Re: [ippm] Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard

[Joel Jaeggli <[e-mail]>]

Your proposed changes capture my observations.

joel

Al Morton wrote:
> Joel,
> thanks for your Sunday-morning comments,
> please see proposed resolutions in-line.
> Al
> 
> At 05:24 AM 5/17/2009, Romascanu, Dan (Dan) wrote:
>> Please find below the OPS-DIR review for draft-ietf-ippm-more-twamp
>> performed by Joel Jaeggli.
>>
>> Please consider these comments together with the other IETF LC comments.
>> ...
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Joel Jaeggli
>> Sent: Sunday, May 17, 2009 11:37 AM
>>
>> review for opsdir of:
>>
>> http://tools.ietf.org/html/draft-ietf-ippm-more-twamp-01
>>
>> section 4 -
>>
>>    "This section describes OPTIONAL extensions.  When the Server has
>>    identified the ability to support the mixed security mode, the
>>    Control-Client has selected the mixed security mode in its Set-Up-
>>    Response, and the Server responds with a zero Accept field in the
>>    Server-Start message, then these extensions are conditionally
>>    REQUIRED."
>>
>> When I read the introduction to section 4 the following statement, it
>> sent me scrambling for the other conditions that would make the above
>> statement required.
>>
>> It should be sufficient to say:
>>
>>    When the Server has identified the ability to support the mixed
>>    security mode, the Control-Client has selected the mixed security
>>    mode in its Set-Up-Response, and the Server responds with a zero
>>    Accept field in the Server-Start message, these extensions are
>>    REQUIRED.
> 
>     When the Server has identified the ability to support the mixed
>     security mode, the Control-Client has selected the mixed security
>     mode in its Set-Up-Response, and the Server responds with a zero
>     Accept field in the Server-Start message, then these extensions are
>     conditionally REQUIRED.                   ^^^^
>     ^^^^^^^^^^^^^
> So, we would delete the first sentence and the words marked in the
> paragraph above.
> 
> This tightens-up some text that we recently added to the draft.
> We would be depending on the OPTIONAL designation of this
> feature in section 2 (Scope) to cover the entire memo.
> 
> Your revisions work for me, does anyone else see a problem
> with Joel's paragraph above?
> 
> --------------------------------------------------------------------
> 
>> regarding 6.1 and 6.2 registry specification and management, 6.1 states:
>>         "Thus, this registry can contain a total of 32 possible bit
>>         positions and corresponding values."
>>
>> Certainly while there are 32 bits in the field, each has two states
>> (e.g. 64) and the sum of the possible positions is significantly greater
>> than 32 e.g. 2^32
> 
> TWAMP has inherited a partial set of bit position assignments,
> and this memo assigns what is likely to be that "last" mutually
> exclusive Mode/bit position (as a command from the Control-Client).
> 
> But Future Modes/bit positions will designate features that
> WILL be used in combination with one of the four Security Modes.
> And, if we start to run out of bit positions, the likely strategy
> would be to use an octet or more in combinations.
> 
> 
>> 6.2 states:
>>
>>    For the TWAMP-Modes registry, we expect that new features will be
>>    assigned using monotonically increasing bit positions and in the
>>    range [0-31] and the corresponding values, unless there is a good
>>    reason to do otherwise.
>>
>> at some future date values in the registry for some bit positions might
>> be encoded in some more complex fashion.
> 
> Right. So let's allow that from the start.
> 
> 6.1  OLD
>    ... Modes are indicated by setting bits in the 32-bit Modes Field.
>        Thus, this registry can contain a total of 32 possible bit
>        positions and corresponding values.
> 
> 6.1  NEW
>    ... Modes are currently indicated by setting single bits in the
> 32-bit Modes Field. However, more complex encoding may be used in the
> future. Thus, this registry can contain a total of 2^32 possible
> assignments.
> 
> ---------------------------------
> (the revision below also addresses Amanda Barber's LC-comment,
> representing IANA)
> 
> 6.2  OLD
> 
> Because the TWAMP-Modes registry can contain only thirty-two values, and
> because TWAMP is an IETF protocol, this registry must be updated only by
> "IETF Consensus" as specified in RFC5226 (an RFC documenting registry
> use that is approved by the IESG). For the TWAMP-Modes registry, we
> expect that new features will be assigned using monotonically increasing
> bit positions and in the range [0-31] and the corresponding values,
> unless there is a good reason to do otherwise.
> 
> 6.2  NEW
> 
> Because the TWAMP-Modes registry can contain a maximum of 2^32 values,
> and because TWAMP is an IETF protocol, this registry must be updated
> only by "IETF Review" as specified in RFC5226 (an RFC documenting
> registry use that is approved by the IESG). For the TWAMP-Modes
> registry, we expect that new features will be assigned using
> monotonically increasing single bit positions and in the range [0-31],
> unless there is a good reason to do otherwise
> (more complex encoding than single bit positions may be used in the
> future, to access the 2^32 value space).
>