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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 May 2009 11:24:25 +0200

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.

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joel Jaeggli
Sent: Sunday, May 17, 2009 11:37 AM
To: [email-masked]
Subject: [OPS-DIR] Review of draft-ietf-ippm-more-twamp-01

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.

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

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.

---

From: Al Morton <[email-masked]>
Date: Sun, 17 May 2009 13:05:44 -0400

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

     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?

--------------------------------------------------------------------

>(e.g. 64) and the sum of the possible positions is significantly greater

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.

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

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 May 2009 10:31:08 -0700

Your proposed changes capture my observations.

joel

Al Morton wrote:
> 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,
> only by "IETF Review" as specified in RFC5226 (an RFC documenting
> monotonically increasing single bit positions and in the range [0-31],
> unless there is a good reason to do otherwise