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

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Aug 2013 10:04:51 -0700

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.

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.

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.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 20 Aug 2013 00:38:02 -0400

Ted - 

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

On Aug 16, 2013, at 1:04 PM, Ted Hardie <[email-masked]> 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss