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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------