ietf
[Top] [All Lists]

Re: Gen-ART Telechat review of draft-nandakumar-rtcweb-stun-uri-05

2013-07-26 11:00:23
Hi Russ - 

Thanks for the review.  My response is inline to your only review comment...

On Jul 26, 2013, at 4:32 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com> 
wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-nandakumar-rtcweb-stun-uri-05
Reviewer: Russ Housley
Review Date: 26-July-2013
IETF LC End Date: 16-Auguest-2013
IESG Telechat date: Unknown

Summary: This draft is basically ready for publication as a Standards Track
RFC, but a few questions should be answered.

This document is the specification of the syntax and semantics of the
Uniform Resource Identifier (URI) scheme for the Session Traversal
Utilities for NAT (STUN) protocol.

Major issues:

None.

Minor issues:

This document defines ABNF for IPv4 and IPv6 addresses.  It seems better
to do these by reference.  

This document and draft-petithuguenin-behave-turn-uris are being progressed in 
parallel and share common elements. Duplicating the <IPv6address> and 
<IPv4address> ABNF production rules from RFC3986 is one of those common 
elements.  To provide you with a bit of background, this duplication was done 
intentionally and was done as a result of comments during uri-review of the 
original TURN URI draft back in 2009.  Here is the reference to the response to 
the relevant thread where this was decided:

https://www.ietf.org/mail-archive/web/behave/current/msg07380.html

Doing this knowingly spurred the addition of the Design Note you see here in 
the TURN URI draft:

http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris-05#appendix-B

It was an oversight not to add that same Design Note to the STUN URI draft as 
well.  The next version will include an updated version of that Design Note 
with specific reference to the duplicated ABNF production rules (i.e., 
<IPv6address>, <IPv4address>, etc.).

Would that satisfactorily address your comment?

Cheers,

Gonzalo








<Prev in Thread] Current Thread [Next in Thread>