Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt

From: [email-masked]
Date: Mon, 13 Jul 2009 17:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

	Title           : REsource LOcation And Discovery (RELOAD) Base Protocol
	Author(s)       : C. Jennings, et al.
	Filename        : draft-ietf-p2psip-base-03.txt
	Pages           : 146
	Date            : 2009-07-13

In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC
3979 respectively.  They refer only to those RFCs and not any
documents that update or supersede them.

This document defines REsource LOcation And Discovery (RELOAD), a
peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P
signaling protocol provides its clients with an abstract storage and
messaging service between a set of cooperating peers that form the
overlay network.  RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that
specify the kinds of data that must be stored for a particular
application.  RELOAD defines a security model based on a certificate
enrollment service that provides unique identities.  NAT traversal is
a fundamental service of the protocol.  RELOAD also allows access
from "client" nodes that do not need to route traffic or store data
for others.

Legal

This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Craig, Dave" <[email-masked]>
Date: Tue, 14 Jul 2009 17:13:24 -0700

I had a few questions on my interpretation of the latest updates as well a few typos.

1. I was trying to understand the change made in 3.2.1.  Could that change also be read as follows?

Note that clients that chose this option MUST process Update messages from the peer.  Those updates can indicate that the peer no longer owns the Client's Node-ID.  The client then forms a connection to the appropriate peer.

2. The change made at the end of 5.4.1.

All overlay algorithms MUST specify maintenance procedures _that_ send Updates to all members of the Connection Table...

3. The change made at the beginning on 5.4.2.3 seems to conflict with that at the end of 5.4.1.  If you MUST send Updates to all members of the connection table, then why is it a SHOULD in 5.4.2.3?

4. Should the IceExtension in 5.5.1.1 be a TLV, so stacks not comprehending the extensions can still Attach?  That preserves a little more of the extensibility in the SDP string encoding.

5. In 5.5.2.3, first paragraph, would this read a little easier as, "... When a connection forms, the node MUST check _that_ the certificate is for the node that _sent_ AttachLiteReqAns..."

6. In 5.5.3., first paragraph, "The AppAttach request and its response contain _an_ application attribute..."

7. In 5.6.2.2., end of paragraph, it looks like a dangling sentence was not finished being removed.

8. In 5.6.2.2.1. third paragraph, "...looking at the time the ACK was received and the time when the message was sent."

9. In 5.6.2.2.1. fifth paragraph, was the following intended?  "If all retransmissions for a message fail, _the sending node should close the connection routing the message_."  Should there also be additional hysteresis to make sure that a failing connection is not quickly reestablished under a fast chord-reload-ping-frequency?

10. In 5.6.3, second paragraph, "take into account space to allow the via and _destination_ lists to grow."

11. In 10.1, your -frequency elements actually specify periods not occurrences per unit of time.  Suggest renaming these to end in "-period" or "-interval".  End users or developers may enter in the wrong value here if they go by the label name alone.

12. In 10.1, I found descriptions for the namespace and encoding requirements for the overlay configuration document.  Is it ok to leave it implicit that these apply to the kind configuration documents sent in 5.5.6.1?

13. In 10.1, "root-cert   This element contains PEM encoded X.509v3 certificates that are a..."

14. In 10.1, Could the following:

   kinds-signature   This signature is computed across the prevision
      kind from the beginning of the first < of the kind to the end of
      the last > of the kind in the same was as the "signature element
      described later in this section.

be reworded as?

   kind-signature   This signature is computed across the
      kind from the beginning of the first < of the kind to the end of
      the last > of the kind in the same way as the "signature element
      described later in this section.

Likewise, kinds-signer in the descriptions appears to be kind-signer in the example.  Suggest updating example with kinds-signer.

15. In 10.5 there's a reference to a broadcast-peers element in the configuration document that is not defined in 10.1.  Is this really the bootstrap-peer element in 10.1?

Thanks,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, July 13, 2009 5:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt
> 
> 3979 respectively.  They refer only to those RFCs and not any documents
> that update or supersede them.
> 
> This document defines REsource LOcation And Discovery (RELOAD), a peer-
> to-peer (P2P) signaling protocol for use on the Internet.  A P2P
> enrollment service that provides unique identities.  NAT traversal is a
> fundamental service of the protocol.  RELOAD also allows access from
> "client" nodes that do not need to route traffic or store data for
> others.
> 
> Legal
> 
> This documents and the information contained therein are provided on an
> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 14 Jul 2009 23:43:17 -0400

Here is the change log for p2psip-base-03:

    * Rearranged forwarding header to fix alignment among other issues
    * Removed route logging
    * Switched to binary ICE for Attach
    * ConfigUpdate improved
    * Change from close DTLS session on fragmentation attack to drop
fragments, indirect attack
    * Updates to trivial sender/receiver text
    * Updates to data model based on list discussion
    * Updates to chord overlay algorithm section
    * Added AppAttach and removed port number from Attach
    * Changed via-list to use shorter structure
    * Rewrote fragmentation
    * Moved AIMD and TFRC congestion control algorithms to appendix
