-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Any chance to have an answer to the questions below?
Thanks.
On 11/01/2010 10:53 AM, Marc Petit-Huguenin wrote:
> A first batch of questions, comments and nits:
>
> - A.1. Section 4.1.2
>
> This section lists what need to be provided to describe a RELOAD storage
> usage.
> OTOH section 4.3 states that "[e]ach usage specifies which type of
> connections
> can be initiated using AppAttach."
>
> Would not it be better to have to add the sentence from 4.3 in the list of
> things that an usage must provide, and move the whole 4.1.2 section outside
> 4.1
> (e.g. as 4.4 section)?
>
> - A.2. Section 5.2.1, 4th paragraph
>
> Is this retransmission needed when sending messages that are clearly
> hop-by-hop,
> like Leave, Update and RouteQuery?
>
> - A.3. Section 5.3.2, "The message is easy to demultiplex from STUN messages
> by
> looking at the first bit."
>
> I think that this sentence is misleading and should be removed. As Message
> are
> always encapsulated in FramedMessage, relo_token cannot be the first word on
> the
> boundary and the STUN messages are not encapsulated in FramedMessage either.
> They are not even encrypted by DTLS (5.5.1.13: "Consequently, once ICE
> processing completes, the agent will begin TLS or DTLS procedures to
> establish a
> secure connection."). My understanding is that even keepalives (section
> 5.5.1.10.3) are not encrypted, probably using the FINGERPRINT attribute to
> differentiate them from encrypted packets. That would fit with section 5.5.1.4
> that says that "...every peers is a STUN server." (but see next entry).
>
> - A.4. Section 5.5.1.4 "Because all RELOAD peers implement ICE and use STUN
> keepalives every peer is a STUN server [...]"
>
> Something implementing ICE connectivity checks is not also a STUN server, at
> least not in the sense of RFC 3489 section 13 (compare with RFC 5245 section
> 10).
>
> - A.5. Section 5.5.1.13 "[...] the media takes the form of application layer
> protocols (RELOAD or SIP for example)[...]"
>
> Attach only supports RELOAD messages. SIP messages are carried by AppAttach.
> I
> think that this whole section must be copied under 5.5.2, and both sections
> cleaned.
>
> - A.6. Section 5.5.2.2
>
> What error code should be used if the peer does not support the application-ID
> in the AppAttachAns message?
>
> - A.7. Section 5.5.4.1 "config_data<2^24-1>"
>
> If I use the explanations in 5.3.1.1 ("The number of bytes to encode the
> length
> on the wire is derived by range; i.e., it is the minimum number of bytes which
> can encode the largest range value."), does this means that the length must be
> encoded with 3 bytes?
>
> - A.8. Section 5.7 "Upon receipt of a fragmented message by the intended
> peer[...]"
>
> It is not clear if the reassembly is done hop-by-hop or end-to-end. The
> previous paragraph states that "[...] a message may be refragmented multiple
> times as it traverse the overlay." which would indicate hop-by-hop reassembly,
> but the next paragraph states that "[...] this time was derived from looking
> at
> the end to end transmission time and saving fragments long enough for the full
> end to end retransmissions to take place." which would imply end-to-end
> reassembly.
>
> Nits
> ====
>
> - Section 1.2.1, 2nd paragraph
>
> s/A usage/ An usage/
>
> - Section 3.3, "Destination Lists:"
>
> s/NodeID/Node-ID/
>
> - Section 5.1, third bullet
>
> s/NodeIDs/Node-IDs/
> s/Resource IDs/Resource-IDs/
>
> - Section 5.4.2.4 title and 1rst paragraph
>
> s/Route_Query/RouteQuery/
>
> - Section 5.5.1.1 "foundation<0..255>"
>
> s/255/2^8-1/
>
> Also name<2^16-1> should be name<0..2^16-1>, here and at various other places.
>
> - Section 5.6.3.1.1 1st paragraph
>
> s/A peer/A node/
> s/The peer MUST/The node MUST/
>
> - Section 5.6.6 title
>
> Superfluous spaces.
>
> - Section 6.1. Input formula
>
> Perhaps replacing the "+" with "|"?
>
> - Section 6.4.1.1 "KindId kind;"
>
> KindId is never defined.
>
> - Section 6.4.3.2. "hash_value<0..255>"
>
> s/255/2^8-1/
>
> - Section 6.4.4 "[...] to walk the Overlay Instance by interactively fetching
> [...]"
>
> I am not a native English speaker, but "interactively" looks strange to me in
> this context.
>
> - Section 6.4.4.2. "[...] it SHOULD return a 404 RELOAD error code."
>
> "404 RELAOD" is not an error code.
>
> - Section 8, 2nd paragraph
>
> s/Peer-ID/Node-ID/
>
> - Section 8, last paragraph, "[..] for the appropriate server type with that
> Resource-ID."
>
> s/server type/KindID/
>
> - Section 9, 2nd paragraph
>
> s/peer id/Node-ID/
>
> - Section 9.6.1 3rd paragraph
>
> s/ATTACH/Attach/
>
> - Section 9.6.3 last paragraph
>
> s/UPDATE/Update/
>
> - Section 9.7 title
>
> s/Route Query/Route query/
>
> - Section 13.5 table
>
> RELOAD is not carried by AppAttach.
>
> - Section 13.8 table
>
> The remove_req and remove_ans messages no longer exist.
> The config_update_req and config_update_ans messages are missing.
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
- --
Marc Petit-Huguenin
Personal email: [email protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkzVbcQACgkQ9RoMZyVa61eBSwCeM1Cm39S9NyBK17k+Pl62+hqm
a2QAn0Rn5LUzkFtMeQjOuderg057WWJj
=rrqv
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
