Re: [ippm] Last Call: <draft-ietf-ippm-twamp-yang-07.txt> (Two-Way Active Measurement Protocol (TWAMP) Data Model) to Proposed Standard

["tom p." <[e-mail]>]

Some further thoughts on this I-D; I have included the earlier ones (as
yet unanswered) below.

typedef test-session-state {
     .....
             "Indicates that accepted TWAMP-Test session request.";

something seems to have been omitted.


leaf reflector-udp-port {
               type uint32 {
                 range "862 | 49152..65535";
I am puzzled as to why uint32 is used and inet:port-number is not used
here (happens in two places)


"Reusable data structure for count which is used both in the Server
container.";

'both' suggests to me that there should be a second clause.


"grouping max-count {
       leaf max-count {
         type uint8 {
           range 10..31;
         }
         default 15;"
contradicts
" ...The default max-count value SHOULD be 32768.'
32768 is outside the range!

I think that your problem here is that other TWAMP documentation, such
as the RFC that you quote and reference uses 'max-count' to mean a 32
bit value but here you are reusing the term with a different semantic
and using it to mean an exponent; rename the object to make it clear
that it is an exponent and not a count e.g. max-count-exp. This occurs
in several places.

"container session-sender {
         if-feature session-sender;
         presence  "Enables TWAMP Session-Sender functionality.";
         description
           "Configuration of the TWAMP Session-Sender logical entity";
         leaf admin-state {
           type boolean;
           mandatory true;
           description
             "Indicates whether the device is allowed to operate
              as a TWAMP Session-Sender.";
"

A presence container is a boolean so I am unclear what it is that the
admin-state boolean adds here since the presence container "Enables
TWAMP Session-Sender functionality.";

"     container session-reflector {
"
same story here

Tom Petch

----- Original Message -----
From: "tom p." <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Wednesday, April 11, 2018 12:40 PM


> Some mostly administrative points on this I-D
>
> [I-D.ietf-ippm-metric-registry] is an Informative Reference so would
not
> hold up the production of this as an RFC yet you ask that the text be
> replaced by the RFC number which implies that you do want it held up.
I
> did ask the RFC Editor about this and yes, they would expect to catch
it
> but it would seem simpler if this could be a Normative Reference.  You
> do have the statement up front about replacing the text with the RFC
> number and yes, the RFC Editor like that.
>
> There is no reference, no legend,  for Tree Diagrams in 5.1 .  There
is
> now an RFC on this, RFC 8340 while RFC8343 s.1.3 is an example of how
to
> reference this RFC.
>
> There is no copyright statement in the YANG module as is required by
> 6087bis (please, IESG, make this an RFC soon:-)
>
> leaf server-start-time {
> includes
>                 The timestamp format follows RFC 1305
> but I see no RFC 1305 in the references of the I-D
>
> leaf reflector-udp-port
> " The default number is
>                   within to the dynamic port range and  .. "
> which is not quite English.
>
> "The new well-known port (862) MAY be used.";
> This was allocated in 2008 which seems to stretch the meaning of 'new'
>
>  leaf secret-key {
>              type binary;
> I wonder about the choice of binary; elsewhere, e.g. RFC8177,
> hexadecimal is used.
> Are there, should there be, any length constraints on this key?
>
>  case poisson {
> ...
>    reference
>                   "RFC 2330: Framework for IP Performance Metrics";
> RFC2330 I cannot see in the references for the I-D
>
> The Security Considerations are not as per the current template e.g.
no
> mention of RESTCONF
>
> Tom Petch
>
> ----- Original Message -----
> From: "The IESG" <[e-mail]>
> To: "IETF-Announce" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Sent: Monday, April 09, 2018 3:57 PM
>
> > The IESG has received a request from the IP Performance Measurement
WG
> (ippm)
> > to consider the following document: - 'Two-Way Active Measurement
> Protocol
> > (TWAMP) Data Model'
> >   <draft-ietf-ippm-twamp-yang-07.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > comments on this action. Please send substantive comments to the
> > [e-mail] mailing lists by 2018-04-27. Exceptionally, comments
may
> be
> > sent to [e-mail] instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    This document specifies a data model for client and server
> >    implementations of the Two-Way Active Measurement Protocol
(TWAMP).
> >    We define the TWAMP data model through Unified Modeling Language
> >    (UML) class diagrams and formally specify it using YANG.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
>