URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol
draft-nandakumar-rtcweb-stun-uri-08

[Ballot comment]
[3.1: ABNF changed to reference 3986]

3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.

[Ballot comment]
3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.

[Ballot discuss]

I have more or less the same comments on TURN.

STUN has a username/password feature, right?. If a stuns URI
is used in some protocol for some use-case, (e.g. webrtc)
then shouldn't you REQUIRE that the username/password is also
not sent in clear in that protocol?

[Ballot comment]

- intro: are you saying that w3c goofed in soem draft of
their webrtc spec? The phrase "non-uniform syntaxes proposed"
could be read to mean that.

- I'd have been interested in knowing if the stuns scheme is
implemented in section 6. (And thanks for section 6 btw.)

[Ballot comment]
I agree with Pete's comments about the ABNF, and share his dismay that these documents copy significant bits of standard ABNF productions from the URI document.  I think that's a Bad Idea.

Comment for the document shepherd: Thanks for a good, useful writeup!

[Ballot comment]
My apologies for being completely confused.

The text I was concerned about is not in this draft at all. I'm not quite sure why I was looking at RFC 5389 in the first place.

I'm clearing - and I'm a yes - and then slinking off to file an errata against RFC 5389.

Thanks for Benoit for letting me know that I REALLY need a vision test.

[Ballot comment]
My apologies for being completely confused.

The text I was concerned about is not in this draft at all. I'm not quite sure why I was looking at RFC 5389 in the first place.

I'm clearing - and I'm actually a yes - and I'm slinking off to file the errata against RFC 5389.

Thanks for Benoit for my latest vision test.

[Ballot discuss]
Sorry for my earlier misfire: I missed this until I saw the other document:

  stun-port    = *DIGIT

I suspect you mean "1*DIGIT". You do not want a colon with no port number following it.

[Ballot comment]
3.1: Could you not have gotten some of this syntax from another document?

3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.

[Ballot comment]
3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.

[Ballot discuss]
I'm updating my position on this draft as background for a conversation with the rest of the IESG, so, no action requested from the author at this time.

I had balloted Discuss based on section 17,  IAB Considerations, which starts out

  The IAB has mandated that protocols developed for this purpose
  document a specific set of considerations. 

I pointed out that the IAB's UNSAF RFC (http://tools.ietf.org/html/rfc3424) is Informational, and I didn't think that the IAB could mandate what IETF specifications must contain.

As best as I can tell, the IAB hasn't been able to mandate what IETF protocols do for nearly 20 years. There's nothing in the IAB charter (RFC 2850) beyond "oversight of the standards process", and the IAB isn't given a role in approving IETF documents beyond acting as the body that hears appeals of IESG decisions in RFC 2026.

Gonzalo Salgueiro pointed out that this text also appears in RFC 5389, so this DISCUSS is perhaps better suited for a 5389bis draft effort or an erratum filed against RFC 5389.

I think it's also wrong in RFC 5389, and I agree with Gonzalo that I should be filing an errata against RFC 5389, so there's that, but I don't think it's OK to publish another draft with the same incorrect text, just because it already appears in a published RFC.

Given that we're having a conversation about IESG-IAB scope on some topic about every three weeks, we have five sitting ADs who have served on the IAB and both the IAB chair and IAB liaison to the IESG are former ADs, I would love to hear from other ADs about how I should handle this Discuss :-)

[Ballot discuss]
This will be a Yes, one way or the other, but I'm looking at section 17.  IAB Considerations, which starts out

  The IAB has mandated that protocols developed for this purpose
  document a specific set of considerations. 

I might be missing something, but http://tools.ietf.org/html/rfc3424 is Informational, and I didn't think that the IAB could mandate what IETF specifications must contain, these days. If I'm not confused, perhaps there's another word that would be more appropriate than "mandate"?

IESG/Authors/WG Chairs:

IANA has reviewed draft-nandakumar-rtcweb-stun-uri-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

This document requests adding two Permanent URIs to the Permanent URI registry located at:

http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

The Permanent URI schemes to be added are:

stun
stuns

As this registry is maintained in accordance with the Expert Review policy specified in RFC 5226, IANA will submit these requests to the IESG-designated expert for review.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ballot/


No IPR declarations have been submitted directly on this I-D.