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." <daedulus@xxxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Cc: <ippm-chairs@xxxxxxxx>; <draft-ietf-ippm-twamp-yang@xxxxxxxx>;
<ippm@xxxxxxxx>
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" <iesg-secretary@xxxxxxxx>
> To: "IETF-Announce" <ietf-announce@xxxxxxxx>
> Cc: <ippm-chairs@xxxxxxxx>; <draft-ietf-ippm-twamp-yang@xxxxxxxx>;
> <ippm@xxxxxxxx>
> 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
> > ietf@xxxxxxxx mailing lists by 2018-04-27. Exceptionally, comments
may
> be
> > sent to iesg@xxxxxxxx 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.
> >
> >
> >
> >
>
