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.
2. Abstract contains [ref] to RFC 5764. This is an ID nit.
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.
4. Reference ID-nits:
== Outdated reference: A later version (-31) exists of
draft-ietf-mmusic-sdp-bundle-negotiation-23
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.
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.
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.
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.
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.
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.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com
----------------------------------------------------------------------
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
