Some comments on this STUN draft and the TURN one:
1) The ABNF in these drafts leaves no room for future extension such as adding parameters. Was that intentional?
2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead of just referencing it? It says in the appendix some ABNF was repeated because RFC 3986 "are for hierarchical URIs". I'm not exactly sure what that means other than you don't have a path component, but as far as I can tell the copied ABNF components in these STUN/TRUN drafts are verbatim copies of RFC 3986, all the way down to their final expansion.
For example, 'IP-literal' and all of its sub-defined parts ('IPv6address', 'IPvFuture', 'h16', 'ls32') appear identical to those in RFC 3986. In fact, so is 'stun-host' and 'turn-host' - it's just RFC 3986 'host' by another name. Am I missing something?
Why not just have this:
stunURI = scheme ":" stun-host [ ":" stun-port ]
scheme = "stun" / "stuns"
stun-host = host ;see section 3.2.2 of [RFC3986]
stun-port = port ;see section 3.2.3 of [RFC3986]
Not a big deal, but it just seems simpler and cleaner to me to not repeat ABNF from other RFCs, especially when the RFC in question is the one for general URI syntax and you're defining a specific URI syntax based on it.
-hadriel
On Aug 12, 2013, at 6:14 PM, Graham Klyne <GK@xxxxxxxxxxxxxx> wrote:
>> From: The IESG <iesg-secretary@xxxxxxxx>
>> To: IETF-Announce <ietf-announce@xxxxxxxx>
>> Reply-To: ietf@xxxxxxxx
>> Sender: <iesg-secretary@xxxxxxxx>
>> Subject: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (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'
>> <draft-nandakumar-rtcweb-stun-uri-05.txt> 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@xxxxxxxx mailing lists by 2013-08-16. Exceptionally, comments may be
>> sent to iesg@xxxxxxxx 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.
>
> As IANA designated expert for reviewing URI scheme registrations, I've been asked to approve this scheme for registration. If there is IETF consensus to publish this document, it is clear to me that the scheme should be registered.
>
> But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized.
>
> The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include:
>
> "New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes."
> -- http://tools.ietf.org/html/rfc4395#section-2.1
>
> This "utility to the broader community" is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something. So, in declaring consensus for this specification, I would request that this aspect at least be considered.
>
> ...
>
> Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation:
> [[
> Classic STUN also had a security vulnerability -- attackers could
> provide the client with incorrect mapped addresses under certain
> topologies and constraints, and this was fundamentally not solvable
> through any cryptographic means. Though this problem remains with
> this specification, those attacks are now mitigated through the use
> of more complete solutions that make use of STUN.
>
> For these reasons, this specification obsoletes RFC 3489, and instead
> describes STUN as a tool that is utilized as part of a complete NAT
> traversal solution.
> ]]
> -- http://tools.ietf.org/html/rfc5389#section-2
>
> It seems to me that creating a URI for STUN could encourage its use in environments outside the "more complete solutions that make use of STUN". This seems to be further reason that STUN[S] should not be a URI scheme.
>
> I have also suggested that, if registered, the URI scheme registration should carries a "health warning" to this effect, and that it is not suitable for general use that is not part of a "complete NAT traversal solution". But I also recognize that I do not fully grasp the security implications, and that if those that do know better can agree that there is no potential for creating security risks here, this suggestion may be unnecessary.
>
> #g
> --