A YANG Data Model for MPLS Base
draft-ietf-mpls-base-yang-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
17 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
17 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2020-12-14
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-11-20
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-11-12
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-11-10
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-11-10
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-11-10
|
17 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-10-29
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-10-26
|
17 | (System) | RFC Editor state changed to EDIT |
2020-10-26
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-10-26
|
17 | (System) | Announcement was received by RFC Editor |
2020-10-26
|
17 | (System) | IANA Action state changed to In Progress |
2020-10-26
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2020-10-26
|
17 | Cindy Morgan | IESG has approved the document |
2020-10-26
|
17 | Cindy Morgan | Closed "Approve" ballot |
2020-10-26
|
17 | Cindy Morgan | Ballot approval text was generated |
2020-10-26
|
17 | Cindy Morgan | Ballot writeup was changed |
2020-10-26
|
17 | Deborah Brungard | Ballot approval text was changed |
2020-10-26
|
17 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-17.txt |
2020-10-26
|
17 | (System) | New version approved |
2020-10-26
|
17 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu |
2020-10-26
|
17 | Tarek Saad | Uploaded new revision |
2020-10-23
|
16 | Robert Wilton | [Ballot comment] Discuss cleared. I also have some comments on the YANG module itself: feature mpls { description "Indicates … [Ballot comment] Discuss cleared. I also have some comments on the YANG module itself: feature mpls { description "Indicates support for MPLS switching."; reference "RFC3031"; } Is the MPLS feature really required? I.e. is it plausible that a device would implement this YANG module without supporting MPLS switching? If not, then just implementing the module should probably be sufficient without a separate feature. Alternatively, it might be worth looking at the ISIS YANG module that define a feature to control with ISIS can be administratively controlled. E.g. draft-ietf-isis-yang-isis-cfg-42, feature admin-control. On a related point: augment /rt:routing: +--rw mpls {mpls}? ... +--rw interface* [name] +--rw name if:interface-ref +--rw enabled? boolean +--rw maximum-labeled-packet? uint32 Is the "enabled" leaf definitely required here? Isn't having the interface under the MPLS list sufficient to indicate that MPLS is enabled? If you really want this leaf then I would change its name to "enable" rather than "enabled", change it's default to true, and consider putting it under a feature like admin-control from the ISIS YANG module. augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: +--ro mpls-enabled? boolean {mpls}? +--ro local-label? rt-types:mpls-label {mpls}? +--ro destination-prefix? -> ../local-label {mpls}? +--ro route-context? string {mpls}? Is "local-label" clearly enough associated with MPLS in the IP RIB? E.g. should this be mpls-local-label, or under an mpls container? Presumably the mpls-enabled leaf shouldn't appear under the MPLS RIB? It might be cleaner to split this into two augments, one for the MPLS RIB, and one for other RIBS. The mpls-operations-type is defined, but not actually used by this module. I wanted to check that this is expected. I also note that the operations-type doesn't include a "no-operation" case statement which I thought might potentially be useful (but I'm not an MPLS expert). Regarding grouping label-blocks: Ben's comment is right that the must statements associated with the start-label/end-label have the wrong sense. There should also only be one of them (since they would always fail/pass in unison), and I would recommend just keeping the end-label must statement. I wasn't sure whether the unique statement is really helpful. Am I right in assuming that the blocks should be disjoint and non overlapping? If so, the unique statement doesn't achieve this, and although it could probably be done in a must statement, it would be tricky to express and get right. However, if this is a constraint then it would certainly be helpful for the description of label-block to mention this. Regarding grouping rib-active-route-mpls-input: I know that this has been discussed with yang-doctors and the authors of the base RIB YANG module that is being extended but seeing the YANG I'm not quite sure we have the best outcome, since users of the RPC would be required to specify both destination-address and local-label as input parameters. Possibly a better choice would to make this a choice so that a client could query either using a destination-address or a local-label (with both using the same type definition)? |
2020-10-23
|
16 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2020-10-20
|
16 | Roman Danyliw | [Ballot comment] Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work. Thank you for … [Ballot comment] Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work. Thank you for addressing my DISCUSS and COMMENT points. |
2020-10-20
|
16 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-10-19
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-19
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-10-19
|
16 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-16.txt |
2020-10-19
|
16 | (System) | New version approved |
2020-10-19
|
16 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza , Vishnu Beeram |
2020-10-19
|
16 | Tarek Saad | Uploaded new revision |
2020-09-10
|
15 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-09-10
|
15 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-09-10
|
15 | Robert Wilton | [Ballot discuss] Hi, Thank for you this YANG module. It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for … [Ballot discuss] Hi, Thank for you this YANG module. It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for the time and effort that you have put into this. I support Roman's discuss regarding the security considerations, but would also like to add one of my own: In my experience, having some instance data examples (e.g., see Appendix D of RFC 8022) greatly helps readers understand the structure of the YANG module and get a good feel for how the YANG model is used. Was adding instance data examples considered for this document? Do the authors that think it would be possible to add some examples? I've also added some comments on the YANG model below that probably need to be addressed but I didn't want to overload the main discuss point. Regards, Rob |
2020-09-10
|
15 | Robert Wilton | Ballot discuss text updated for Robert Wilton |
2020-09-10
|
15 | Robert Wilton | [Ballot discuss] Hi, Thank for you this YANG module. It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for … [Ballot discuss] Hi, Thank for you this YANG module. It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for the time and effort that have put into this. I support Roman's discuss regarding the security considerations, but would also like to add one of my own: In my experience, having some instance data examples (e.g., see Appendix D of RFC 8022) greatly helps readers understand the structure of the YANG module and get a good feel for how the YANG model is used. Was adding instance data examples considered for this document? Do the authors that think it would be possible to add some examples? I've also added some comments on the YANG model below that probably need to be addressed but I didn't want to overload the main discuss point. Regards, Rob |
2020-09-10
|
15 | Robert Wilton | [Ballot comment] I also have some comments on the YANG module itself: feature mpls { description "Indicates support for … [Ballot comment] I also have some comments on the YANG module itself: feature mpls { description "Indicates support for MPLS switching."; reference "RFC3031"; } Is the MPLS feature really required? I.e. is it plausible that a device would implement this YANG module without supporting MPLS switching? If not, then just implementing the module should probably be sufficient without a separate feature. Alternatively, it might be worth looking at the ISIS YANG module that define a feature to control with ISIS can be administratively controlled. E.g. draft-ietf-isis-yang-isis-cfg-42, feature admin-control. On a related point: augment /rt:routing: +--rw mpls {mpls}? ... +--rw interface* [name] +--rw name if:interface-ref +--rw enabled? boolean +--rw maximum-labeled-packet? uint32 Is the "enabled" leaf definitely required here? Isn't having the interface under the MPLS list sufficient to indicate that MPLS is enabled? If you really want this leaf then I would change its name to "enable" rather than "enabled", change it's default to true, and consider putting it under a feature like admin-control from the ISIS YANG module. augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: +--ro mpls-enabled? boolean {mpls}? +--ro local-label? rt-types:mpls-label {mpls}? +--ro destination-prefix? -> ../local-label {mpls}? +--ro route-context? string {mpls}? Is "local-label" clearly enough associated with MPLS in the IP RIB? E.g. should this be mpls-local-label, or under an mpls container? Presumably the mpls-enabled leaf shouldn't appear under the MPLS RIB? It might be cleaner to split this into two augments, one for the MPLS RIB, and one for other RIBS. The mpls-operations-type is defined, but not actually used by this module. I wanted to check that this is expected. I also note that the operations-type doesn't include a "no-operation" case statement which I thought might potentially be useful (but I'm not an MPLS expert). Regarding grouping label-blocks: Ben's comment is right that the must statements associated with the start-label/end-label have the wrong sense. There should also only be one of them (since they would always fail/pass in unison), and I would recommend just keeping the end-label must statement. I wasn't sure whether the unique statement is really helpful. Am I right in assuming that the blocks should be disjoint and non overlapping? If so, the unique statement doesn't achieve this, and although it could probably be done in a must statement, it would be tricky to express and get right. However, if this is a constraint then it would certainly be helpful for the description of label-block to mention this. Regarding grouping rib-active-route-mpls-input: I know that this has been discussed with yang-doctors and the authors of the base RIB YANG module that is being extended but seeing the YANG I'm not quite sure we have the best outcome, since users of the RPC would be required to specify both destination-address and local-label as input parameters. Possibly a better choice would to make this a choice so that a client could query either using a destination-address or a local-label (with both using the same type definition)? |
2020-09-10
|
15 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2020-09-10
|
15 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-09-09
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-09-09
|
15 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-09-08
|
15 | Erik Kline | [Ballot comment] [[ nits ]] [ section 2.2 ] * "represents support possible" -> "represents support for possible"? [ section 2.3 ] * s/Adjecency/Adjacency/ [ … [Ballot comment] [[ nits ]] [ section 2.2 ] * "represents support possible" -> "represents support for possible"? [ section 2.3 ] * s/Adjecency/Adjacency/ [ section 2.5 ] * "Next-hop acts as primary traffic carrying." May read as slightly awkward. Consider perhaps: "Next-hop acts as primary for carrying traffic." ...or something. * "aaugmentation" -> "augmentation" |
2020-09-08
|
15 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-09-08
|
15 | Benjamin Kaduk | [Ballot comment] Before getting into the section-by-section comments, I'll note that there are a few things in the YANG module itself that seem awry to … [Ballot comment] Before getting into the section-by-section comments, I'll note that there are a few things in the YANG module itself that seem awry to my untrained eye. Section 2.2 The 'ietf-mpls' module defines the following identities: [...] label-block-alloc-mode: (nit?) We also define two identities based on this one; is the list of "defines the following identities" supposed to be comprehensive (vs. "high-level")? nhlfe-multiple-contents: A YANG grouping that describes a set of NHLFE(s) and their associated parameters as described in the MPLS architecture document [RFC3031]. (editorial) Perhaps we could say a few more words about how these NHLFEs are related/why they are being grouped together? (I do not recall such grouping being specifically covered in 3031.) rib-mpls-properties: A YANG grouping for the augmentation of MPLS label forwarding data to the generic RIB as defined in [RFC3031]. nit(?): the "as defined in " seems more applicable to "MPLS label forwarding data" than "generic RIB". Section 2.3 o routes that cross-connect an MPLS local label to a Layer-3 adjacency or interface - such as MPLS Segment-Routing (SR) Adjecency Segments (Adj-SIDs), SR MPLS Binding SIDs, etc. as defined in [RFC8402]. nit(?): is there a semantic difference between "MPLS SR" and "SR MPLS" for the two types of route mentioned? Section 2.5 identity label-block-alloc-mode { description "Base identity label-block allocation mode."; } nit: missing "for". grouping nhlfe-multiple-contents { description "MPLS NHLFE contents."; nit: this description feels a little terse; is this the "generic" case or something similar? leaf index { type string; description "A user-specified identifier utilised to uniquely reference the next-hop entry in the next-hop list. The value of this index has no semantic meaning other than for referencing the entry."; } leaf backup-index { type string; description "A user-specified identifier utilised to uniquely reference the backup next-hop entry in the NHLFE list. The value of this index has no semantic meaning other than for referencing the entry."; } I'm not sure I understand the semantics, here -- does 'index' authoritatively name the current entry with 'backup-index' being effectively a pointer to a different entry? I don't see any leafs of type string in, e.g., rt-types:mpls-label-stack that this would be referring to. If the backup-index is indeed just a pointer to a different entry, why is the string name used instead of a YANG reference? Also, what's a good reference for "backup" MPLS next-hops? I don't see the string "backup" in either RFC 3031 or 3032. grouping interfaces-mpls { [...] leaf name { type if:interface-ref; description "The name of a configured MPLS interface."; } pedantic nit: is this really a "name"? leaf start-label { type rt-types:mpls-label; must '. >= ../end-label' { error-message "The start-label must be less than or equal " + "to end-label"; } I think the sense of the YANG comparator is reversed, for both start-label (this) and end-label (not quoted). (Also, IIUC, it's redundant to specify both, but harmless.) leaf free-labels-count { when "derived-from-or-self(../block-allocation-mode, " + "'mpls:label-block-alloc-mode-manager')"; type yang:counter32; config false; description "Label-block free labels count."; I think that counter32 is semantically the wrong type, here (and for inuse-labels-count as well) -- IIRC the 'counter' types are for thigns like counting a particular type of event, and only ever monotonically increase. Even if the free label count behaves monotonically (which is far from clear to me), wouldn't it be decreasing, not increasing? Also, won't it always be true that free-labels-count + inuse-labels-count == end-label - start-label + 1? I'm not sure why there's a need to introduce such redundant fields and the corresponding risk of internal inconsistency among them. uses rib-mpls-properties { /* MPLS AF aaugmentation to native MPLS RIB */ nit: s/aaugmentation/augmentation/ uses rib-active-route-mpls-input { /* MPLS AF aaugmentation to native MPLS RIB */ (ditto) Section 4 Why is the rt:simple-next-hop augmentation listed but not the rt:next-hop-list augmentation? IIUC they are functionally identical in terms of the sensitivity of information content. Also, it seems like the augmented RPC output is similarly sensitive to the readable nodes that are already mentioned. It looks like the main writeable nodes are the global configuration/state, and while it's perhaps defensible to say that these particular nodes are not sensitive, I did want to check what the behavior would be if (e.g.) the label-blocks subtree was overwritten. Would things just silently start using the new label block and keep working? Perhaps it would be too banal, but should we reference the security considerations of 3031/3032 as applying to MPLS usage? Section 7.1 It's not clear that we reference RFC 8402 in a normative manner anywhere. Section 7.2 I agree with the document shepherd that RFCs 3031 and 3032 naturally would be classified as normative references. Similarly, RFC 7424 is refrenced by the YANG module itself, which usually indicates a normative reference. |
2020-09-08
|
15 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-09-08
|
15 | Roman Danyliw | [Ballot discuss] ** Section 11. Thanks for enumerating the sensitive read operations. It looks like the sensitive writes aren’t described. Wouldn’t it be a problem … [Ballot discuss] ** Section 11. Thanks for enumerating the sensitive read operations. It looks like the sensitive writes aren’t described. Wouldn’t it be a problem for arbitrary writes to occur to /rt:routing/mpls/*? I recommend using the "template language" of "There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable ... These are the subtrees and data nodes and their sensitivity/vulnerability:" to provide this easy fix. |
2020-09-08
|
15 | Roman Danyliw | [Ballot comment] Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work. Editorial nits: -- … [Ballot comment] Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work. Editorial nits: -- Section 1. Editorial. There is a tool chain artifact which is leaving “{!RFC8349}” in the text. -- Section 2.3. Typo. s/Adjecency/Adjacency/ -- Section 2.5. Typo. s/aaugmentation/augmentation/ |
2020-09-08
|
15 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-09-07
|
15 | Murray Kucherawy | [Ballot comment] In Section 3, it says: "This document registers the following URIs in the IETF XML registry." I think it should say "This document … [Ballot comment] In Section 3, it says: "This document registers the following URIs in the IETF XML registry." I think it should say "This document registers the following URIs in the 'ns' sub-registry of the IETF XML registry." I can relate to Barry's comment about "module" vs. "model". I think I understand the difference, but I've run into this with every YANG document that's come up lately: I think the "model" is a formal expression for a configuration of some network component, while "module" is a chunk of YANG code that describes that model, which can be evaluated (a la ABNF) against some input to validate a configuration. I also concur with Barry's remark about BCP 14 being cited when it's not used anywhere. This should be cleaned up (by either using it, or removing the citation). I'm tempted to DISCUSS this, but I assume since it's easily resolved that that'll happen in due course. |
2020-09-07
|
15 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-09-04
|
15 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I really appreciated the clear and sharp introduction. I am also trusting the Management … [Ballot comment] Thank you for the work put into this document. I really appreciated the clear and sharp introduction. I am also trusting the Management and routing ADs for the accuracy of the YANG module. Please find below two minors nits I hope that this helps to improve the document, Regards, -éric == NITS == -- Section 1 -- s/A core routing data model is defined/A core routing YANG data model is defined/ -- Section 5 -- Naming all design team members could be more friendly. |
2020-09-04
|
15 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-09-03
|
15 | Barry Leiba | [Ballot comment] The document sometimes says “YANG model” and sometimes “YANG module”. It should use the correct term and be consistent, no? I note that … [Ballot comment] The document sometimes says “YANG model” and sometimes “YANG module”. It should use the correct term and be consistent, no? I note that there is BCP 14 boilerplate here but no BCP 14 key words in the document. The shepherd writeup notes that also and says that the shepherd wanted to discuss this with the authors... but there is no resolution to that. Did the shepherd discuss it with the authors? Should some “must”s become “MUST”s? Or should the boilerplate and references be removed? — Section 1 — The MPLS base model also defines a new instance of the generic RIB model as defined in {!RFC8349}} to store native MPLS routes. What is the notation around RFC8349? Does it mean something, or is it a markup artifact that needs to be fixed during editing? |
2020-09-03
|
15 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-08-31
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-08-27
|
15 | Cindy Morgan | Placed on agenda for telechat - 2020-09-10 |
2020-08-27
|
15 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-08-27
|
15 | Deborah Brungard | Ballot has been issued |
2020-08-27
|
15 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2020-08-27
|
15 | Deborah Brungard | Created "Approve" ballot |
2020-08-27
|
15 | Deborah Brungard | Ballot writeup was changed |
2020-08-20
|
15 | Gyan Mishra | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Gyan Mishra. Sent review to list. |
2020-08-19
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-08-17
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-08-17
|
15 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-15.txt |
2020-08-17
|
15 | (System) | New version accepted (logged-in submitter: Tarek Saad) |
2020-08-17
|
15 | Tarek Saad | Uploaded new revision |
2020-08-17
|
14 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-08-17
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mpls-base-yang-14. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mpls-base-yang-14. If any part of this review is inaccurate, please let us know. 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 new namespace will be registered as follows: ID: yang:ietf-mpls URI: urn:ietf:params:xml:ns:yang:ietf-mpls 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 new YANG module will be registered as follows: Name: ietf-mpls File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-mpls Prefix: ietf-mpls Module: Reference: [ RFC-to-be ] 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 |
2020-08-13
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-08-13
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-08-10
|
14 | Derrell Piper | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derrell Piper. Sent review to list. |
2020-08-06
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
2020-08-06
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
2020-08-06
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-08-06
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-08-05
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-08-05
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-08-19): From: The IESG To: IETF-Announce CC: Loa Andersson , mpls@ietf.org, db3546@att.com, draft-ietf-mpls-base-yang@ietf.org, … The following Last Call announcement was sent out (ends 2020-08-19): From: The IESG To: IETF-Announce CC: Loa Andersson , mpls@ietf.org, db3546@att.com, draft-ietf-mpls-base-yang@ietf.org, mpls-chairs@ietf.org, loa@pi.nu Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Data Model for MPLS Base) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A YANG Data Model for MPLS Base' 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 last-call@ietf.org mailing lists by 2020-08-19. 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 contains a specification of the MPLS base YANG model. The MPLS base YANG model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS-enabled router. It is expected that other MPLS YANG models (e.g. MPLS Label Switched Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS base YANG model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ No IPR declarations have been submitted directly on this I-D. |
2020-08-05
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-08-05
|
14 | Deborah Brungard | Last call was requested |
2020-08-05
|
14 | Deborah Brungard | Ballot approval text was generated |
2020-08-05
|
14 | Deborah Brungard | Ballot writeup was generated |
2020-08-05
|
14 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2020-08-05
|
14 | Deborah Brungard | Last call announcement was changed |
2020-08-03
|
14 | Ron Bonica | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list. |
2020-07-30
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2020-07-30
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2020-07-28
|
14 | Deborah Brungard | Requested Last Call review by RTGDIR |
2020-06-30
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Standard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior to wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits tool identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o status change of any other RFC when this documents is published. However the development of this draft has resulted in an errata against RFC8349. For route entries that appear IPv4/IPv6 RIBs, those are keyed by address and having the leaf "destination-address" makes sense. However, route entries that appear in MPLS RIB are keyed by MPLS local label, so it would be misleading to have a leaf named 'destination-address' for them. Hence, an errata to relax the 'MUST' in RFC8349 will be filed by the authors of this document. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked every time the document is posted. The YANG module is published on github and reviews, issues are tracked under the project. Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors. Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? All the tools mentioned above were used to validate the YANG module is free from errors. YANG module is compliant with NMDA |
2020-06-30
|
14 | Loa Andersson | Responsible AD changed to Deborah Brungard |
2020-06-30
|
14 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2020-06-30
|
14 | Loa Andersson | IESG state changed to Publication Requested from I-D Exists |
2020-06-30
|
14 | Loa Andersson | IESG process started in state Publication Requested |
2020-06-30
|
14 | Loa Andersson | Changed consensus to Yes from Unknown |
2020-06-30
|
14 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2020-06-30
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Standard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior to wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits tool identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o status change of any other RFC when this documents is published. However the development of this draft has resulted in an errata against RFC8349. For route entries that appear IPv4/IPv6 RIBs, those are keyed by address and having the leaf "destination-address" makes sense. However, route entries that appear in MPLS RIB are keyed by MPLS local label, so it would be misleading to have a leaf named 'destination-address' for them. Hence, an errata to relax the 'MUST' in RFC8349 will be filed by the authors of this document. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked every time the document is posted. The YANG module is published on github and reviews, issues are tracked under the project. Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors. Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? All the tools mentioned above were used to validate the YANG module is free from errors. YANG module is compliant with NMDA |
2020-05-13
|
14 | Loa Andersson | Notification list changed to Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, draft-ietf-mpls-base-yang@ietf.org from Loa Andersson <loa@pi.nu> |
2020-05-13
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Standard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior to wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits tool identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o status change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked every time the document is posted. The YANG module is published on github and reviews, issues are tracked under the project. Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors. Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? All the tools mentioned above were used to validate the YANG module is free from errors. YANG module is compliant with NMDA |
2020-05-13
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Standard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior to wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits tool identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o status change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked every time the document is posted. The YANG module is published on gihub and reviews, issues are tracked under the project. Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors. Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? All the tools mentioned above were used to validate the YANG module is free from errors. YANG module is compliant with NMDA |
2020-05-07
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Standard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior ti wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits toll identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o stauts change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked automatically every time the document is posted. Need help to fill in additional info (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? Need help to fill in this info. |
2020-05-07
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Stardard track RFC. (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: The MPLS base model augments the core routing model defined in RFC8349 with additional data specific to MPLS technology as described in MPLS Architecture RFC3031. RFC8349 requires specific YANG augmentations by any such routing protocol and these have been included. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior ti wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits toll identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o stauts change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked automatically every time the document is posted. Need help to fill in additional info (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? Need help to fill in this info. |
2020-05-07
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Stardard track RFC. (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: A core routing data model is defined in RFC 8349, and it provides a basis for the development of data models for routing protocols. The MPLS base model augments core routing data model with additional data specific to MPLS technology as described in the MPLS architecture document RFC3031. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementations or intent to implement. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a positive influence on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa Andersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not clear who the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the document at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the request of the authors prior ti wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed against this document. (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? The working group stands behinds this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits toll identify there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the document does not use any requirement language. Note: the Shepherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative reference. Especially since the definition of MPLS push, pop and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative references are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o stauts change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked automatically every time the document is posted. Need help to fill in additional info (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? Need help to fill in this info. |
2020-05-01
|
14 | Loa Andersson | The MPLS working group request that draft-ietf-mpls-base-yang is published a an RFC on the standards track (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? As a YANG model this document should be published as a Stardard track RFC. (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: A core routing data model is defined in RFC 8349, and it provides a basis for the development of data models for routing protocols. The MPLS base model augments core routing data model with additional data specific to MPLS technology as described in the MPLS architecture document RFC3031. The MPLS base model serves as a basis for future development of MPLS data models covering specific MPLS feature(s) and sub-system(s). The main purpose of the MPLS base is to provide building blocks for more complicated and data models, including different control plane protocols, and advanced MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by other modules developed at IETF (e.g. by MPLS and TEAS working groups). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group is solidly behind that the document. Document Quality: We understand that there are implementations and intents to implement this YANG model, from a large number of vendors. However we have not earlier documented implementtaitons or intent to implment. An implementation poll has therefore been sent to the working group mailing list. Tom Petch has done very thorough review, and had a postive influnce on the document. THe document has been reviewed by the Yang Doctors several times. Personnel: Loa ndersson is the Document Shepherd. Deborah Brungard 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. When this document came online the Shepherd reviewed, but at that time it was not cler sho the shepherd would be so this was a wg chair review to look at what was new. The shepherd was appointed just prior to the wglc, but reviewed the dcument at wgap and wglc. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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. The document has been reviewed bu the YANG doctors on the requst of the authors prior ti wgap and on the request of the Shepherd (via the authors) at wglc. (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. No such 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? All the authors and contributors have confirmed that that they are unaware of any IPRs. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPRs disclosed againstthis document. (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? The working group stands behinds this document. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd has not identified any other nits than what the nits toll identify there is a BCP 14 boiler plate in section 1.1 Terminolgy, but the rest of the document does not use any requirment language. Note: the SHpherd wants to discuss this with the authors since there are lower case musts in YANG Module, and the shepherd does not understand if they are equivalent to BCP 14 language. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The YANG doctors have reviewed the document at several occasion. No further formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes - all references are split into normative and informative references, though the Shepherd would like to understand why RFC 3031 is an informative refrence. Especially since the definition of MPLS puh, op and swap operations comes from RFC 3031. Same goes for RFC 3032 that defines the MPLS Label Stack encoding. (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? All the normative refrences are Standard Track RFCs or BCPs. (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 downward references. (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. There will be n o stauts change of any other RFC when this documents is published. (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 8126). The IANA section has been reviewed several time during the development of the document. (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. No such registries created. (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, YANG modules, etc. The YANG module is checked automatiall every time the document is posted. Need help to fill in additional info (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? Need help to fill in this info. |
2020-03-04
|
14 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-14.txt |
2020-03-04
|
14 | (System) | New version approved |
2020-03-04
|
14 | (System) | Request for posting confirmation emailed to previous authors: Kamran Raza , Xufeng Liu , Vishnu Beeram , Rakesh Gandhi , Tarek Saad |
2020-03-04
|
14 | Tarek Saad | Uploaded new revision |
2020-03-03
|
13 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-13.txt |
2020-03-03
|
13 | (System) | New version approved |
2020-03-03
|
13 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Tarek Saad , Rakesh Gandhi , Kamran Raza , Xufeng Liu |
2020-03-03
|
13 | Tarek Saad | Uploaded new revision |
2020-02-18
|
12 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-12.txt |
2020-02-18
|
12 | (System) | New version approved |
2020-02-18
|
12 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza |
2020-02-18
|
12 | Tarek Saad | Uploaded new revision |
2020-01-29
|
11 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG set. |
2020-01-29
|
11 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2020-01-29
|
11 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2019-12-09
|
11 | Loa Andersson | The document is in IPR poll starting Dec 9 2019. |
2019-12-09
|
11 | Loa Andersson | Notification list changed to Loa Andersson <loa@pi.nu> |
2019-12-09
|
11 | Loa Andersson | Document shepherd changed to Loa Andersson |
2019-09-12
|
11 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-11.txt |
2019-09-12
|
11 | (System) | New version approved |
2019-09-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Xufeng Liu , Vishnu Beeram , mpls-chairs@ietf.org, Kamran Raza , Tarek Saad |
2019-09-12
|
11 | Tarek Saad | Uploaded new revision |
2019-08-28
|
10 | (System) | Document has expired |
2019-08-18
|
10 | Ebben Aries | Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Ebben Aries. Sent review to list. |
2019-07-11
|
10 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ebben Aries |
2019-07-11
|
10 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ebben Aries |
2019-07-10
|
10 | Tarek Saad | Requested Early review by YANGDOCTORS |
2019-02-24
|
10 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-10.txt |
2019-02-24
|
10 | (System) | New version approved |
2019-02-24
|
10 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza |
2019-02-24
|
10 | Tarek Saad | Uploaded new revision |
2018-11-05
|
09 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-09.txt |
2018-11-05
|
09 | (System) | New version approved |
2018-11-05
|
09 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, Kamran Raza , Tarek Saad |
2018-11-05
|
09 | Tarek Saad | Uploaded new revision |
2018-10-16
|
08 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-08.txt |
2018-10-16
|
08 | (System) | New version approved |
2018-10-16
|
08 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu |
2018-10-16
|
08 | Tarek Saad | Uploaded new revision |
2018-10-12
|
07 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-07.txt |
2018-10-12
|
07 | (System) | New version approved |
2018-10-12
|
07 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu |
2018-10-12
|
07 | Tarek Saad | Uploaded new revision |
2018-08-19
|
06 | (System) | Document has expired |
2018-02-15
|
06 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-06.txt |
2018-02-15
|
06 | (System) | New version approved |
2018-02-15
|
06 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Raqib Jones , Bin Wen , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Raqib Jones , Bin Wen , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, Xia Chen , Igor Bryskin , Kamran Raza , Tarek Saad |
2018-02-15
|
06 | Tarek Saad | Uploaded new revision |
2018-01-03
|
05 | (System) | Document has expired |
2017-07-02
|
05 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-05.txt |
2017-07-02
|
05 | (System) | New version approved |
2017-07-02
|
05 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen … Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , Igor Bryskin , Bin Wen , Raqib Jones |
2017-07-02
|
05 | Tarek Saad | Uploaded new revision |
2017-03-12
|
04 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-04.txt |
2017-03-12
|
04 | (System) | New version approved |
2017-03-12
|
04 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen … Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones |
2017-03-12
|
04 | Tarek Saad | Uploaded new revision |
2017-03-11
|
03 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-03.txt |
2017-03-11
|
03 | (System) | New version approved |
2017-03-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen … Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones |
2017-03-11
|
03 | Tarek Saad | Uploaded new revision |
2017-03-10
|
02 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-02.txt |
2017-03-10
|
02 | (System) | New version approved |
2017-03-10
|
02 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Xufeng Liu , Vishnu Beeram , Xia Chen … Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Xufeng Liu , Vishnu Beeram , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones |
2017-03-10
|
02 | Tarek Saad | Uploaded new revision |
2017-01-09
|
01 | (System) | Document has expired |
2016-07-08
|
01 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-01.txt |
2016-06-12
|
00 | Loa Andersson | This document now replaces draft-saad-mpls-base-yang instead of None |
2016-06-12
|
00 | Tarek Saad | New version available: draft-ietf-mpls-base-yang-00.txt |