Hi Magnus, We just published version -10. See below for some comments.
On 06/28/2016 07:35 AM, Magnus Westerlund wrote: > Authors and WGs, > > In my review for the publication writeup I did spot some issues in the draft. > Please consider the following issues: > > 1. Abstract: With the addition of the ZRTP the abstract should benefit from > being updated. The ZRTP protocol being possible to multiplex is missing as > well as that there are now 4 issues. Fixed. > > 2. Abstract contains [ref] to RFC 5764. This is an ID nit. Fixed. > > 3. Section 1. The introduction is not explicitly saying that it updates RFC > 5764. I think that can be put as a sentence after: > > This is achieved by > modifying the IANA registries with instructions for coordination > between the protocols at risk. We incorporated this in that sentence and also added it into the abstract. > > 4. Reference ID-nits: > > == Outdated reference: A later version (-31) exists of > draft-ietf-mmusic-sdp-bundle-negotiation-23 Fixed. > > 5. Section 2: > > ID-nits complains about the modified boilerplate for the RFC2119 text. First > of all one usually don't cut down the list to only the used ones. The > requirement on all caps ones I am very divided about. I do have a preference > for unmodified boilerplate, this as I otherwise have to explain in the > write-up the ID-nit. Fixed. > > 6. Section 6: > > In order to prevent future documents from assigning values from the > unused range to a new protocol, this document modifies the RFC 5764 > demultiplexing algorithm to properly account for TURN channels by > allocating the values from 64 to 79 for this purpose. > > I think this text fails to be explicit about that this restricts the TURN > Channel space to a more limited set of possible channels when the TURN client > does the channel binding request. Thus affecting the TURN channel allocation > algorithm in the client implementations, at least when used in combination of > muxing. Fixed. > > Based on this and the fact that this specification changes the IANA > registrations performed by RFC5766, I think this document to have "Updates" > for RFC5766 also. So please add that in header, abstract and introduction. Based on our understanding and looking at other RFCs, just updating an IANA registry does not imply a update to the core specification, so we did not made that change. > > 7. Updates RFC5389: > > Looking at the impact also on the STUN protocol I would also think that this > requires and "Updates" also for RFC 5389. > Based on the argument above, we do not think that this warrants an "Updates" status. > > 8. Section 10.3: > > The IANA registry name is not the correct one. The IANA page says that the > registry name is: > > Traversal Using Relays around NAT (TURN) Channel Numbers > http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#turn-channel > > Please update. Fixed. > > 9. Section 12.2: > > The reference to ZRTP [RFC6189] is likely in the wrong category, at the same > time moving this to a normative one creates a downref. I guess it one that > has to be accepted in this case. I suggest that you move it to the normative > references. We are keeping it informative for now, but we will forward the discussion with the AD to the mailing-list as requested. -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
