[Ballot comment]
I support Adam's DISCUSS.

Section 1.1: I'm surprised to see the two references to the long-expired NFVRG drafts. If a reference to describe virtualized infrastructure using orchestration is really needed (I'm not convinced that it is), I would assume a better reference exists from outside the IETF/IRTF.

Section 5.2:

OLD
"Encrypted mode 'makes it impossible to alter
              timestamps undetectably.' See also Section 4 of RFC 7717
              and Section 6 of RFC 4656."

NEW
"Encrypted mode 'makes it impossible to alter
              timestamps undetectably' [Section 6 of RFC 4656]. See also Section 4 of RFC 7717."
             
Process comment more for the AD: the YANG doctors reviewed a version of this more than a year ago. Is that typical or would they normally review again during IETF LC?

[Ballot discuss]
Thanks for the work and thought that everyone involved in this document spent. I
find the model well described and easy to understand.

I agree with Ben's comments about including more information about the privacy
and security properties of specific entities in the module. See
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines for specific
guidance.

Since this conflicts with normative language in RFC 6087 §3.4 (and 6087bis
§3.7), it is a blocking defect that needs to be remedied prior to publication.

[Ballot comment]
I applaud the use of UML in this document. I believe you need to include a
reference to ISO/IEC 19501:2005 (or the OMG equivalent); and, since the
diagrams appear to be normative, this reference probably needs to be
normative. It may be helpful (but less necessary) to also include a brief key
to the symbols used by this document, for those readers who may not be
familiar with UML notation.

---------------------------------------------------------------------------

§4.1:

>  Specifically, mode-preference-chain lists the
>  mode and its corresponding priority, expressed as a 16-bit unsigned
>  integer, where zero is the highest priority and subsequent integers
>  increase by one.

I think I know what this is trying to say, but it doesn't really say it.
Subsequent integers increase by one, by the definition of "integer," so I
don't think we need to reiterate that behavior here. Perhaps: "with zero as
the highest priority, and 65535 as the lowest."

---------------------------------------------------------------------------

Figure 6:

>  +----=--------------+
>  | session-reflector |
>  +-------------------+
>  | admin-state      |
>  | refwait          |
>  +-------------------+

Nit: the top line appears to have had an "=" character sneak in.

---------------------------------------------------------------------------

Page 81:

>            +--ro reflector-udp-port                  inet:port-numbe
>r
>            +--ro parent-connection-client-ip?        inet:ip-address
>            +--ro parent-connection-client-tcp-port?  inet:port-numbe
>r
>            +--ro parent-connection-server-ip?        inet:ip-address
>            +--ro parent-connection-server-tcp-port?  inet:port-numbe
>r

Wrapping the final character of the word "number" is probably not what you want
to happen here.

---------------------------------------------------------------------------

Page 34:

                  The configured (or auto-allocated) value is
                      advertized in the Sender Port field of the

Nit: "advertised"

---------------------------------------------------------------------------

Page 35:

>            leaf timeout {
>              type uint64;
>              units seconds;
>              default 2;
>              description
>                "The length of time (in seconds) that the
>                Session-Reflector should continue to respond to
>                packets belonging to this TWAMP-Test session after
>                a Stop-Sessions TWAMP-Control message has been
>                received.
>
>                This value will be placed in the Timeout field of
>                the Request-TW-Session message.";
>                                reference
>                "RFC 5357: TWAMP, Section 3.8";
>            }

This reference (Section 3.8 "Stop-Sessions") doesn't seem right. Perhaps
section 3.5 was intended? Possibly even section 3.5 of RFC 4656 would be more
appropriate.

---------------------------------------------------------------------------

Page 36:

