Subject: Re: [AVTCORE] Errata on RFC 5764 (Errata 3913)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Jan 2015 16:23:04 +0100

WG,

In regards to the following Errata:

http://www.rfc-editor.org/errata_search.php?eid=3913

As we currently have a milestone and candidate WG document that proposes
to deal with this issue. I think a reasonable handling of this one would
be to put it into the "Held for Documents Update" category.

Please provide feedback by the 12th of February.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Jan 2015 13:28:20 +0100

WG,

Based on this discussion it appears that the conclusion was to Reject
this errata. We have ongoing document work that will address this issue,
so approving it would be to get ahead of that work. Secondly, held for
document update appears possible, but also unnecessary now that the work
actually is happening.

So this will be requested to be rejected by the AD, unless someone
speaks up before the 13th of February.

Cheers

Magnus
WG chair

On 2014-05-05 08:41, Magnus Westerlund wrote:
> On 2014-05-02 19:10, Martin Thomson wrote:
>> On 2 May 2014 01:26, Magnus Westerlund <[email-masked]> wrote:
>>> 1. To any in the WG: Do you really think there is an issue of
>>> restricting STUN to 128 methods per class per existing RFC?
>>
>> This is an alternative to what I proposed, which would leave 5764
>> alone.  You need to make some allowance for this though:
>> http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#stun-parameters-2
>>  (Note the range 0x800-0xFFF, which is currently unused)
> 
> 
> Yes, and from my personal position, I think it is fine to leave RFC 5764
> alone here. The 128 methods per class should be sufficient.
> 
> But I do agree that we should work to ensure that these limitations are
> reflected in STUN's IANA section.
> 
>>
>>> 2. To Martin: What made you think there was an error in RFC 5764?
>>
>> This:
>>
>>> Formally this is a value overlap between what STUN could potentially use
>>> (0-63) and what DTLS can potentially use 20-63.
>>
>> I don't think that it's quite fair to say that it's a fault of STUN.
>> STUN was there first, so arguably the fault lies with RFC 5764.
> 
> Agreed, but it was a decision that was discussed in the community when
> it happened.
> 
>>
>> As I said, it's a minor issue.  There doesn't seem to be any need for
>> the overlap, so it's probably safe to retroactively change the rules
>> for STUN method registrations.
>>
> 
> I also think so. And, I think the minimal work needed here is to address
> STUN's IANA rules within the TRAM WG, not also change values in RFC
> 5764. Therefore I would like to reject this Errata.
> 
> I will give everyone two weeks to think this over and object against my
> proposal to reject the errata.
> 
> Cheers
> 
> Magnus Westerlund
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Jan 2015 13:29:55 +0100

Sorry, for confusing you.

I already sent another email on this. Lets go with the previous emails
Held for Document Update.

/Magnus

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 29 Jan 2015 21:38:50 -0500

Magnus Westerlund <[email-masked]> writes:
> I think a reasonable handling of this one would

This makes sense to me, but I think the following sentence is not as
informative as it needs to be:  "STUN messages with methods identifiers
of 1280 or higher cannot be demultiplexed."  The statement should tell
what happens, e.g., "STUN messages with method identifiers of 1280 or
higher are indistinguishable from ***, so such method identifiers must
be avoided when ***."

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Jan 2015 10:50:28 +0100

> higher are indistinguishable from ***, so such method identifiers must

Sounds good, if we prepare a replacement for the note, I believe the AD
can edit the Errata.

OLD NEW Text:

Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].
STUN messages with methods identifiers of 1280 or higher cannot
be demultiplexed.
...
                   |       B < 20  -+--> forward to STUN
...
If the value of this byte is less than 20, then the packet is STUN.

New NEW Text:
Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].
STUN messages with method identifiers of 1280 or higher are
indistinguishable from DTLS so such method identifiers must
be avoided when multiplexing the protocols on the same 5-tuple.
...
                   |       B < 20  -+--> forward to STUN
...
If the value of this byte is less than 20, then the packet is STUN.

END OF CHANGE

I also note that one potential critique to accepting it in the current
form, is the issue Cullen raised if we really should assign all of the
0-19 space to STUN or keep that space more limited.

Cheers

Magnus Westerlund