Subject: [ippm] RE: very drafty IANA section for twamp

From: "Hedayat, Kaynam" <[email-masked]>
Date: Fri, 28 Sep 2007 17:45:03 -0400

Mat,

Thank you for the text. To answer your questions:

- The authors have no objections to have 0 as reserved, generally this
is a good idea.
- I will add similar text as section 2 of OWAMP with regards to network
byte order.
- The case of headings in your text is consistent with the rest of the
document.
- We don't see a need to revise the initial paragraph.

Regards,
Kaynam & Al

> -----Original Message-----
> From: Matthew J Zekauskas [mailto:[email-masked]] 
> Sent: Monday, August 06, 2007 12:53 PM
> To: Hedayat, Kaynam
> Cc: Matt Zekauskas; IETF IPPM WG
> Subject: very drafty IANA section for twamp
> 
> 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
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm