Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[[e-mail] (Dale R. Worley)]

My apologies for not responding to this sooner:

Marc Petit-Huguenin <[e-mail]> writes:
>> 17.1.  STUN Security Features Registry
>> 
>>    A STUN Security Feature set defines 24 bit as flags.
>> 
>>    IANA is requested to create a new registry containing the STUN
>>    Security Features that are protected by the bid down attack
>>    prevention mechanism described in section Section 9.2.1.
>> 
>>    The initial STUN Security Features are:
>> 
>>    Bit 0: Password algorithms
>>    Bit 1: Username anonymity
>>    Bit 2-23: Unassigned
>> 
>> Beware that the assignment of features to bits in the security feature
>> value has changed!  Bit numbers are assigned from the left/high-order
>> end -- see figure 2 in the draft.  So the *values* for these bits are:
>> 
>> 0x400000   Bit 0: Password algorithms
>> 0x200000   Bit 1: Username anonymity
>> 
>> But the values assigned in -15 were:
>> 
>>    0x000001: Password algorithms
>>    0x000002: Username anonymity
>
> Hmm, that was not the intent, and not how I read the text. Even in
> Figure 2 less significant bits are on the right.  So the intent is
> real tat bit0=0x001, bit1 = 0x002, and so on.  All we do is about
> interoperability, so I added some text that makes that less ambiguous.

(The latest posted version is still -16, so I haven't seen the changes
you refer to.)

In reference to the statements:

>>    The initial STUN Security Features are:
>> 
>>    Bit 0: Password algorithms
>>    Bit 1: Username anonymity
>>    Bit 2-23: Unassigned

I've skimmed the text again, and it appears that this passage is the
only one that allocates the functions "password algorithms" and
"username anonymity" to specific bits of the security feature value.
Thus, it's critical what "bit 0" means in this context.

Searching for "0" in the document, I can find no outright definition of
the meaning of "bit 0".  However, there are 10 figures in the document,
and 8 of them show the numbering of the bits of various fields, with bit
"0" being the *high-order*, *most-significant*, "left"-most bit of the
field, bit "1" the next-highest-order bit, etc.  This numbering seems to
be conventional in RFCs.

Thus, I recommend that if you really want to persist in calling the
low-order bit of the security features field "bit 0", you should explain
that very clearly in section 17.1.

Dale