Re: [apps-discuss] Apps directorate review of draft-nandakumar-rtcweb-stun-uri-5.txt

Ted - 

Thanks for your review and feedback.  Some comments inline...

On Aug 16, 2013, at 1:04 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> Document:  draft-nandakumar-rtcweb-stun-uri-5.txt
> 
> Title:  URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol
> 
> Reviewer: Ted Hardie
> Review Date: August 16th, 2013
> Summary: This document is ready to be published as an informational RFC; it currently gives a target of standards track, but  I do not believe this is required.

While registration of a URI does not mandate a Standards Track document, I suspect there is some level of subjectivity here.  Our view is that If we had gone to the IETF after the fact (i.e., the URIs were used in products) and then we documented them in an RFC, then yes, we would agree that Informational is more appropriate.  But in this instance that was not the case .  We went to the IETF first and interacted with experts to develop a normative specification that provides protocol directive. This, Standard Track seems the more appropriate status in this case.

> 
> Discussion:  The draft has had some discussion in response to comments by Graham Klyne, the Designated Expert for URI schemes.  I personally believe that this document has sufficient utility to qualify for permanent registration, both in the WebRTC context and potentially in similar contexts.  I also am not terribly worried that it duplicates the ABNF of RFC 3986; while it certainly could have done it differently, the chances of drift in definition in this case seem low enough to be harmless.

Good to hear as that our (the authors) collective position on this as well.
> 
> Nit:  The document recommends removal of the implementation status section, but not the appendices, including the one which gives the design rationale.  I'd either move the implementation status to an appendix and keep the all, or remove them all.  But this is obviously an editorial choice, not a substantive issue.

The reason we proceeded as we have is because removing the implementation status report was mandated by RFC 6982, while the design notes were important for future implementers to understand the choices (and was done at the request of the document Shepherd).

Cheers,

Gonzalo

> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss