Re: [AVTCORE] Errata on RFC 5764 : Errata ID: 3913

[Magnus Westerlund <[e-mail]>]

WG,

I decided that the WG recommendation for this Errata is HELD FOR
DOCUMENT UPDATE. The reason is that there is ongoing work both in
AVTCORE
(https://datatracker.ietf.org/doc/draft-petithuguenin-avtcore-rfc5764-mux-fixes/)
and in TRAM WG (With TURN IANA rules) in regards to this Errata.

Cheers

Magnus Westerlund

On 2015-01-29 13:29, Magnus Westerlund wrote:
> Sorry, for confusing you.
> 
> I already sent another email on this. Lets go with the previous emails
> Held for Document Update.
> 
> /Magnus
> 
> On 2015-01-29 13:28, Magnus Westerlund wrote:
>> 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 <[e-mail]> 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
>>>
>>> ----------------------------------------------------------------------
>>> Services, Media and Network features, Ericsson Research EAB/TXM
>>> ----------------------------------------------------------------------
>>> Ericsson AB                 | Phone  [phone]
>>> Färögatan 6                 | Mobile [phone]
>>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>>> ----------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>
>>
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------