Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
draft-ietf-lime-yang-connectionless-oam-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-16
|
18 | Alissa Cooper | Shepherding AD changed to Ignas Bagdonas |
2019-03-20
|
18 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-02-04
|
18 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-01-23
|
18 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-01-14
|
18 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-11-07
|
18 | (System) | RFC Editor state changed to EDIT from MISSREF |
2017-12-19
|
18 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2017-11-27
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-11-22
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-11-22
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-11-14
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2017-11-14
|
18 | (System) | IANA Action state changed to Waiting on Authors from On Hold |
2017-11-14
|
18 | (System) | IANA Action state changed to On Hold from In Progress |
2017-11-14
|
18 | (System) | IANA Action state changed to In Progress |
2017-11-14
|
18 | (System) | RFC Editor state changed to MISSREF |
2017-11-14
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-11-14
|
18 | (System) | Announcement was received by RFC Editor |
2017-11-14
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-11-14
|
18 | Amy Vezza | IESG has approved the document |
2017-11-14
|
18 | Amy Vezza | Closed "Approve" ballot |
2017-11-14
|
18 | Amy Vezza | Ballot approval text was generated |
2017-11-14
|
18 | Amy Vezza | Ballot writeup was changed |
2017-11-14
|
18 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2017-11-13
|
18 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-18.txt |
2017-11-13
|
18 | (System) | New version approved |
2017-11-13
|
18 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-11-13
|
18 | Qin Wu | Uploaded new revision |
2017-11-12
|
17 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-17.txt |
2017-11-12
|
17 | (System) | New version approved |
2017-11-12
|
17 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-11-12
|
17 | Qin Wu | Uploaded new revision |
2017-11-12
|
17 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-11-12
|
17 | Qin Wu | Uploaded new revision |
2017-10-30
|
16 | Alia Atlas | [Ballot comment] Thank you very much for handling my Discuss so well and promptly. I am clearing based on the changes in version -16. I've … [Ballot comment] Thank you very much for handling my Discuss so well and promptly. I am clearing based on the changes in version -16. I've left the comments and Discuss below for clearer history. ==================== I took a quick look through version -15 and it looks like it addresses almost all of my serious Discuss points. The only Discuss-worthy point is (c) below. I have a few more points related to the changes that were made; they are just comments & listed here to be with the original points. For version 15: a) In Sec 3.1, it still says " o Router-id to represent the device or node. [I-D.ietf-spring-sr-yang]" but [I-D.ietf.spring-sr-yang] has nothing to do with the router-id b) In Section 4, thanks for adding urn:ietf:params:xml:ns:yang:ietf-lime-common-types - but could it be a meaningful and accurate name like ietf-lime-time-types or ietf-time-types (Benoit would know best structure) that clearly shows its intended scope for reuse and please fix the description for it too. c) [I-D.ietf-rtgwg-ni-model] is still listed as informative, but the model defined in there is imported "import ietf-network-instance { prefix ni; }" It needs to be normative d) I-D.ietf-spring-sr-yang is still listed as informative - but not really correctly used as a reference. ================= Thank you for your work on this document. I have a number of serious concerns - but they all amount to fixing up your references and slight restructuring for clarity and reuse. 1) In Sec 3.1, the reference is system-id to represent the device or node.[I-D.ietf-spring-sr-yang] I believe that should be "typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; }" from draft-ietf-rtgwg-routing-types. Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency. I see that this document actually redefines router-id, instead of using it as part of the included import from import ietf-routing-types { prefix rt; } On p.27, I see "leaf system-id { type rt:router-id; description "System ID assigned to this node."; }" so it is using the routing-yang-types, but renaming it as system-id, there. Consistency isn't just the hobgoblin of little minds - it's actually useful. In choice to-location, again "case system-id { leaf system-id-location { type router-id; description "System id location"; } description "System ID";" using the locally defined router-id and renaming it instead of using rt:router-id. 2) On p. 13 & 14, there are many identities associated with time and time-stamps. I cannot believe that the best way to handle these is by having them as part of an OAM model! At a minimum, they should be defined as a separate module and then included, even if it is in the same draft. Then they will be available for reuse elsewhere. 3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference. 4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields that are labeled NI without adequate description. 5) [I-D.ietf-rtgwg-routing-types] is not an informative reference. Its module is imported and used. It must be normative. 6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative. Instead, I believe this can be removed as a reference. ============================== a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics} instead of hardcoded members for IPv4 and IPv6 traffic only. While it can still be extended for additional traffic types, the naming may be inconsistent and there's no requirement that the contents are cc-session-statistics. b) On p.9: " +--:(system-id) | +--rw system-id-location? router-id" Why isn't this just named router-id instead of system-id, for consistency? This comment applies throughout the draft. c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which uses "tp" for termination-point. d) On p. 13: "identity address-attribute-types { description "This is base identity of address attribute types which are ip-prefix, bgp, tunnel, pwe3, vpls, etc."; }" I haven't a clue what is meant by a bgp address attribute type or a tunnel one. Can you please expand the description to be substantially more meaningful? How is it used? On p. 24, I see these defined " case bgp { leaf bgp { type inet:ip-prefix; description "BGP Labeled Prefix "; } } case tunnel { leaf tunnel-interface { type uint32; description "VPN Prefix "; } } case pw { leaf remote-pe-address { type inet:ip-address; description "Remote pe address."; } " but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms. e) "grouping tp-address-ni " Please expand what NI is the abbreviation for in the description. |
2017-10-30
|
16 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to Yes from Discuss |
2017-10-30
|
16 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-16.txt |
2017-10-30
|
16 | (System) | New version approved |
2017-10-30
|
16 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-10-30
|
16 | Qin Wu | Uploaded new revision |
2017-10-30
|
15 | Alia Atlas | [Ballot discuss] I took a quick look through version -15 and it looks like it addresses almost all of my serious Discuss points. The only … [Ballot discuss] I took a quick look through version -15 and it looks like it addresses almost all of my serious Discuss points. The only Discuss-worthy point is (c) below. I have a few more points related to the changes that were made; they are just comments & listed here to be with the original points. For version 15: a) In Sec 3.1, it still says " o Router-id to represent the device or node. [I-D.ietf-spring-sr-yang]" but [I-D.ietf.spring-sr-yang] has nothing to do with the router-id b) In Section 4, thanks for adding urn:ietf:params:xml:ns:yang:ietf-lime-common-types - but could it be a meaningful and accurate name like ietf-lime-time-types or ietf-time-types (Benoit would know best structure) that clearly shows its intended scope for reuse and please fix the description for it too. c) [I-D.ietf-rtgwg-ni-model] is still listed as informative, but the model defined in there is imported "import ietf-network-instance { prefix ni; }" It needs to be normative d) I-D.ietf-spring-sr-yang is still listed as informative - but not really correctly used as a reference. ================= Thank you for your work on this document. I have a number of serious concerns - but they all amount to fixing up your references and slight restructuring for clarity and reuse. 1) In Sec 3.1, the reference is system-id to represent the device or node.[I-D.ietf-spring-sr-yang] I believe that should be "typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; }" from draft-ietf-rtgwg-routing-types. Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency. I see that this document actually redefines router-id, instead of using it as part of the included import from import ietf-routing-types { prefix rt; } On p.27, I see "leaf system-id { type rt:router-id; description "System ID assigned to this node."; }" so it is using the routing-yang-types, but renaming it as system-id, there. Consistency isn't just the hobgoblin of little minds - it's actually useful. In choice to-location, again "case system-id { leaf system-id-location { type router-id; description "System id location"; } description "System ID";" using the locally defined router-id and renaming it instead of using rt:router-id. 2) On p. 13 & 14, there are many identities associated with time and time-stamps. I cannot believe that the best way to handle these is by having them as part of an OAM model! At a minimum, they should be defined as a separate module and then included, even if it is in the same draft. Then they will be available for reuse elsewhere. 3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference. 4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields that are labeled NI without adequate description. 5) [I-D.ietf-rtgwg-routing-types] is not an informative reference. Its module is imported and used. It must be normative. 6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative. Instead, I believe this can be removed as a reference. |
2017-10-30
|
15 | Alia Atlas | [Ballot comment] ============================== a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics} instead of hardcoded members … [Ballot comment] ============================== a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics} instead of hardcoded members for IPv4 and IPv6 traffic only. While it can still be extended for additional traffic types, the naming may be inconsistent and there's no requirement that the contents are cc-session-statistics. b) On p.9: " +--:(system-id) | +--rw system-id-location? router-id" Why isn't this just named router-id instead of system-id, for consistency? This comment applies throughout the draft. c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which uses "tp" for termination-point. d) On p. 13: "identity address-attribute-types { description "This is base identity of address attribute types which are ip-prefix, bgp, tunnel, pwe3, vpls, etc."; }" I haven't a clue what is meant by a bgp address attribute type or a tunnel one. Can you please expand the description to be substantially more meaningful? How is it used? On p. 24, I see these defined " case bgp { leaf bgp { type inet:ip-prefix; description "BGP Labeled Prefix "; } } case tunnel { leaf tunnel-interface { type uint32; description "VPN Prefix "; } } case pw { leaf remote-pe-address { type inet:ip-address; description "Remote pe address."; } " but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms. e) "grouping tp-address-ni " Please expand what NI is the abbreviation for in the description. |
2017-10-30
|
15 | Alia Atlas | Ballot comment and discuss text updated for Alia Atlas |
2017-10-28
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-10-28
|
15 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-15.txt |
2017-10-28
|
15 | (System) | New version approved |
2017-10-28
|
15 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-10-28
|
15 | Qin Wu | Uploaded new revision |
2017-10-26
|
14 | Warren Kumari | [Ballot comment] I fully agree with the readability comments - it needs a good editorial pass, and I feel it is unfair to give to … [Ballot comment] I fully agree with the readability comments - it needs a good editorial pass, and I feel it is unfair to give to the RFC Editor without one. |
2017-10-26
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-10-26
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-10-25
|
14 | Benoît Claise | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-10-25
|
14 | Ben Campbell | [Ballot comment] I have some mostly editorial comments: - I agree with Adam's comments about readability. Please also consider an editing pass for grammar--I noted … [Ballot comment] I have some mostly editorial comments: - I agree with Adam's comments about readability. Please also consider an editing pass for grammar--I noted some missing articles, plural disagreement, etc. - Please check IDNits. It has some complaints about references. I will leave it to the authors to determine if they are real. -1, paragraph starting with "The different OAM tools...": The phrase "After the connection is established" is missing an article. -2.2: "RPC operation - A specific Remote Procedure Call.": That seems like a circular definition. -3, first paragraph: 'The model augments "/networks/network/node" path...': missing article. -3.1, 6th paragraph: "... these parameters are not explicit configured": s/explicit/explicitly -5.2.1.2, 2nd paragraph: s/user/users -6, third paragraph: " writable/creatable/deletable": Please don't use "/" as a substitute for conjunctions. |
2017-10-25
|
14 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-10-25
|
14 | Alissa Cooper | [Ballot comment] Update: It seems the Gen-ART comments concerning the summary of the imported modules and their sources and the timestamps still need to be … [Ballot comment] Update: It seems the Gen-ART comments concerning the summary of the imported modules and their sources and the timestamps still need to be addressed. Sorry for missing this in my original ballot. |
2017-10-25
|
14 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2017-10-25
|
14 | Adam Roach | [Ballot comment] I'd like to update my comment with some fairly mechanical suggestions for improvement that I believe will increase readability of the document greatly. … [Ballot comment] I'd like to update my comment with some fairly mechanical suggestions for improvement that I believe will increase readability of the document greatly. In evaluating this document, I found a number of minor formatting issues that made it somewhat difficult to read. 1. Please ensure that all opening parentheses have a space before them and no space after them. 2. Please ensure that all closing parentheses have a space after them and no space before after them. 3. Please ensure that all quoted terms include both an opening quotation mark and a closing quotation mark. 4. Please ensure that there are no spaces between a quotation mark and the term it is quoting. 5. Please ensure that there *is* a space before an opening quotation mark 6. Please ensure that there *is* a space after a closing quotation mark (unless followed by another punctuation mark) 7. Please ensure that periods at the end of a sentence have no space before them and a space after them. 8. Please break up long paragraphs into separate paragraphs or bullet lists. The third paragraph of section 3 and the paragraph that forms section 3.3 are prime candidates for such an improvement. 9. Please double-check the formatting of the YANG module. The indentation is inconsistent and, in some places, can easily mislead the reader about the level of nesting and association of elements with each other. My original comments follow. ------------------------------------------------------------ Please expand "EXP", "VPLS", and "LAG" on first use. Section 3.2 refers to the "lime base model". Please define or expand "lime" or provide a citation that does so. The id-nits tool reports that there are 6 instances of overly-long lines in the document. Given that these exist in code elements, the authors can probably make better decisions about how to resolve these than the RFC editor can. Section 3.3 contains the following definition: list oam-neighboring-tps { key "index"; leaf index { type uint16 { range "0..65536"; } uint16 cannot represent 65536. ---------------------------------------- Later in the model: container timestamp-80bit { when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{ description "Only applies when 80bit PTP Timestamp."; } if-feature ptp-long-format; leaf timestamp-sec { type uint64 { range "0..281474976710656"; } description "48bit Timestamp in seconds as per IEEE1588v2."; } leaf timestamp-nanosec { type uint32; description "Fractional part in nanoseconds as per IEEE1588v2 or Fractional part in 64-bit NTP timestamp."; } description "Container for 64bit timestamp."; } Issue 1: The 48-bit range should be 0..281474976710655, not 0..281474976710656 Issue 2: The description for this 80-bit timestamp container contains a description of "Container for 64bit timestamp." ---------------------------------------- Similar to issue 2 above, ntp-timestamp-32bit describes itself as a 64-bit timestamp. |
2017-10-25
|
14 | Adam Roach | Ballot comment text updated for Adam Roach |
2017-10-25
|
14 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-10-25
|
14 | Alia Atlas | [Ballot discuss] Thank you for your work on this document. I have a number of serious concerns - but they all amount to fixing up … [Ballot discuss] Thank you for your work on this document. I have a number of serious concerns - but they all amount to fixing up your references and slight restructuring for clarity and reuse. 1) In Sec 3.1, the reference is system-id to represent the device or node.[I-D.ietf-spring-sr-yang] I believe that should be "typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; }" from draft-ietf-rtgwg-routing-types. Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency. I see that this document actually redefines router-id, instead of using it as part of the included import from import ietf-routing-types { prefix rt; } On p.27, I see "leaf system-id { type rt:router-id; description "System ID assigned to this node."; }" so it is using the routing-yang-types, but renaming it as system-id, there. Consistency isn't just the hobgoblin of little minds - it's actually useful. In choice to-location, again "case system-id { leaf system-id-location { type router-id; description "System id location"; } description "System ID";" using the locally defined router-id and renaming it instead of using rt:router-id. 2) On p. 13 & 14, there are many identities associated with time and time-stamps. I cannot believe that the best way to handle these is by having them as part of an OAM model! At a minimum, they should be defined as a separate module and then included, even if it is in the same draft. Then they will be available for reuse elsewhere. 3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference. 4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields that are labeled NI without adequate description. 5) [I-D.ietf-rtgwg-routing-types] is not an informative reference. Its module is imported and used. It must be normative. 6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative. Instead, I believe this can be removed as a reference. |
2017-10-25
|
14 | Alia Atlas | [Ballot comment] a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics} instead of hardcoded members for … [Ballot comment] a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics} instead of hardcoded members for IPv4 and IPv6 traffic only. While it can still be extended for additional traffic types, the naming may be inconsistent and there's no requirement that the contents are cc-session-statistics. b) On p.9: " +--:(system-id) | +--rw system-id-location? router-id" Why isn't this just named router-id instead of system-id, for consistency? This comment applies throughout the draft. c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which uses "tp" for termination-point. d) On p. 13: "identity address-attribute-types { description "This is base identity of address attribute types which are ip-prefix, bgp, tunnel, pwe3, vpls, etc."; }" I haven't a clue what is meant by a bgp address attribute type or a tunnel one. Can you please expand the description to be substantially more meaningful? How is it used? On p. 24, I see these defined " case bgp { leaf bgp { type inet:ip-prefix; description "BGP Labeled Prefix "; } } case tunnel { leaf tunnel-interface { type uint32; description "VPN Prefix "; } } case pw { leaf remote-pe-address { type inet:ip-address; description "Remote pe address."; } " but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms. e) "grouping tp-address-ni " Please expand what NI is the abbreviation for in the description. |
2017-10-25
|
14 | Alia Atlas | [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas |
2017-10-25
|
14 | Alissa Cooper | [Ballot comment] Thanks for addressing the Gen-ART review comments. |
2017-10-25
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-10-25
|
14 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-10-24
|
14 | Adam Roach | [Ballot comment] Please expand "EXP", "VPLS", and "LAG" on first use. Section 3.2 refers to the "lime base model". Please define or expand "lime" or … [Ballot comment] Please expand "EXP", "VPLS", and "LAG" on first use. Section 3.2 refers to the "lime base model". Please define or expand "lime" or provide a citation that does so. The id-nits tool reports that there are 6 instances of overly-long lines in the document. Given that these exist in code elements, the authors can probably make better decisions about how to resolve these than the RFC editor can. Section 3.3 contains the following definition: list oam-neighboring-tps { key "index"; leaf index { type uint16 { range "0..65536"; } uint16 cannot represent 65536. ---------------------------------------- Later in the model: container timestamp-80bit { when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{ description "Only applies when 80bit PTP Timestamp."; } if-feature ptp-long-format; leaf timestamp-sec { type uint64 { range "0..281474976710656"; } description "48bit Timestamp in seconds as per IEEE1588v2."; } leaf timestamp-nanosec { type uint32; description "Fractional part in nanoseconds as per IEEE1588v2 or Fractional part in 64-bit NTP timestamp."; } description "Container for 64bit timestamp."; } Issue 1: The 48-bit range should be 0..281474976710655, not 0..281474976710656 Issue 2: The description for this 80-bit timestamp container contains a description of "Container for 64bit timestamp." ---------------------------------------- Similar to issue 2 above, ntp-timestamp-32bit describes itself as a 64-bit timestamp. |
2017-10-24
|
14 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2017-10-24
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-10-24
|
14 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-14.txt |
2017-10-24
|
14 | (System) | New version approved |
2017-10-24
|
14 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-10-24
|
14 | Qin Wu | Uploaded new revision |
2017-10-24
|
13 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-10-24
|
13 | Eric Rescorla | [Ballot comment] Can you add a sentence or two to the Security Considerations explaining why the nodes that are sensitive are sensitive? I noticed a … [Ballot comment] Can you add a sentence or two to the Security Considerations explaining why the nodes that are sensitive are sensitive? I noticed a number of punctuation, spacing, and grammar errors. These will probably be caught by RFC-Ed but a proofread might help. |
2017-10-24
|
13 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-10-24
|
13 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-10-23
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-10-23
|
13 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-13, and we have a question for Benoit. QUESTION: should … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-13, and we have a question for Benoit. QUESTION: should the new YANG module be posted in the registry? If so, instructions should be added to the IANA Considerations section. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single new registration is to be made as follows: ID: yang:ietf-connectionless-oam URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods Filename: [ TBD-at-registration ] Reference: [ RFC-to-be ] The IESG-designated expert has reviewed and approved this request. Second, in the YANG Module Names registry on the YANG Parameters page located at: https://www.iana.org/assignments/yang-parameters/ a single new module name is to be registered as follows: Name: ietf-connectionless-oam Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam Prefix: cl-oam Module: Reference: [ RFC-to-be ] The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document. Thank you, Amanda Baber Lead IANA Services Specialist |
2017-10-23
|
13 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Elwyn Davies. Sent review to list. |
2017-10-23
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-10-23
|
13 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft and following the template for security considerations. Also, thanks for responding to the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/h1A7I1CVAZme2CvOKapZ6QiqvPQ |
2017-10-23
|
13 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-10-23
|
13 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-13.txt |
2017-10-23
|
13 | (System) | New version approved |
2017-10-23
|
13 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-10-23
|
13 | Qin Wu | Uploaded new revision |
2017-10-23
|
12 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-12.txt |
2017-10-23
|
12 | (System) | New version approved |
2017-10-23
|
12 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-10-23
|
12 | Qin Wu | Uploaded new revision |
2017-10-21
|
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-10-19
|
11 | Benoît Claise | Ballot has been issued |
2017-10-19
|
11 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2017-10-19
|
11 | Benoît Claise | Created "Approve" ballot |
2017-10-19
|
11 | Benoît Claise | Ballot writeup was changed |
2017-10-19
|
11 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Charlie Kaufman. |
2017-10-12
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2017-10-12
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2017-10-12
|
11 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Charlie Kaufman |
2017-10-12
|
11 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Charlie Kaufman |
2017-10-11
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2017-10-11
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2017-10-11
|
11 | Gunter Van de Velde | Assignment of request for Telechat review by OPSDIR to Carlos Martinez was rejected |
2017-10-11
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Carlos Martinez |
2017-10-11
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Carlos Martinez |
2017-10-11
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-10-11
|
11 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-10-25): From: The IESG To: IETF-Announce CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro … The following Last Call announcement was sent out (ends 2017-10-25): From: The IESG To: IETF-Announce CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro , bclaise@cisco.com, lime@ietf.org, draft-ietf-lime-yang-connectionless-oam@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard The IESG has received a request from the Layer Independent OAM Management in the Multi-Layer Environment WG (lime) to consider the following document: - 'Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols' 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 2017-10-25. 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 presents a base YANG Data model for connectionless Operations Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. The base model presented here can be extended to include technology specific details. This is leading to uniformity between OAM protocols and support both nested OAM workflows (i.e., performing OAM functions at different or same levels through a unified interface) and interacting OAM workflows ( i.e., performing OAM functions at same levels through a unified interface). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-10-11
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-10-11
|
11 | Amy Vezza | Last call announcement was changed |
2017-10-11
|
11 | Benoît Claise | Placed on agenda for telechat - 2017-10-26 |
2017-10-10
|
11 | Benoît Claise | Last call was requested |
2017-10-10
|
11 | Benoît Claise | Last call announcement was generated |
2017-10-10
|
11 | Benoît Claise | Ballot approval text was generated |
2017-10-10
|
11 | Benoît Claise | Ballot writeup was generated |
2017-10-10
|
11 | Benoît Claise | IESG state changed to Last Call Requested from AD Evaluation |
2017-10-04
|
11 | Carlos Pignataro | 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 … 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? Proposed Standard (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 presents a base YANG Data model for connectionless Operations Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. Working Group Summary This document is the product of an early split of LIME YANG Models into Connection-Oriented (C-O) OAM Models and Connectionless (CL, i.e., this) OAM Models. Further, the CL Model is further split into the Model (this document) and the retrieval methods (adjunct document). Document Quality There are plans of and implementations of this specification. This includes at least two different implementations of the model, as well as product and demos at Bits-n-Bytes. Further, there are plans to finalize the implementation of this specification. The WG was very active in reviewing these documents. Notably, participants of the BFD and MPLS WGs were special reviewers. Additionally, worth mentioning Carl Moberg's YANG Doctor review which resulted in many fixes and improvements. Personnel Carlos Pignataro is the Document Shepherd Benoit Claise is the Responsible Area Director (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. This version of the document is ready to be sent to the responsible AD. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns regarding both breath and depth of reviews. (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. YANG, with review taken place by YANG Doctors (Carl Moberg) (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. None. (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, during WG adoption. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (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? WG Agreement. (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 threat of appeal. One working group participant has expressed discontent several times. In particular, this participant has expressed concern that his comments have not been addressed and also that he has not been given enough time to review. Part of that discussion can be seen at: https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4 -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I -> https://mailarchive.ietf.org/arch/msg/lime/XWfZid1wp5JZImKNBxHDEtah6V0 The WG held 4 "Editathon" interims in which we went comment-by-comment hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime Further, both LIME WG Chairs believe there's been ample opportunity to share review and comments in multiple occasions, and that the document editors have responded timely and incorporated comments. In fact, multiple deadlines were given to this participant. Many of these deadlines were not respected, yet the WG and document editors waited and incorporated late comments just to get another deadline. This caused delay and broke the WG flow. (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. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. YANG Doctor (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. No. (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). All looks good. (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. None. (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 Doctors Review. YANG Validator. |
2017-10-03
|
11 | Carlos Pignataro | 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 … 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? Proposed Standard (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 presents a base YANG Data model for connectionless Operations Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. Working Group Summary This document is the product of an early split of LIME YANG Models into Connection-Oriented (C-O) OAM Models and Connectionless (CL, i.e., this) OAM Models. Further, the CL Model is further split into the Model (this document) and the retrieval methods (adjunct document). Document Quality There are plans of and implementations of this specification. This includes at least two different implementations of the model, as well as product and demos at Bits-n-Bytes. Further, there are plans to finalize the implementation of this specification. The WG was very active in reviewing these documents. Notably, participants of the BFD and MPLS WGs were special reviewers. Additionally, worth mentioning Carl Moberg's YANG Doctor review which resulted in many fixes and improvements. Personnel Carlos Pignataro is the Document Shepherd Benoit Claise is the Responsible Area Director (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. This version of the document is ready to be sent to the responsible AD. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns regarding both breath and depth of reviews. (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. YANG, with review taken place by YANG Doctors (Carl Moberg) (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. None. (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, during WG adoption. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (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? WG Agreement. (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 threat of appeal. One working group participant has expressed discontent several times. In particular, this participant has expressed concern that his comments have not been addressed and also that he has not been given enough time to review. Part of that discussion can be seen at: https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4 -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I -> https://mailarchive.ietf.org/arch/msg/lime/XWfZid1wp5JZImKNBxHDEtah6V0 The WG held 4 "Editathon" interims in which we went comment-by-comment hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime Further, both LIME WG Chairs believe there's been ample opportunity to share review and comments in multiple occasions, and that the document editors have responded timely and incorporated comments. (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. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. YANG Doctor (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. No. (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). All looks good. (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. None. (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 Doctors Review. YANG Validator. |
2017-09-20
|
11 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-11.txt |
2017-09-20
|
11 | (System) | New version approved |
2017-09-20
|
11 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar |
2017-09-20
|
11 | Qin Wu | Uploaded new revision |
2017-09-15
|
10 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-10.txt |
2017-09-15
|
10 | (System) | New version approved |
2017-09-15
|
10 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang |
2017-09-15
|
10 | Qin Wu | Uploaded new revision |
2017-08-31
|
09 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-09.txt |
2017-08-31
|
09 | (System) | New version approved |
2017-08-31
|
09 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang |
2017-08-31
|
09 | Qin Wu | Uploaded new revision |
2017-08-30
|
08 | Deepak Kumar | New version available: draft-ietf-lime-yang-connectionless-oam-08.txt |
2017-08-30
|
08 | (System) | New version approved |
2017-08-30
|
08 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang |
2017-08-30
|
08 | Deepak Kumar | Uploaded new revision |
2017-07-04
|
07 | Benoît Claise | IESG state changed to AD Evaluation from Publication Requested |
2017-06-28
|
07 | Carlos Pignataro | 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 … 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? Proposed Standard (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 presents a base YANG Data model for connectionless Operations Administration, and Maintenance(OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. Working Group Summary This document is the product of an early split of LIME YANG Models into Connection-Oriented (C-O) OAM Models and Connectionless (CL, i.e., this) OAM Models. Further, the CL Model is further split into the Model (this document) and the retrieval methods (adjunct document). Document Quality There are plans of and implementations of this specification. This includes at least two different implementations of the model, as well as product and demos at Bits-n-Bytes. Further, there are plans to finalize the implementation of this specification. The WG was very active in reviewing these documents. Notably, participants of the BFD and MPLS WGs were special reviewers. Additionally, worth mentioning Carl Moberg's YANG Doctor review which resulted in many fixes and improvements. Personnel Carlos Pignataro is the Document Shepherd Benoit Claise is the Responsible Area Director (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. This version of the document is ready to be sent to the responsible AD. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns regarding both breath and depth of reviews. (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. YANG, with review taken place by YANG Doctors (Carl Moberg) (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. None. (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, during WG adoption. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (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? WG Agreement. (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 threat of appeal. (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. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. YANG Doctpr (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. No. (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). All looks good. (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. None. (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 Doctors Review. YANG Validator. |
2017-06-28
|
07 | Carlos Pignataro | Responsible AD changed to Benoit Claise |
2017-06-28
|
07 | Carlos Pignataro | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-06-28
|
07 | Carlos Pignataro | IESG state changed to Publication Requested |
2017-06-28
|
07 | Carlos Pignataro | IESG process started in state Publication Requested |
2017-06-28
|
07 | Carlos Pignataro | Tag Other - see Comment Log cleared. |
2017-06-28
|
07 | Carlos Pignataro | Notification list changed to Ron Bonica <rbonica@juniper.net>, Carlos Pignataro <cpignata@cisco.com> |
2017-06-28
|
07 | Carlos Pignataro | Notification list changed to none from Ron Bonica <rbonica@juniper.net>, Carlos Pignataro <cpignata@cisco.com> |
2017-06-28
|
07 | Carlos Pignataro | Changed document writeup |
2017-06-28
|
07 | Carlos Pignataro | Changed document writeup |
2017-06-16
|
07 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-07.txt |
2017-06-16
|
07 | (System) | New version approved |
2017-06-16
|
07 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang |
2017-06-16
|
07 | Qin Wu | Uploaded new revision |
2017-06-09
|
06 | Carlos Pignataro | Notification list changed to Ron Bonica <rbonica@juniper.net>, Carlos Pignataro <cpignata@cisco.com> from Ron Bonica <rbonica@juniper.net> |
2017-06-09
|
06 | Carlos Pignataro | Document shepherd changed to Carlos Pignataro |
2017-06-09
|
06 | Carlos Pignataro | Changed document writeup |
2017-06-09
|
06 | Qin Wu | New version available: draft-ietf-lime-yang-connectionless-oam-06.txt |
2017-06-09
|
06 | (System) | New version approved |
2017-06-09
|
06 | (System) | Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang |
2017-06-09
|
06 | Qin Wu | Uploaded new revision |
2017-06-01
|
05 | Carl Moberg | Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Carl Moberg. Sent review to list. |
2017-06-01
|
05 | Carlos Pignataro | Pending ID Nits fixes. |
2017-06-01
|
05 | Carlos Pignataro | Tag Other - see Comment Log set. |
2017-06-01
|
05 | Carlos Pignataro | YANg Doctor review performed by Carl Moberg, at https://www.ietf.org/mail-archive/web/lime/current/msg00660.html |
2017-06-01
|
05 | Carlos Pignataro | Notification list changed to Ron Bonica <rbonica@juniper.net> |
2017-06-01
|
05 | Carlos Pignataro | Document shepherd changed to Ron Bonica |
2017-06-01
|
05 | Carlos Pignataro | Tag Revised I-D Needed - Issue raised by WG cleared. |
2017-06-01
|
05 | Carlos Pignataro | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-06-01
|
05 | Carlos Pignataro | Tag Revised I-D Needed - Issue raised by WG set. |
2017-06-01
|
05 | Carlos Pignataro | IETF WG state changed to In WG Last Call from WG Document |
2017-06-01
|
05 | Carlos Pignataro | Changed consensus to Yes from Unknown |
2017-06-01
|
05 | Carlos Pignataro | Intended Status changed to Proposed Standard from None |
2017-05-15
|
05 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-05.txt |
2017-05-15
|
05 | (System) | New version approved |
2017-05-15
|
05 | (System) | Request for posting confirmation emailed to previous authors: Zitao Wang , Reshad Rahman , Deepak Kumar , lime-chairs@ietf.org, Srihari Raghavan , Qin Wu |
2017-05-15
|
05 | Zitao Wang | Uploaded new revision |
2017-03-30
|
04 | Carlos Pignataro | Added to session: IETF-98: lime Thu-1740 |
2017-02-23
|
04 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-04.txt |
2017-02-23
|
04 | (System) | New version approved |
2017-02-23
|
04 | (System) | Request for posting confirmation emailed to previous authors: Zitao Wang , Reshad Rahman , Deepak Kumar , lime-chairs@ietf.org, Srihari Raghavan , Qin Wu |
2017-02-23
|
04 | Zitao Wang | Uploaded new revision |
2017-02-07
|
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Carl Moberg |
2017-02-07
|
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Carl Moberg |
2017-02-07
|
03 | Mehmet Ersue | Requested Early review by YANGDOCTORS |
2016-12-23
|
03 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-03.txt |
2016-12-23
|
03 | (System) | New version approved |
2016-12-23
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Srihari Raghavan" , lime-chairs@ietf.org, "Zitao Wang" , "Reshad Rahman" , "Qin Wu" , "Deepak Kumar" |
2016-12-23
|
03 | Zitao Wang | Uploaded new revision |
2016-10-31
|
02 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-02.txt |
2016-10-31
|
02 | (System) | New version approved |
2016-10-31
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Srihari Raghavan" , lime-chairs@ietf.org, "Zitao Wang" , "Reshad Rahman" , "Qin Wu" , "Deepak Kumar" |
2016-10-31
|
02 | Zitao Wang | Uploaded new revision |
2016-10-20
|
01 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-01.txt |
2016-10-20
|
01 | (System) | New version approved |
2016-10-20
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Srihari Raghavan" , lime-chairs@ietf.org, "Zitao Wang" , "Reshad Rahman" , "Qin Wu" , "Deepak Kumar" |
2016-10-20
|
01 | Zitao Wang | Uploaded new revision |
2016-10-07
|
00 | Carlos Pignataro | Added to session: interim-2016-lime-03 |
2016-09-12
|
00 | Carlos Pignataro | This document now replaces draft-kumar-lime-yang-connectionless-oam instead of None |
2016-09-12
|
00 | Zitao Wang | New version approved |
2016-09-12
|
00 | Zitao Wang | Uploaded new revision |
2016-09-12
|
00 | Zitao Wang | Request for posting confirmation emailed to submitter and authors: "Qin Wu" , "Srihari Raghavan" , "Deepak Kumar" , "Reshad Rahman" , "Michael Wang" |
2016-09-12
|
00 | Zitao Wang | New version available: draft-ietf-lime-yang-connectionless-oam-00.txt |