>              type union {
>                type uint32 {
>                  range 0..4294967294;
>                }
>                type enumeration {
>                  enum forever {
>                    description
>                      "Indicates that the test session SHALL be
>                      repeated *forever* using the information in
>                      repeat-interval parameter, and SHALL NOT
>                      decrement the value.";
>                  }
>                }

If I had to guess here, the intention is to reserve the value 4294967295 for
"forever," but the model doesn't appear to do that. The preceding definition
defines "forever" as "0", which would appear to conflict with a repeat value
of 0. See RFC 7950 §9.6.4.2:

>  If a value is not specified, then one will be automatically assigned.
>  If the "enum" substatement is the first one defined, the assigned
>  value is zero (0); otherwise, the assigned value is one greater than
>  the current highest enum value (i.e., the highest enum value,
>  implicit or explicit, prior to the current "enum" substatement in the
>  parent "type" statement).

I think this should be:

                type enumeration {
                  enum forever {
                    value 4294967295;
                    description
                      "Indicates that the test session SHALL be
                        repeated *forever* using the information in
                        repeat-interval parameter, and SHALL NOT
                        decrement the value.";
                  }

---------------------------------------------------------------------------

The examples include the address "192.68.0.2" in several places. Please change
this to an address in one of the RFC 5737 ranges (e.g., 192.0.2.2).

[Ballot discuss]
I have three large areas of questions related to this model. They are not related to the contents of the module itself but to the broader scope of where this model can and should fit in the overall context of practical manageability and usability.

1. Operational state. Section 2 defines operational aspects of the configured TWAMP mechanisms as being out of scope. How does that relate to the motivation goals in section 1? Having no common machine readable mechanism for retrieving measurement results and verifying the operation of measurement processes does not seem to help in reducing the need for proprietary mechanisms.

2. What is the compatibility of this model with NMDA?

3. Key storage. The document defines its own way of storing keys - while there are multiple existing ways to store keys (routing key-chain model, I2NSF, IPsec model, netconf-keystore). Why yet another key storage mechanism is required? What could be reused from other existing mechanisms?

[Ballot comment]
RFC1305 is obsoleted by RFC5905.

A nit suggestion - YANG examples typically look more readable in JSON encoding.

IANA considerations section - likley the registrant contact should be the IESG and not the IPPM WG?

[Ballot discuss]
Operational state. Section 2 defines operational aspects of the configured TWAMP mechanisms as being out of scope. How does that relate to the motivation goals in section 1? Having no common machine readable mechanism for retrieving measurement results and verifying the operation of measurement processes does not seem to help in reducing the need for proprietary mechanisms.

If operational aspects are not out of scope, what is the compatibility of this model with NMDA?

Key storage. The document defines its own way of storing keys - while there are multiple existing ways to store keys (routing key-chain model, I2NSF, IPsec model, netconf-keystore). Why yet another key storage mechanism is required?

[Ballot comment]
It would be good if the yang model can be updated to refer to the NTPv4 specification (RFC5905) for the timestamps. It is currently referring to the obsolete NTPv3 specification (RFC1305 which is not listed in the references section) to describe the timestamp format.

[Ballot comment]
It would be good if the yang model can be updated to refer to the NTPv4 specification for the timestamps. It is currently referring to the obsolete NTPv3 specification (RFC1305 which is not listed in the references section) to describe the timestamp format.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3912



COMMENTS
S 6.1.
>      Figure 8 shows a configuration example for a Control-Client with
>      client/admin-state enabled.  In a real implementation following
>      Figure 2 this would permit the initiation of TWAMP-Control
>      connections and TWAMP-Test sessions.
> 
>      [note: '\' line wrapping is for formatting only]

Most of these examples do not contain any line wrapping.


S 7.
>        </twamp>
>     
> 
>  7.  Security Considerations
> 
>      The YANG module specified in Section 5 this document defines a schema

Some words about the threat model would be appreciated here. Is the
assumption that the two sender and the reflector are owned by whoever
runs the network and therefore they are not mounting an attack? If
not, what is the model?

[Ballot comment]
Substantive:

§7:

The security consideration lists a couple of examples of writeable nodes that might be vulnerable. I'd like to see an actual list of nodes thought to be vulnerable, along with a sentence or two describing the risks for each.

Are there no nodes that are privacy (or otherwise) sensitive when just readable?

Editorial:

- Title/abstract: It seems like there's a bit more than a data model here; there some normative behavior as well.

§3.3:
- first bullet: s/ "identical with " / "identical to "
- third bullet: "such as" and "for example" are redundant.

[Ballot comment]
[not balloting yet, but leaving this here because I noticed it and don't want it to get lost]

The examples include the address "192.68.0.2" in several places. Please change this to an address in one of the RFC 5737 ranges (e.g., 192.0.2.2).

[Ballot comment]
        bit unauth-test-encrpyt-control {

I think you probably mean "encrypt" above

          position 3;
          description
            "When using the Mixed Security Mode, the TWAMP-Test
              protocol follows the Unauthenticated mode and the
              TWAMP-Control protocol the Encrypted mode.";
          reference
            "RFC 5618: Mixed Security Mode for the Two-Way Active
              Measurement Protocol (TWAMP)";
        }

On pages 25-26:

    grouping key-management {
      list key-chain {
        key key-id;
        leaf key-id {
          type string {
            length 1..80;
          }
          description
            "KeyID used for a TWAMP-Control connection. As per
              Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
              80 octets in length' and is used to select which 'shared

This makes me slightly uncomfortable about possibility of truncating a UTF-8 encoding of some Unicode characters, but this probably doesn't matter in reality. Are these likely to be used for display?

              shared secret the [Control-Client] wishes to use to
              authenticate or encrypt'.";

[Ballot comment]
Perhaps I am confused and/or misreading things, but the descriptions
of the control-client and session-reflector include discussion of
'sid' session identifiers as if they were always used, but the mode
bitmap includes a separate bit for negotiation of
'individual-session-control' for session identifier usage.  Is there
some conflict between this mandatory/negotiable distinction, or are
they actually talking about different things?

Comments below in document order, but please pay special note to the
(potential) need for global uniqueness of key-ids, the PBKDF2
iteration count, and the list of sensitive nodes to call out in the
security considerations.


Section 3.1

  o  Authentication and encryption attributes such as KeyID, Token and
      the Client Initialization Vector (Client-IV); see also the last
      paragraph of Section 6 in OWAMP [RFC4656] and Randomness
      Requirements for Security [RFC4086].

I'm confused about what the RFC4656 reference is intended to call
out -- the reliance on AES to be resistant to chosen plaintext, or
the randomly generated challenge from the server, or the existential
forgeries?

  o  Information pertaining to the test packet stream, such as the test
      starting time, which performance metric is to be used Registry for
      Performance Metrics [I-D.ietf-ippm-metric-registry], or whether
      the test should be repeated.

Is there something missing before or around "Registry for
Performance Metrics"?  The current text is hard to read.

Section 3.4

  Each Session-Reflector is associated with zero or more TWAMP-Test
  sessions.  For each test session, the REFWAIT timeout parameter which
  determines whether to discontinue the session if no packets have been
  received (TWAMP [RFC5357], Section 4.2) can be configured.

nit: I think this would be easier to read if "which
determines...received" was offset by commas or parentheses.

  Read-only access to other data model parameters, such as the Sender
  IP address is foreseen.  Each test session can be uniquely identified
  by the 4-tuple mentioned in Section 3.2.

Nit: comma after "Sender IP address".

Section 4.1

  [...] Specifically, mode-preference-chain lists the
  mode and its corresponding priority, expressed as a 16-bit unsigned
  integer, where zero is the highest priority and subsequent integers
  increase by one.

I thought I remembered some discussion about this text being unclear
and removing "and subsequent integers increase by one" being
proposed.  But I don't see that discussion in an obvious place, so
maybe it was on a different document.

  Note that the list of preferred Modes may set bit position
  combinations when necessary, such as when referring to the extended
  [...]

Maybe "may set multiple bits independently" would be more clear?
But it seems that some bit combinations don't make any sense, like
unauthenticated+authenticated -- is there need for more expository
text here?

  [...] The secret-key is the shared secret, a sequence
  of octets of arbitrary length whose interpretation is unspecified.
  The key-id and secret-key encoding SHOULD follow Section 9.4 of YANG
  [RFC7950]. [...]

Section 9.4 of YANG is for (printable) strings, but the secret-key
is binary -- should this get a Section 9.8 reference as well?
I'm also not sure that leaving it as "arbitrary length"
is great -- if we're using it to derive 16-byte AES keys and 32-byte
HMAC-SHA1 keys, we could at least say "SHOULD contain at least 128
bits of entropy".

Section 4.2

  [...] The Server, being prepared to conduct
  sessions with more than one Control-Client, uses KeyIDs to choose the
  appropriate secret-key; a Control-Client would typically have
  different secret keys for different Servers. key-id tells the Server
  which shared-secret the Control-Client wishes to use for
  authentication or encryption.

Does this imply a global uniqueness requirement for key-ids?  If so,
that should be called out more clearly.

Section 4.3

                            | name                      |
                            | ctrl-connection-name {ro} |
                            | fill-mode                |
                            | number-of-packets        |
                            | state {ro}                |
                            | sent-packets        {ro} |
                            | rcv-packets          {ro} |
                            | last-sent-seq        {ro} |
                            | last-rcv-seq        {ro} |
                            +---------------------------+

nit: should the "{ro}" on "state" be right-aligned with the others?

Is there any privacy concern about exposing the parent-connection
4-tuple?

Section 5.2

In the 'count' leaf, a default value of 10 (corresponding to an
iteration count of 2^10 == 1024 for PBKDF2) is described.  This
seems quite low for a PBKDF2 iteration count, by modern standards.
In "normal" cryptographic protocols we would generally be using a
default closer to 32768 == 2^15 (which I see is the default *max*
count value, and there is additional discussion of the issue in the
leaf description for that leaf).  Perhaps one could make an argument
that this is just for test setups and the keys and data exchanged
are "not very valuable", but there is always risk of key sharing
across protocols, and my preference is to present the strong
defaults and give users the option to reduce where appropriate.
What are the authors' thoughts here?

Section 7

There are probably more nodes that can get called out as
particularly vulnerable, such as the count and max-count nodes that
can cause a long time to be spent on PBKDF2 iterations, the dscp
markings, the mode bitmask, etc.

Appendix A

The <secret-key> elements appear to be using base64-encoded values.
Where is it specified that such encoding is used for the binary
values?  (I assume this is just my ignorance of a generic standard,
so please enlighten me!)

Am I reading it right that the <count>30</count> means 2^30 (one
billion) PBKDF2 iterations?  Has this actually been run in practice?
It seems like it would be painfully slow.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ippm-twamp-yang-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-twamp
URI: urn:ietf:params:xml:ns:yang:ietf-twamp
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-twamp
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-twamp
Prefix: twamp
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for this new YANG module?

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the
    proper type of RFC?  Is this type of RFC indicated in the title page header?


This document is intended to be a Proposed Standard document.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:


Technical Summary

  This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).
  The TWAMP data model is described through Unified Modeling Language (UML) class diagrams and formally specified using YANG.

  The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to measure network performance parameters such as latency, bandwidth,
  and packet loss by sending probe packets and measuring their experience in the network.  To date, TWAMP implementations do not come
  with a standard management framework and, as such, configuration depends on proprietary mechanisms developed by the corresponding
  TWAMP vendor.  This document addresses this gap by formally specifying the TWAMP data model using YANG.


Working Group Summary

  This document was presented and discussed in IETF96, IETF97, IETF98 and IETF99.  There has also been discussion on the email list. 
  There were questions raised as to the inclusion of TWAMP Light in this document.  The consensus was that TWAMP Light is not
  adequately specified as a protocol.  This is the precursor to creating a YANG model.


Document Quality

  The document was reviewed and comments were provided in both the IETF meetings and on the IPPM WG mailing list.
  A YANG doctors review was requested for the YANG module in the document and it was provided by Jan Lindblad.


Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to
implement the specification?

  AT&T has an implementation.  Viavi was working on an implementation for testing Ethernet.
 
 

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion
that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the
case of a Media Type review, on what date was the request posted?


  A YANG doctors review was requested for the YANG module in the document and it was provided by Jan Lindblad.  A number of the suggestions were implemented.
 


Personnel

  The Document Shepherd is Nalini Elkins.  The Responsible Area Director is Spencer Dawkins.




(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready
    for publication, please explain why the document is being forwarded to the IESG.



  The document shepherd has followed the progression of the document through the WG and has reviewed the email chains as well as the review of the
  Yang doctor. As this time, it appears the document has addressed comments other than those regarding the inclusion of TWAMP Light, because there will
  be a separate document by the commentor to address TWAMP Light.  As a document shepherd I believe the document is ready for publication.

  There were quite a few comments from the Yang doctors.  I have verified that all comments were addressed. These include comments regarding
  the YANG model, stream characteristics, and operator commands.

 


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS,
    DHCP, XML, or internationalization? If so, describe the review that took place.


    This document is concerned with TWAMP and YANG.  Both areas have been addressed in detail.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those
concerns here.


I have no concerns


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.


  Yes, each author has so confirmed.


(8) Has an IPR disclosure been filed that references this document?  If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  Since this is a YANG model for RFC 5357, the IPR disclosed for TWAMP is applicable: https://datatracker.ietf.org/ipr/search/?rfc=5357&submit=rfc


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There appears to be rough consensus from that portion of the WG which is involved with TWAMP and YANG.  Not all WG members work in that area so
  they are silent. 



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


  No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.



Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 651 has weird spacing: '...riority    uin...'

  == Line 684 has weird spacing: '...m-index    uin...'




(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


  A YANG doctor review has been done.


(13) Have all references within this document been identified as either normative or informative?

  Yes


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?


  No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in
the Last Call procedure.

  See idnits



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


  No



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  This document registers a URI in the IETF XML registry [RFC3688].  The format is correct.




(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  There are no new IANA registries


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.



  YANG validation Passed:

From the Datatracker page, if you click on the Yin/YANG symbol, you get:

draft-ietf-ippm-twamp-yang-04.txt:
xym 0.4:
Extracting 'ietf-twamp@2017-02-22.yang'


ietf-twamp@2017-02-22.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.13.69: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i:
No validation errors

The following Last Call announcement was sent out (ends 2018-04-27):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: ippm-chairs@ietf.org, nalini.elkins@insidethestack.com, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org, Nalini Elkins <nalini.elkins@insidethestack.com>, spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-ippm-twamp-yang-07.txt> (Two-Way Active Measurement Protocol (TWAMP) Data Model) to Proposed Standard


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@ietf.org mailing lists by 2018-04-27. Exceptionally, comments may be
sent to iesg@ietf.org 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.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the
    proper type of RFC?  Is this type of RFC indicated in the title page header?


This document is intended to be a Internet Standard document.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:


Technical Summary

  This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).
  The TWAMP data model is described through Unified Modeling Language (UML) class diagrams and formally specified using YANG.

  The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to measure network performance parameters such as latency, bandwidth,
  and packet loss by sending probe packets and measuring their experience in the network.  To date, TWAMP implementations do not come
  with a standard management framework and, as such, configuration depends on proprietary mechanisms developed by the corresponding
  TWAMP vendor.  This document addresses this gap by formally specifying the TWAMP data model using YANG.


Working Group Summary

  This document was presented and discussed in IETF96, IETF97, IETF98 and IETF99.  There has also been discussion on the email list. 
  There were questions raised as to the inclusion of TWAMP Light in this document.  The consensus was that TWAMP Light is not
  adequately specified as a protocol.  This is the precursor to creating a YANG model.


Document Quality

  The document was reviewed and comments were provided in both the IETF meetings and on the IPPM WG mailing list.
  A YANG doctors review was requested for the YANG module in the document and it was provided by Jan Lindblad.


Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to
implement the specification?

  AT&T has an implementation.  Viavi was working on an implementation for testing Ethernet.
 
 

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion
that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the
case of a Media Type review, on what date was the request posted?


  A YANG doctors review was requested for the YANG module in the document and it was provided by Jan Lindblad.  A number of the suggestions were implemented.
 


Personnel

  The Document Shepherd is Nalini Elkins.  The Responsible Area Director is Spencer Dawkins.




(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready
    for publication, please explain why the document is being forwarded to the IESG.



  The document shepherd has followed the progression of the document through the WG and has reviewed the email chains as well as the review of the
  Yang doctor. As this time, it appears the document has addressed comments other than those regarding the inclusion of TWAMP Light, because there will
  be a separate document by the commentor to address TWAMP Light.  As a document shepherd I believe the document is ready for publication.

  There were quite a few comments from the Yang doctors.  I have verified that all comments were addressed. These include comments regarding
  the YANG model, stream characteristics, and operator commands.

 


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS,
    DHCP, XML, or internationalization? If so, describe the review that took place.


    This document is concerned with TWAMP and YANG.  Both areas have been addressed in detail.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those
concerns here.


I have no concerns


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.


  Yes, each author has so confirmed.


(8) Has an IPR disclosure been filed that references this document?  If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  Since this is a YANG model for RFC 5357, the IPR disclosed for TWAMP is applicable: https://datatracker.ietf.org/ipr/search/?rfc=5357&submit=rfc


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There appears to be rough consensus from that portion of the WG which is involved with TWAMP and YANG.  Not all WG members work in that area so
  they are silent. 



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


  No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.



Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 651 has weird spacing: '...riority    uin...'

  == Line 684 has weird spacing: '...m-index    uin...'

  -- The document date (August 22, 2017) is 16 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: draft-ietf-netconf-restconf has been published as
    RFC 8040





(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


  A YANG doctor review has been done.


(13) Have all references within this document been identified as either normative or informative?

  Yes


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?


  No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in
the Last Call procedure.

  See idnits



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


  No



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  This document registers a URI in the IETF XML registry [RFC3688].  The format is correct.




(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  There are no new IANA registries


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.



  YANG validation Passed:

From the Datatracker page, if you click on the Yin/YANG symbol, you get:

draft-ietf-ippm-twamp-yang-04.txt:
xym 0.4:
Extracting 'ietf-twamp@2017-02-22.yang'


ietf-twamp@2017-02-22.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.13.69: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i:
No validation errors

Request for posting confirmation emailed to previous authors: ippm-chairs@ietf.org, Mahesh Jethanandani <mjethanandani@gmail.com>, Reshad Rahman <rrahman@cisco.com>, Ruth Civil <gcivil@ciena.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Lianshu Zheng <vero.zheng@huawei.com>

Request for posting confirmation emailed to previous authors: "Al Morton" <acmorton@att.com>, "Lianshu Zheng" <vero.zheng@huawei.com>, "Ruth Civil" <gcivil@ciena.com>, "Reshad Rahman" <rrahman@cisco.com>, "Kostas Pentikousis" <k.pentikousis@travelping.com>, "Mahesh Jethanandani" <mjethanandani@gmail.com>