Re: [tram] Updated IANA sections in STUNbis (RFC 8489)

Harald Alvestrand <harald@alvestrand.no> Mon, 25 November 2019 13:51 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5F12095B for <tram@ietfa.amsl.com>; Mon, 25 Nov 2019 05:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXWYR8SrZVoc for <tram@ietfa.amsl.com>; Mon, 25 Nov 2019 05:51:06 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3381812095D for <tram@ietf.org>; Mon, 25 Nov 2019 05:51:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9739A7C0AB1; Mon, 25 Nov 2019 14:51:04 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBC5QTCBWd3Q; Mon, 25 Nov 2019 14:51:01 +0100 (CET)
Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id CC8697C0A26; Mon, 25 Nov 2019 14:51:01 +0100 (CET)
To: Marc Petit-Huguenin <petithug@acm.org>, "tram@ietf.org" <tram@ietf.org>
References: <ac5ba642-60a0-84c8-9e2d-b6b0c83677fb@acm.org> <cfe3cfa2-de13-a6c6-f0ed-f4f67ce25d71@alvestrand.no> <6a30205b-36d5-ea0c-5105-cffdb327e915@acm.org>
From: Harald Alvestrand <harald@alvestrand.no>
Openpgp: preference=signencrypt
Message-ID: <15f68a35-f963-0bc9-468b-6836fa8b244e@alvestrand.no>
Date: Mon, 25 Nov 2019 14:51:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <6a30205b-36d5-ea0c-5105-cffdb327e915@acm.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/WHUksz9FHoX7RMkJN2dMButKkho>
Subject: Re: [tram] Updated IANA sections in STUNbis (RFC 8489)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2019 13:51:09 -0000

Den 25.11.2019 14:48, skrev Marc Petit-Huguenin:
> Hi Harald,
> 
> Thanks for the review, please find the new text below.  About your question about attributes with an updated reference, these are still listed in sections 18.3.1 (updated attributes) and 18.3.2 (new attributes).  The text in section 18.3 below in just added in front of these 2 sections.

Looks good to me!

The "attributes updated" is what happens when reviewing diffs rather
than documents - I assume you'll get it back together in a good way.

Thanks for the update!

Harald

