Subject: [ippm] 2nd WGLC for draft TWAMP Reflect Octets

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 02 Jun 2010 09:52:38 +0200

IPPM Group,

This is a second WGLC for the draft:

     TWAMP Reflect Octets and Symmetrical Size Features

A number of small issues were raised during the first WGLC.  This version
addresses them.  We'd like to give everybody a chance to confirm that the
comments have been correctly incorported.  Please raise any issues on the
draft by Monday June 14, 9:00 UTC.  An URL for the draft is:

   http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-reflect-octets/

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

I confirm today what I denied yesterday.            Anonymous Politician.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jun 2010 16:48:11 +0300

Summary: Good to go, modulo some IANA issues.

INTRODUCTION, paragraph 4:
>    The IETF has completed its work on the core specification of TWAMP -
>    the Two-Way Active Measurement Protocol.

  Suggest to remove statements that may change over time (like this one)
  before publication of this document as an archival RFC. (Same
  elsewhere in the document.)

Section 3.1., paragraph 1:
>    TWAMP connection establishment follows the procedure defined in
>    section 3.1 of [RFC4656] and section 3.1 of [RFC5357].  The new
>    features require two new bit positions (and values) to identify the
>    ability of the Server/Session-Reflector to reflect specific octets
>    back to the Control-Client/Session-Sender, and to support the new
>    Session-Sender packet format in TWAMP-Test Protocol.

  The entire remainder of Section 3.1 should IMO be merged into the IANA
  Considerations section, which duplicates much of this information
  already and is the usual place for it.

Section 3.4., paragraph 2:
>    With the publication of this memo as an RFC, the last 7 bit positions
>    of the Modes 32-bit Field are used.  A Control-Client conforming to
>    this extension of [RFC5357] MAY ignore the values in the higher bits
>    of the Modes Field, or it MAY support other features that are
>    communicated in those bit positions.  The other bits are available
>    for future protocol extensions.

  Do we really need to say this?

Section 4.1.3., paragraph 4:
>                        TWAMP-Test Padding Trucation

  Nit: s/Trucation/Truncation/

Section 6.1., paragraph 0:
> 6.1.  Registry Specification

  Section seems unneeded, given that the registry already exists.

Section 6.2., paragraph 0:
> 6.2.  Registry Management

  Section seems unneeded, given that the registry already exists.

Section 6.3., paragraph 0:
> 6.3.  Experimental Numbers

  Section seems unneeded, given that the registry already exists.

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 14 Jun 2010 12:01:39 +0200

IPPM group,

> draft by Monday June 14, 9:00 UTC. An URL for the draft is:

No issues have been raised, so this draft will be moved forward.

Henk

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Jun 2010 11:54:35 -0400

>Summary: Good to go, modulo some IANA issues.

Lars,

In version 07 (not yet submitted),
we've implemented most of your comments below.

The only exceptions (with our justification) are:

  - We left in the last paragraph of section 3.4, since we still
    think that a short heads-up to implementors is appreciated.

  - We combined the IANA material in that section, but didn't move
    any protocol requirements there, and kept section 6.1 as it has
    helped the IANA folks to understand our future plans for the registry.

Thanks for your comments, the IANA section continues to be a difficult
curve for us to negotiate at the end.

Regards,
Len and Al

>_______________________________________________
>ippm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ippm

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 28 Jun 2010 13:20:19 +0200

Al,

> we've implemented most of your comments below.

When do you plan to submit?

Henk

---

From: Al Morton <[email-masked]>
Date: Mon, 28 Jun 2010 08:51:39 -0400

>When do you plan to submit?
We were waiting to hear a reply, since we didn't agree with
a few comments, but as time is short for the deadline
we will post 07 shortly...

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 28 Jun 2010 16:01:35 +0200

> we will post 07 shortly...

Yes, please do post before the deadline for Maastricht.

Henk