[ippm] very drafty IANA section for twamp

[Matthew J Zekauskas <matt at internet2.edu>]

Here is my initial public cut on the text for TWAMP. I still have some
questions, and perhaps working group members have an opinion (or better
way to state some of the text).

If it does not already do so, perhaps we should say somewhere
"TWAMP-Control" is an update of OWAMP-Control for two-way measurements,
rather than just calling it "TWAMP-Control".  I think it might even say
that somewhere...  [this is a question from me]


x == 8 in the current draft:


--=== begin text ===--

x. IANA Considerations

IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also
applies to the TWAMP-Control part of the TWAMP protocol.

Since TWAMP adds an additional OWAMP-Control command to the OWAMP-Control
specification, and describes behavior when this control command is
used, we will create an IANA registry for this field.  The field is
not explicitly named in [RFC4656] but is called out for each command.

x.1 Registry Specification

IANA will create an OWAMP-Control Command registry.  OWAMP-Control
commands are specified by the first octet in OWAMP-Control messages as
shown in section 3.4 of [RFC4656], and modified by this document.
Thus this registry may contain sixteen possible values.

x.2 Registry Management

Because the registry may only contain sixteen values, and because
OWAMP and TWAMP are IETF protocols, this registry must only be updated
by "IETF Consensus" as specified in [RFC2434] -- an RFC documenting
the use that is approved by the IESG.  We expect that new values will
be assigned as monotonically increasing integers in the range [0-15],
unless there is a good reason to do otherwise.


x.3 Experimental Numbers

[RFC3692] recommends allocating an appropriate number of values for
experimentation and testing.  It is not clear to the authors exactly
how many might be useful in this space, nor if it would be useful that
they were easily distinguishable or at the "high end" of the number
range.  Two might be useful, say one for session control, and one for
session fetch.  On the other hand, a single number would allow for
unlimited extension, because the format of the rest of the message
could be tailored, with allocation of other numbers done once usefulness
has been proven.  Thus, this document will allocate one number, the
next sequential number 6, as designated for experimentation and
testing.

x.4 Initial Registry Contents

OWAMP-Control Command Registry

Value  Description             Semantics Definition
0      Reserved
1      Request-Session         RFC4656, Section 3.5
2      Start-Sessions          RFC4656, Section 3.7
3      Stop-Sessions           RFC4656, Section 3.8
4      Fetch-Session           RFC4656, Section 3.9
5      Request-TW-Session      this document, Section 3.5
6      Experimentation         undefined, see Section x.3.

--=== end text ===--

New Normative Reference: Guidelines for IANA Considerations, RFC 2434/BCP 26
New Informative Reference: Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692/BCP 82

Other questions and issues:

* should we have 0 as reserved?
* any need to mention "network byte order" here in this document?
* is the case of the headings consistent with the rest of the document?
* does the initial para need a revision?  it is carried over from the
current draft.

* we should probably write an Errata request for 4656 that points to
this document, so there is a forward reference.

--Matt









_______________________________________________
ippm mailing list
ippm at ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm