draft-willis-p2psip-concepts-02(1012).txt

IETF12号的文档

4.1.  PP2PSIP Peer Protocol

   This may or may not be SIP.  What should it be?  Alternatives include
   SIP, a full IETF protocol based on OpenDHT, or something else.  Do we
   need to define a new protocol?  Will implementors want to implement a
   new protocol?

4.2.  P2PSIP Client Protocol

   This may or may not be SIP.  What should it be?  It defines only GET/
   PUT operations, which could be done using SIP REGISTER transactions.
   Essentially disappears if we do select SIP.

4.3.  How To Find Media Relays?

   This needs to be net-path efficient.  Is this possible?  Is it enough
   just to construct a key with a "relay" identifier?  What sorts of
   access controls do we need on media relays?





Willis, et al.           Expires April 15, 2007                [Page 20]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


4.4.  How Do We Find Gateways?

   This needs to be not only netpath efficient, but also embodies
   elements of the TRIP and SPEERMINT problems.

4.5.  Peer-Adjacency Through NATs

   We assume that some or even many peers will be behind NATs, and
   therefore reached through peer-to-peer routing.  How do we keep alive
   the NAT-crossing peer bindings?  Is some variant of "outbound" [15]
   usable?

4.6.  Cryptotransparency

   When forwarding requests, are the bodies of the requests visible to
   peers?  If so, this creates substantial security problems that the
   deployers of conventional SIP have been willing to mostly ignore.
   Can we make peers cryptotransparent (like HTTP proxies) when security
   is requested?

4.7.  Record Formats

   Clearly we need user routing records stored into the P2PSIP overlay.
   Do we need other sorts of record?  If so, what?  How do we
   differentiate between or classify records?  Do we end up with many
   records per user per client, or do we aggregate the per-client or
   per-user view using something like XML?

4.8.  Peer and Client Enrollment Protocols

   We know that we need to enroll peer and client nodes into a P2PSIP
   Overlay.  Do we define a protocol or process for this, assume it will
   happen externally, or just provide an existence-proof argument?

4.9.  Peer and User Credentials

   We believe we need some sort of credentials for authenticating peers
   and users of each P2PSIP Overlay.  What should we use for these
   credentials?  Certificates?  PGP keys?  Passwords?  If certificates,
   should these be signed by a CA associated with the overlay, or can
   self-signed certificates work in some or all cases?  Do we need to
   specify a standard credential format, or should we allow different
   implementations to use different credential formats?

4.10.  Bootstrapping

   We know that sometimes peers or clients will start up without
   knowledge of how to find a peer for insertion.  Do we need to define



Willis, et al.           Expires April 15, 2007                [Page 21]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


   a bootstrap mechanism or mechanisms?  Do we need to define supporting
   protocols?

4.11.  Credential Recovery

   One reader suggested that we extend the definition of P2PSIP Peer
   Enrollment to cover the case where a previously-inserted peer has
   lost its credentials (through, perhaps, being moved to a different
   host) and wishes to recover them without necessarily creating a new
   P2PSIP Peer-ID.  The editors are inclined to believe that this is an
   operational issue, not a matter of definition, but would like to seek
   a broader consensus before concluding the topic.  A similar question
   applies to user enrollment.

4.12.  Overlapping Domains

   If the P2PSIP Resource (User) Identifier is not scoped to a single
   DNS domain, this would appear to allow nodes from two or more
   apparent domains to share a single P2PSIP Overlay.  What, if
   anything, do we need to say about this mode of operation?

4.13.  Hybrid Domains

   It appears possible to have some hosts within a domain using
   conventional SIP and some using P2PSIP.  This potentially raises a
   number of questions: 1) What should happen if we want to run a P2PSIP
   overlay in an existing SIP domain? 2) Do the existing redir/proxy
   servers need to be coupled with a peer layer? 3) When would an
   overlay peer want to discover them as opposed to looking in the
   overlay? 4) Is better not to run conventional SIP with P2PSIP? 5)
   When conventional and P2PSIP are run together, shall the existing
   redir servers keep their local databases or switch to the overlay
   storage.

