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

[Magnus Westerlund <[e-mail]>]

Hi,

Regarding Errata ID: 3913

I am not certain that the current text is wrong. I think we need to dig
into this a bit more before deciding what to do.

So, to my understanding the following requirements do exists.

For STUN, a first byte value of 0 and 1 MUST be counted as STUN, as STUN
encodes the higher bit of the message class in the first bytes lowest
bit (bit 7). There already exist STUN messages with this bit set to 1.
Thus, B < 2 is absolutely correct.

We also know that DTLS uses byte values (B) of 20-63.

Formally this is a value overlap between what STUN could potentially use
(0-63) and what DTLS can potentially use 20-63.

However the reality is that it is unlikely that we ever is going to need
that many STUN messages. What we come down to is the question is how
much we want to restrict the future assignment of STUN messages. If we
assume B < 2 is correct, then RFC 5764 did restrict STUN messages to no
more than 128 methods per message class (This due to one bit in the
second byte of the STUN message is for message class).

If I remember correctly, I think the non specification of the B values
2-19 is actually intentional. The values assigned was only the ones that
was required, to not unnecessarily limit any future actions.

If one think this restriction on STUNs extension space is okay, and my
personal opinion is that it is more than sufficient. Then we reject this
errata.

If you are stongly in the camp that STUN should be allowed to use all
the way up to and including 19 of B values, then something must be done.
 Then the question comes if this is something an errata can change, i.e.
this was only a typo. If it can be determined that this was intentional
then I would say that an RFC update will be required to change this.

Regarding the STUN specification: Yes, it would be good to update the
IANA section to introduce the correct limit to future extension based on
DTLS-SRTP. But, that is not this WG's work, rather someone should take
this issue to TRAM and let them introduce that correction.

To conclude I have two questions:

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?

2. To Martin: What made you think there was an error in RFC 5764?


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