> 
> 
> "18.2.  STUN Methods Registry
> 
>     A STUN method is a hex number in the range 0x000 - 0xFFF.  The
>     encoding of STUN method into a STUN message is described in
>     Section 5.
> 
>     STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review
>     [RFC8226].  STUN methods in the range 0x800 - 0xFFF are assigned by
>     Expert Review [RFC8226].  The responsibility of the expert is to
>     verify that the selected codepoint(s) are not in use and that the
>     request is not for an abnormally large number of codepoints.
>     Technical review of the extension itself is outside the scope of the
>     designated expert responsibility.
> 
>     IANA has updated the name for method 0x002 as described below as well
>     as updated the reference from RFC 5389 to RFC 8489 for the following
>     STUN methods:
> 
>     0x000: Reserved
>     0x001: Binding
>     0x002: Reserved; was SharedSecret prior to [RFC5389]"
> 
> "18.3.  STUN Attributes Registry
> 
>     A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF.
>     STUN attribute types in the range 0x0000 - 0x7FFF are considered
>     comprehension-required; STUN attribute types in the range 0x8000 -
>     0xFFFF are considered comprehension-optional.  A STUN agent handles
>     unknown comprehension-required and comprehension-optional attributes
>     differently.
> 
>     STUN Attribute types in the first half of the comprehension-required
>     range (0x0000 - 0x3FFF) and in the first half of the comprehension-
>     optional range (0x8000 - 0xBFFF) are assigned by IETF Review
>     [RFC8226].  STUN Attribute types in the second half of the
>     comprehension-required range (0x4000 - 0x7FFF) and in the second half
>     of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
>     Expert Review [RFC8226].  The responsibility of the expert is to
>     verify that the selected codepoint(s) are not in use, and that the
>     request is not for an abnormally large number of codepoints.
>     Technical review of the extension itself is outside the scope of the
>     designated expert responsibility."
> 
> "18.4.  STUN Error Codes Registry
> 
>     A STUN error code is a number in the range 0 - 699.  STUN error codes
>     are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is
>     intended only for human consumption and can be anything appropriate;
>     this document proposes only suggested values.
> 
>     STUN error codes are consistent in codepoint assignments and
>     semantics with SIP [RFC3261] and HTTP [RFC2616].
> 
>     New STUN error codes are assigned based on IETF Review [RFC8226].
>     The specification must carefully consider how clients that do not
>     understand this error code will process it before granting the
>     request.  See the rules in Section 6.3.4.
> 
>    IANA has updated the reference from RFC 5389 to RFC 8489 for the
>    error codes defined in Section 14.8.
> 
>    IANA has changed the name of the 401 error code from "Unauthorized"
>    to "Unauthenticated"."
> 
> 
> On 11/11/19 6:12 AM, Harald Alvestrand wrote:
>> Den 10.11.2019 15:56, skrev Marc Petit-Huguenin:
>>> I have been asked by Magnus to send the proposed changed to the IANA section to the WG and to Harald for review.  The full new content of the 3 sections are copied below:
>>
>> Great to see this!
>>
>> Nits:
>> - RFC 5226 is obsoleted by RFC 8226
>> - The term "Designated Expert" is now deprecated; please use "Expert
>> Review" (8226 section 4.5).
>>
>> Those are the ones I found on reading. Also, there's one question below.
>> Apart from that, I'm happy.
>>
>>>
>>>
>>> "18.2.  STUN Methods Registry
>>>
>>>     A STUN method is a hex number in the range 0x000 - 0xFFF.  The
>>>     encoding of STUN method into a STUN message is described in
>>>     Section 5.
>>>
>>>     STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review
>>>     [RFC5226].  STUN methods in the range 0x800 - 0xFFF are assigned by
>>>     Designated Expert [RFC5226].  The responsibility of the expert is to
>>>     verify that the selected codepoint(s) are not in use and that the
>>>     request is not for an abnormally large number of codepoints.
>>>     Technical review of the extension itself is outside the scope of the
>>>     designated expert responsibility.
>>>
>>>     IANA has updated the name for method 0x002 as described below as well
>>>     as updated the reference from RFC 5389 to RFC 8489 for the following
>>>     STUN methods:
>>>
>>>     0x000: Reserved
>>>     0x001: Binding
>>>     0x002: Reserved; was SharedSecret prior to [RFC5389]"
>>>
>>> "18.3.  STUN Attributes Registry
>>>
>>>     A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF.
>>>     STUN attribute types in the range 0x0000 - 0x7FFF are considered
>>>     comprehension-required; STUN attribute types in the range 0x8000 -
>>>     0xFFFF are considered comprehension-optional.  A STUN agent handles
>>>     unknown comprehension-required and comprehension-optional attributes
>>>     differently.
>>>
>>>     STUN Attribute types in the first half of the comprehension-required
>>>     range (0x0000 - 0x3FFF) and in the first half of the comprehension-
>>>     optional range (0x8000 - 0xBFFF) are assigned by IETF Review
>>>     [RFC5226].  STUN Attribute types in the second half of the
>>>     comprehension-required range (0x4000 - 0x7FFF) and in the second half
>>>     of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
>>>     Designated Expert [RFC5226].  The responsibility of the expert is to
>>>     verify that the selected codepoint(s) are not in use, and that the
>>>     request is not for an abnormally large number of codepoints.
>>>     Technical review of the extension itself is outside the scope of the
>>>     designated expert responsibility."
>>
>> Are there no attributes with an updated reference in this registry?
>>
>>>
>>> "18.4.  STUN Error Codes Registry
>>>
>>>     A STUN error code is a number in the range 0 - 699.  STUN error codes
>>>     are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is
>>>     intended only for human consumption and can be anything appropriate;
>>>     this document proposes only suggested values.
>>>
>>>     STUN error codes are consistent in codepoint assignments and
>>>     semantics with SIP [RFC3261] and HTTP [RFC2616].
>>>
>>>     New STUN error codes are assigned based on IETF Review [RFC5226].
>>>     The specification must carefully consider how clients that do not
>>>     understand this error code will process it before granting the
>>>     request.  See the rules in Section 6.3.4.
>>>
>>>    IANA has updated the reference from RFC 5389 to RFC 8489 for the
>>>    error codes defined in Section 14.8.
>>>
>>>    IANA has changed the name of the 401 error code from "Unauthorized"
>>>    to "Unauthenticated"."
>>>
>>
> 
>