4.14.  Admissions Control

   What do we need to say about admissions control with respect to the
   enrollment of peers and users?  Do we need to discuss per-call
   admissions control in a P2P environment?

4.15.  Users versus Resources

   This model presumes that all addressable elements, aka "users", are
   unique.  Are their other classes of resources that need some sort of
   class-addressable identifier that does not refer to a unique user?






Willis, et al.           Expires April 15, 2007                [Page 22]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


5.  Security Considerations

   Building a P2PSIP system has many security considerations, many of
   which we have only begun to consider.  We anticipate that the
   protocol documents describing the actual protocols will deal more
   thoroughly with security topics.


6.  IANA Considerations

   This document presently raises no IANA considerations.


7.  Acknowledgements

   This document draws heavily from the contributions of many
   participants in the P2PSIP Mailing List but the authors are
   especially grateful for the support of Spencer Dawkins, Cullen
   Jennings, and Henning Schulzrinne, all of whom spent time on phone
   calls about this document or provided text.  Additionally, Spencer
   provided a large portion of the ASCII art contained in this document.


8.  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
        Resource Locators (URL)", RFC 1738, December 1994.

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

   [5]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [6]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
        Extension Header Field for Registering Non-Adjacent Contacts",
        RFC 3327, December 2002.





Willis, et al.           Expires April 15, 2007                [Page 23]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


8.2.  Informative References

   [7]   Bryan, D., "A P2P Approach to SIP Registration and Resource
         Location", draft-bryan-sipping-p2p-02 (work in progress),
         March 2006.

   [8]   Shim, E., "An Architecture for Peer-to-Peer Session Initiation
         Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in
         progress), March 2006.

   [9]   Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet
         Communications", draft-johnston-sipping-p2p-ipcom-02 (work in
         progress), March 2006.

   [10]  Matthews, P., "Industrial-Strength P2P SIP",
         draft-matthews-sipping-p2p-industrial-strength-00 (work in
         progress), February 2005.

   [11]  Risson, J. and T. Moors, "Survey of Research towards Robust
         Peer-to-Peer Networks: Search Methods",
         draft-irtf-p2prg-survey-search-00 (work in progress),
         March 2006.

   [12]  Bryan, D., "Use Cases for Peer-to-Peer Session Initiation
         Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 (work
         in progress), December 2005.

   [13]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
         June 2005.

   [14]  Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
         Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
         progress), October 2006.

   [15]  Jennings, C. and R. Mahy, "Managing Client Initiated
         Connections in the Session Initiation Protocol  (SIP)",
         draft-ietf-sip-outbound-04 (work in progress), June 2006.

URIs

   [16]  <http://en.wikipedia.org/wiki/File_sharing>










Willis, et al.           Expires April 15, 2007                [Page 24]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


Authors' Addresses

   Dean Willis (editor)
   Cisco Systems
   3100 Independence Pkwy #311-164
   Plano, Texas  75075
   USA

   Phone: unlisted
   Email: [e-mail]


   David A. Bryan
   SIPeerior Technologies and William & Mary
   3000 Easter Circle
   Williamsburg, Virginia  23188
   USA

   Phone: unlisted
   Email: [e-mail]


   Philip Matthews
   Avaya
   100 Innovation Drive
   Ottawa, Ontario  K2K 3G7
   Canada

   Phone: [phone] x224
   Email: [e-mail]


   Eunsoo Shim
   Panasonic Digital Networking Laboratory
   Two Research Way, 3rd Floor
   Princeton, New Jersey  08540
   USA

   Phone: unlisted
   Email: [e-mail]











Willis, et al.           Expires April 15, 2007                [Page 25]

Internet-Draft       P2PSIP Concepts and Terminology        October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Willis, et al.           Expires April 15, 2007                [Page 26]