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 protected] [mailto:[email protected]] On
> Behalf Of [email protected]
> Sent: Monday, July 13, 2009 5:00 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt
>
> 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.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
