Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-12-09 |
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-09-28 |
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-29 |
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-14 |
13 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-05-08 |
13 | Mirja Kühlewind | Shepherding AD changed to Mirja Kühlewind |
2018-07-13 |
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-07-13 |
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-07-13 |
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-07-11 |
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-07-11 |
13 | (System) | RFC Editor state changed to MISSREF |
2018-07-11 |
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-07-11 |
13 | (System) | Announcement was received by RFC Editor |
2018-07-11 |
13 | (System) | IANA Action state changed to In Progress |
2018-07-11 |
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-07-11 |
13 | Amy Vezza | IESG has approved the document |
2018-07-11 |
13 | Amy Vezza | Closed "Approve" ballot |
2018-07-11 |
13 | Amy Vezza | Ballot approval text was generated |
2018-07-11 |
13 | Amy Vezza | Ballot writeup was changed |
2018-07-11 |
13 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-07-10 |
13 | Spencer Dawkins | RFC Editor Note was changed |
2018-07-10 |
13 | Spencer Dawkins | RFC Editor Note was changed |
2018-07-10 |
13 | Spencer Dawkins | RFC Editor Note for ballot was generated |
2018-07-10 |
13 | Spencer Dawkins | RFC Editor Note for ballot was generated |
2018-07-02 |
13 | Adam Roach | [Ballot comment] Thanks for addressing my discuss and comments |
2018-07-02 |
13 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2018-07-02 |
13 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-13.txt |
2018-07-02 |
13 | (System) | New version approved |
2018-07-02 |
13 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-07-02 |
13 | Mahesh Jethanandani | Uploaded new revision |
2018-06-26 |
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-26 |
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-06-26 |
12 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-12.txt |
2018-06-26 |
12 | (System) | New version approved |
2018-06-26 |
12 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-06-26 |
12 | Mahesh Jethanandani | Uploaded new revision |
2018-06-26 |
11 | Ignas Bagdonas | [Ballot comment] Thank you for addressing DISCUSS comments. |
2018-06-26 |
11 | Ignas Bagdonas | [Ballot Position Update] Position for Ignas Bagdonas has been changed to No Objection from Discuss |
2018-06-21 |
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-06-21 |
11 | Alissa Cooper | [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 … [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? |
2018-06-21 |
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-06-21 |
11 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-06-20 |
11 | Adam Roach | [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. … [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. |
2018-06-20 |
11 | Adam Roach | [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 … [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). |
2018-06-20 |
11 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to Discuss from No Record |
2018-06-20 |
11 | Ignas Bagdonas | [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 … [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? |
2018-06-20 |
11 | Ignas Bagdonas | [Ballot comment] RFC1305 is obsoleted by RFC5905. A nit suggestion - YANG examples typically look more readable in JSON encoding. IANA considerations section - likley … [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? |
2018-06-20 |
11 | Ignas Bagdonas | Ballot comment and discuss text updated for Ignas Bagdonas |
2018-06-20 |
11 | Ignas Bagdonas | [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 … [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? |
2018-06-20 |
11 | Ignas Bagdonas | [Ballot comment] RFC1305 is obsoleted by RFC5905. |
2018-06-20 |
11 | Ignas Bagdonas | [Ballot Position Update] New position, Discuss, has been recorded for Ignas Bagdonas |
2018-06-20 |
11 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-06-20 |
11 | Suresh Krishnan | [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 … [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. |
2018-06-20 |
11 | Suresh Krishnan | Ballot comment text updated for Suresh Krishnan |
2018-06-20 |
11 | Suresh Krishnan | [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 … [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. |
2018-06-20 |
11 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-06-19 |
11 | Pete Resnick | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2018-06-19 |
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-06-19 |
11 | Eric Rescorla | [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 … [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? |
2018-06-19 |
11 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-06-19 |
11 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-06-19 |
11 | Ben Campbell | [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 … [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. |
2018-06-19 |
11 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-06-18 |
11 | Adam Roach | [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 … [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). |
2018-06-18 |
11 | Adam Roach | Ballot comment text updated for Adam Roach |
2018-06-18 |
11 | Alexey Melnikov | [Ballot comment] bit unauth-test-encrpyt-control { I think you probably mean "encrypt" above position 3; … [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'."; |
2018-06-18 |
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-06-18 |
11 | Benjamin Kaduk | [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 … [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. |
2018-06-18 |
11 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-06-18 |
11 | Mirja Kühlewind | [Ballot comment] High level question: How does this YANG model relate to the lmap YANG model (rfc8194)? |
2018-06-18 |
11 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-05-25 |
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-05-25 |
11 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-11.txt |
2018-05-25 |
11 | (System) | New version approved |
2018-05-25 |
11 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-05-25 |
11 | Mahesh Jethanandani | Uploaded new revision |
2018-05-25 |
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-05-25 |
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-05-23 |
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-05-23 |
10 | Amy Vezza | Placed on agenda for telechat - 2018-06-21 |
2018-05-23 |
10 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-05-23 |
10 | Spencer Dawkins | Ballot has been issued |
2018-05-23 |
10 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-05-23 |
10 | Spencer Dawkins | Created "Approve" ballot |
2018-05-23 |
10 | Spencer Dawkins | Ballot writeup was changed |
2018-05-22 |
10 | Martin Stiemerling | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2018-05-22 |
10 | Spencer Dawkins | Shepherding AD changed to Spencer Dawkins |
2018-05-21 |
10 | Cindy Morgan | Shepherding AD changed to Mirja Kühlewind |
2018-05-03 |
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-05-03 |
10 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-10.txt |
2018-05-03 |
10 | (System) | New version approved |
2018-05-03 |
10 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-05-03 |
10 | Mahesh Jethanandani | Uploaded new revision |
2018-04-30 |
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-04-27 |
09 | Victor Kuarsingh | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Victor Kuarsingh. Sent review to list. |
2018-04-27 |
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-04-26 |
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-04-26 |
09 | Sabrina Tanamal | (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 … (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 |
2018-04-25 |
09 | Adam Montville | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Adam Montville. Sent review to list. |
2018-04-23 |
09 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-09.txt |
2018-04-23 |
09 | (System) | New version approved |
2018-04-23 |
09 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-04-23 |
09 | Mahesh Jethanandani | Uploaded new revision |
2018-04-20 |
08 | Nalini Elkins | 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 … 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 |
2018-04-19 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2018-04-19 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2018-04-16 |
08 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-08.txt |
2018-04-16 |
08 | (System) | New version approved |
2018-04-16 |
08 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-04-16 |
08 | Mahesh Jethanandani | Uploaded new revision |
2018-04-16 |
07 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2018-04-12 |
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-04-12 |
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-04-11 |
07 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2018-04-11 |
07 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2018-04-10 |
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2018-04-10 |
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2018-04-09 |
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-04-09 |
07 | Amy Vezza | 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>, … 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. |
2018-04-09 |
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-04-08 |
07 | Spencer Dawkins | Last call was requested |
2018-04-08 |
07 | Spencer Dawkins | Ballot approval text was generated |
2018-04-08 |
07 | Spencer Dawkins | Ballot writeup was generated |
2018-04-08 |
07 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-04-08 |
07 | Spencer Dawkins | Last call announcement was changed |
2018-04-08 |
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-04-08 |
07 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-07.txt |
2018-04-08 |
07 | (System) | New version approved |
2018-04-08 |
07 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-04-08 |
07 | Mahesh Jethanandani | Uploaded new revision |
2018-03-29 |
06 | Spencer Dawkins | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-03-16 |
06 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
2018-03-15 |
06 | Brian Trammell | 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 … 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 |
2018-03-15 |
06 | Brian Trammell | Responsible AD changed to Spencer Dawkins |
2018-03-15 |
06 | Brian Trammell | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-03-15 |
06 | Brian Trammell | IESG state changed to Publication Requested |
2018-03-15 |
06 | Brian Trammell | IESG process started in state Publication Requested |
2018-03-15 |
06 | Brian Trammell | Changed consensus to Yes from Unknown |
2018-03-15 |
06 | Brian Trammell | Intended Status changed to Proposed Standard from None |
2018-02-13 |
06 | Mahesh Jethanandani | New version available: draft-ietf-ippm-twamp-yang-06.txt |
2018-02-13 |
06 | (System) | New version approved |
2018-02-13 |
06 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2018-02-13 |
06 | Mahesh Jethanandani | Uploaded new revision |
2017-11-12 |
05 | Brian Trammell | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-11-08 |
05 | Brian Trammell | Added to session: IETF-100: ippm Mon-0930 |
2017-10-19 |
05 | Reshad Rahman | New version available: draft-ietf-ippm-twamp-yang-05.txt |
2017-10-19 |
05 | (System) | New version approved |
2017-10-19 |
05 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2017-10-19 |
05 | Reshad Rahman | Uploaded new revision |
2017-10-17 |
04 | Nalini Elkins | Changed document writeup |
2017-08-28 |
04 | Bill Cerveny | Notification list changed to Nalini Elkins <nalini.elkins@insidethestack.com> |
2017-08-28 |
04 | Bill Cerveny | Document shepherd changed to Nalini Elkins |
2017-08-23 |
04 | Kostas Pentikousis | New version available: draft-ietf-ippm-twamp-yang-04.txt |
2017-08-23 |
04 | (System) | New version approved |
2017-08-23 |
04 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman <rrahman@cisco.com>, Al Morton <acmorton@att.com>, Kostas Pentikousis <k.pentikousis@travelping.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Ruth Civil <gcivil@ciena.com> |
2017-08-23 |
04 | Kostas Pentikousis | Uploaded new revision |
2017-03-24 |
03 | Brian Trammell | Added to session: IETF-98: ippm Mon-0900 |
2017-03-17 |
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Jan Lindblad. |
2017-03-17 |
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Jan Lindblad |
2017-03-17 |
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Jan Lindblad |
2017-03-17 |
03 | Mehmet Ersue | Requested Early review by YANGDOCTORS |
2017-02-22 |
03 | Kostas Pentikousis | New version available: draft-ietf-ippm-twamp-yang-03.txt |
2017-02-22 |
03 | (System) | New version approved |
2017-02-22 |
03 | (System) | 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 … 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> |
2017-02-22 |
03 | Kostas Pentikousis | Uploaded new revision |
2016-12-23 |
02 | Kostas Pentikousis | New version available: draft-ietf-ippm-twamp-yang-02.txt |
2016-12-23 |
02 | (System) | New version approved |
2016-12-23 |
02 | (System) | 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" … 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> |
2016-12-23 |
02 | Kostas Pentikousis | Uploaded new revision |
2016-11-09 |
01 | Bill Cerveny | Added to session: IETF-97: ippm Mon-1550 |
2016-07-08 |
01 | Kostas Pentikousis | New version available: draft-ietf-ippm-twamp-yang-01.txt |
2016-06-30 |
00 | Brian Trammell | Added to session: IETF-96: ippm Tue-1400 |
2016-03-21 |
00 | Al Morton | This document now replaces draft-cmzrjp-ippm-twamp-yang instead of None |
2016-03-21 |
00 | Al Morton | New version available: draft-ietf-ippm-twamp-yang-00.txt |