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

[Al Morton <[e-mail]>]

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).