until further wg effort decides direction there.

For a more thorough view of changes, take a look at the diff

http://tools.ietf.org/rfcdiff?url2=draft-ietf-p2psip-base-03.txt

Bruce

On Mon, Jul 13, 2009 at 8:00 PM, <[email-masked]> wrote:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: jc <[email-masked]>
Date: Tue, 14 Jul 2009 23:07:49 -0700

FYI: The sample xml configuration has open/end tag mismatches.

            <kind-signer> 47112162e84c69ba <kind-signer>
            <kind-signer> 6eba45d31a900c06 <kind-signer>

jc

On Jul 13, 2009, at 5:00 PM, [email-masked] wrote:

> <mime-attachment>_______________________________________________
> P2PSIP mailing list
> [email-masked]

---

From: jc <[email-masked]>
Date: Tue, 14 Jul 2009 23:19:45 -0700

It is my opinion that the SRV Service name for enrollment server  
discovery be changed from "p2p_enroll" to "p2psip_enroll".

jc

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 15 Jul 2009 08:41:14 -0700

First off, thanks to the authors for getting the new version out. It's
a great deal of work to revise it and we appreciate it.

At the last meeting in San Francisco, I asked for volunteers to review
the next version as soon as it came out. Now that it is out, I would
like to ask the volunteers we had (Vidya Narayana, Saumitra Das,
Melody Song, and myself) to please now do a review. (I've already
started mine) I know that the editors would really appreciate the
feedback, and as WG chairs, we want to get the draft moving forward,
and getting formal reviews.

Also, if there are any other volunteers willing to do a complete
review, please drop me an email.

I'd like to have these reviews as soon as possible.

Also: thanks to Dave Craig, who I noticed already sent very
substantial comments on the new draft.

Thanks,

David (as chair)

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 16 Jul 2009 23:08:57 -0400

Dave,

Thanks for your detailed read and comments.  Going to try to
incorporate them into the next update.

> 9. In 5.6.2.2.1. fifth paragraph, was the following intended?  "If all retransmissions for a message fail, _the sending node should close the connection routing the message_."  Should there also be…

Yes, that sentence should have finished that the link has failed and
the connection be closed.

Actually, ping-frequency doesn't come into play very much here.
First, it's very long, and second, the algorithm uses randomness in
its finger table searches, trying to avoid this problem.  It's more of
an issue for neighbor connections, which are tried more aggressively.
But if you're using periodic recovery, you get that automatic bit of
hysteresis.  A reactive recovery implementation probably would want to
detect and avoid rapid oscillations, but the draft doesn't go into
that detail right now.  Probably it should mention it.

Bruce

---

From: Michael Chen <[email-masked]>
Date: Sun, 26 Jul 2009 09:54:20 -0700

Hi,

Nice to see progress. Here are things I want to point out and suggest:

1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not 
conform with the current mmusic-ice-19 section 15.1, which has the 
following text:

"<rel-addr> and <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>
      and <rel-port> MUST be present for server reflexive, peer
      reflexive and relayed candidates."

Therefore, the definition of IceCandidate should be:

         struct {
           ...
           select (type){
             case host:
               ;          /* Nothing */
             case srflx:
             case prflx:
             case relay:
               IpAddressPort     rel_addr_port;
           }
           ...
         } IceCandidate;

   rel_addr_port
      corresponds to the related address and port of ICE, which MUST
      present for type "srflx", "prflx" and "relay".

2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq 
are not added. I suggest fill these two values (app_attach_req=5, 
app_attach_ans=6) in the holes left by the abandoned tunnel_req and 
tunnel_ans.

3) In Section 6.4.1.2, if the store request has multiple kinds, the 
current answer structure will send replica node IDs multiple times. For 
efficiency, I suggest moving the replica node IDs to the outer layer as:

         struct {
           KindId                  kind;
           uint64                  generation_counter;
         } StoreKindResponse;

         struct {
           StoreKindResponse       kind_responses<0..2^16-1>;
           NodeId                  replicas<0..2^16-1>;
         } StoreAns;

4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members 
of this draft should address the lack of ice-tcp standard in the next 
draft, meeting or on the mailing list. Assuming this group is no longer 
interested in mmusic-ice-tcp-07, something like this should be added  to 
section  5.5.1.5 to make things clear:

   For peers that support TCP/TLS, the ICE TCP host candidates are the addresses
   and port number of each network interface it listens to.  They may also be the
   address and port number accessible to other peers via methods described in 
   draft-lowekamp-mmusic-ice-tcp-framework.

   When forming ICE check candidate pairs, a local TCP candidate is paired with
   a remote TCP candidate of matching address type (IPv4 or IPv6).  In addition,
   for peers in "active" or "act-pass" role, a new port number MUST be allocate
   for the local candidate in the pair.  This is often done automatically by the 
   operating system when the program calls the connect() function of the socket
   library to creates a TCP connection to the remote candidate address.

That is it so far. Thanks

--Michael

[email-masked] wrote:
> ------------------------------------------------------------------------
>