A YANG Data Model for Layer 2 Network Topologies
draft-ietf-i2rs-yang-l2-network-topology-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-11-09
|
18 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-11-02
|
18 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-09-29
|
18 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-09-24
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-09-24
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-09-24
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-09-23
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-09-22
|
18 | (System) | RFC Editor state changed to EDIT |
2020-09-22
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-09-22
|
18 | (System) | Announcement was received by RFC Editor |
2020-09-22
|
18 | (System) | IANA Action state changed to In Progress |
2020-09-22
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-09-22
|
18 | Amy Vezza | IESG has approved the document |
2020-09-22
|
18 | Amy Vezza | Closed "Approve" ballot |
2020-09-22
|
18 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-09-22
|
18 | Martin Vigoureux | Ballot approval text was generated |
2020-09-17
|
18 | Robert Wilton | [Ballot comment] Clearing discuss held for IEEE review: The IEEE Yangsters (members of the IEEE YANG experts) who reviewed and contributed review comments to this … [Ballot comment] Clearing discuss held for IEEE review: The IEEE Yangsters (members of the IEEE YANG experts) who reviewed and contributed review comments to this draft are comfortable with version -18. Note, that these represent informal reviews of individuals and do not represent a formal IEEE consensus position." Regards, Rob Mostly minor/editorial comments (###) on the YANG model, but I do think that it would be helpful for these to be discussed and addressed as appropriate: 4. Layer 2 Topology YANG Module import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } ### These references should probably both just be: "RFC 6991: Common YANG Data Types" revision 2020-06-29 { description "Initial revision"; reference "RFC XXXX: A YANG Data Model for Layer 2 Network Topologies"; } ### I would reorder these sections to be (which will solve the forward reference issue mentioned by Ben): feature-stmt identity-stmt typedef-stmt I'm surprised that pyang didn't flag this. /* * Typedefs */ typedef vni { type uint32 { range "0..16777215"; } description "VXLAN Network Identifier or VXLAN Segment ID. It allows up to 16 M VXLAN segments to coexist within the same administrative domain. The use of value '0' is implementation-specific."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } typedef l2-flag-type { type identityref { base flag-identity; } description "Base type for L2 flags. One example of L2 flag type is trill which represents trill topology type."; } ### This isn't really a base type. Given where this flag is used, would this be better as an "network-flag-type", with a description more similar to the ones below? typedef node-flag-type { type identityref { base flag-identity; } description "Node flag attributes. The physical node can be one example of node flag attribute."; } typedef link-flag-type { type identityref { base flag-identity; } description "Link flag attributes. One example of link flag attribute is the pseudowire."; } ### Should there be identities defined for l2-flag, node-flag and link-flag that derive from flag-identity? That would them make these three typedefs reference different things rather than all referencing the same base flags. typedef l2-network-event-type { type enumeration { enum add { value 0; description "A Layer 2 node or link or termination-point has been added."; } enum remove { value 1; description "A Layer 2 node or link or termination-point has been removed."; } enum update { value 2; description "A Layer 2 node or link or termination-point has been updated."; } } description "Layer 2 network event type for notifications."; } ### Since these are events, I would suggest renaming these "add" -> "addition", "remove" -> "removal", "update" typedef neg-mode { type enumeration { enum full-duplex { description "Indicates full-duplex mode."; } enum auto-neg { description "Indicates auto-negotiation mode."; } enum half-duplex { description "Indicates half-duplex mode."; } } description "Indicates the type of the negotiation mode."; } ### What negotiation do you mean? Does this mean IEEE 802.3 auto-negotation? If so, it would be more correct to have a separate leaf for duplex vs auto-negotation. /* * Features */ feature VLAN { description "Indicates that the system supports the vlan functions (also known as an IEEE 802.1Q tag)."; } feature QinQ { description "Indicates that the system supports the qinq functions (also known as IEEE 802.1ad double tag)."; } ### I think that the description should be more clear on what is supported here: 2 VLAN tags, as defined by IEEE 802.1ad. The features should also include reference statements. Possibly we need to find a better name for these features (IEEE will possibly comment on this). feature VXLAN { description "Indicates that the device supports VXLAN functions."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } /* * Identities */ identity flag-identity { description "Base type for flags."; } ### Probably the name should be just "flag" rather than "flag-identity" identity eth-encapsulation-type { base ift:iana-interface-type; description "Base identity from which specific Ethernet encapsulation types are derived."; reference "RFC 7224: IANA Interface Type YANG Module"; } ### I would rename the base identity to probably "l2-encapsulation-type". It also probably doesn't help to derive from ift:iana-interface-type. identity ethernet { ... identity vxlan { base eth-encapsulation-type; description "VXLAN MAC in UDP encapsulation."; } ### Please add references for protocols defined in the identities. /* * Groupings */ grouping l2-network-type { Dong, et al. Expires December 31, 2020 [Page 12] Internet-Draft Layer 2 Network Topology Data Model June 2020 description "Indicates the topology type to be L2."; container l2-network { presence "Indicates L2 Network"; description "The presence of the container node indicates L2 Topology."; } } grouping l2-network-attributes { description "L2 Topology scope attributes."; container l2-network-attributes { description "Contains L2 network attributes."; leaf name { type string; description "Name of the L2 network."; ### Perhaps just "Name of the network". Are there any restrictions here on how long the name can be, can it contain spaces, etc? } leaf-list flag { type l2-flag-type; description "L2 network flags."; } } } ### Perhaps expand the description to "Flags that can be associated with the network" I would suggest changing the name of all "flag" to "flags" where they are leaf-lists. grouping l2-node-attributes { description "L2 node attributes"; container l2-node-attributes { description "Contains L2 node attributes."; leaf name { type string; description "Node name."; } leaf description { type string; description "Node description."; } leaf-list management-address { type inet:ip-address; description "System management address."; } leaf sys-mac-address { type yang:mac-address; description "System MAC address."; } leaf management-vid { if-feature "VLAN"; type dot1q-types:vlanid; description "System management VID."; ### Please change "management-vid" to "management-vlan-id", and fix the description. Probably could expand on all the descriptions of the "System" properties to explain what these system properties are and how they are used (e.g. to manage the device). } leaf-list flag { type node-flag-type; description "Node operational flags."; } } } grouping l2-link-attributes { description "L2 link attributes"; container l2-link-attributes { description "Contains L2 link attributes."; leaf name { type string; description "Link name."; } leaf-list flag { type link-flag-type; description "Link flags."; } leaf rate { type decimal64 { fraction-digits 2; } units "Mbps"; description "Link rate."; ### Please expand on this description. Does this describe how the link is operating at the physical layer, or its bandwidth? } leaf delay { type uint32; units "microseconds"; description "Link delay in microseconds."; ### Is this uni-directional delay, or bi-directional? Please clarify. leaf maximum-frame-size { type uint32; description "Maximum L2 frame size. If L2 frame is an Ethernet frame, the Ethernet header should be included; if L2 frame is other type (e.g., PPP), the L2 header should be included."; ### This needs to clarify whether the 4 byte CRC is included in the frame size. leaf eth-encapsulation { type identityref { base eth-encapsulation-type; } ### As per comments on the identities, I think that this should be "encapsulation". description "Encapsulation type of this termination point."; } leaf lag { type boolean; default "false"; description "Defines whether lag is supported or not."; ### Does this leaf indicate whether LAG is supported, or enabled on the link? } leaf-list member-link-tp { when "../lag = 'true'" { description "Relevant only when the lag interface is supported."; } type leafref { path "/nw:networks/nw:network/nw:node/" + "nt:termination-point/nt:tp-id"; } description "Member link termination points."; } leaf mode { type neg-mode; default "auto-neg"; description "Exposes the negotiation mode."; } ### Suggest changing the name to "ethernet-auto-neg-mode", and refining the description. I would also suggest splitting duplex and auto-negotiation into 2 separate leaves to more accurately represent leaf port-vlan-id { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vlan'."; } if-feature "VLAN"; type dot1q-types:vlanid; description "Port VLAN ID is the VLAN identifier that will be assigned to any untagged frames entering the switch on the specific port."; } ### Probably naming this as the "default-untagged-vlan" may be more helpful. list vlan-id-name { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vlan'."; } ### I think that I would name this list "vlans" leaf vlan-name { ### I would suggest renaming this leaf to just "name" "Interface configured SVLANs and CVLANs."; leaf svlan-id { type dot1q-types:vlanid; description "SVLAN ID."; } leaf cvlan-id { type dot1q-types:vlanid; description "CVLAN ID."; } } ### Suggest "SVLAN" => "S-VLAN" and "CVLAN" => "C-VLAN" container vxlan { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vxlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vxlan'."; } if-feature "VXLAN"; leaf vni-id { type vni; description "VXLAN Network Identifier (VNI)."; } description "Vxlan encapsulation type."; } } //case ethernet case legacy { leaf layer-2-address { type yang:phys-address; description "Interface Layer 2 address."; } leaf encapsulation { type identityref { base ift:iana-interface-type; } description "Other legacy encapsulation type of this termination point."; } } //case legacy such as atm, ppp, hdlc, etc. } //choice termination-point-type leaf tp-state { type enumeration { enum in-use { value 1; description "The termination point is in forwarding state."; } enum blocking { value 2; description "The termination point is in blocking state."; } enum down { value 3; description "The termination point is in down state."; } enum others { ### Please rename others => other value 4; description "The termination point is in other state."; ### Please modify the description to something like "The termination point is in another state, not listed in the enumeration." } } config false; description "State of the termination point."; } } } |
2020-09-17
|
18 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2020-09-10
|
18 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-18.txt |
2020-09-10
|
18 | (System) | New version approved |
2020-09-10
|
18 | (System) | Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Xiugang Wei , Anders Liu , Qin WU , Jie Dong |
2020-09-10
|
18 | Qin Wu | Uploaded new revision |
2020-08-27
|
17 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-17.txt |
2020-08-27
|
17 | (System) | New version approved |
2020-08-27
|
17 | (System) | Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Xiugang Wei , Qin WU , Jie Dong , Anders Liu |
2020-08-27
|
17 | Qin Wu | Uploaded new revision |
2020-08-13
|
16 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-16.txt |
2020-08-13
|
16 | (System) | New version approved |
2020-08-13
|
16 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Mohamed Boucadair , Xiugang Wei , Anders Liu , Qin WU |
2020-08-13
|
16 | Qin Wu | Uploaded new revision |
2020-08-03
|
15 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Stig Venaas. Submission of review completed at an earlier date. |
2020-07-12
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-12
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-12
|
15 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-15.txt |
2020-07-12
|
15 | (System) | New version approved |
2020-07-12
|
15 | (System) | Request for posting confirmation emailed to previous authors: Xiugang Wei , Mohamed Boucadair , Jie Dong , Anders Liu , Qin WU |
2020-07-12
|
15 | Qin Wu | Uploaded new revision |
2020-07-09
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-07-09
|
14 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2020-07-09
|
14 | Robert Wilton | [Ballot discuss] I support Magnus's discuss regarding IEEE 802.1Q WG review. I also feel that the YANG model could benefit from another editorial pass: - … [Ballot discuss] I support Magnus's discuss regarding IEEE 802.1Q WG review. I also feel that the YANG model could benefit from another editorial pass: - In many places the descriptions are very terse, and references are missing. - The way that auto-neg is defined doesn't really match the 802.3 specification, probably splitting it into two separate leaves (one for whether auto-neg is on/off, and separate one for the duplex setting would be better). - The use of terminology for VLAN vs QinQ might not be acceptable to IEEE. Finding names that are more closely aligned with the terms in 802.1Q may be helpful (although if I understand it correctly, 802.1Q bridges don't directly expose double VLAN tags). Possibly some of the terminology/description from draft-ietf-netmod-sub-intf-vlan-model (which has been reviewed by IEEE 802.1Q WG) may be helpful here. |
2020-07-09
|
14 | Robert Wilton | [Ballot comment] Mostly minor/editorial comments (###) on the YANG model, but I do think that it would be helpful for these to be discussed and … [Ballot comment] Mostly minor/editorial comments (###) on the YANG model, but I do think that it would be helpful for these to be discussed and addressed as appropriate: 4. Layer 2 Topology YANG Module import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } ### These references should probably both just be: "RFC 6991: Common YANG Data Types" revision 2020-06-29 { description "Initial revision"; reference "RFC XXXX: A YANG Data Model for Layer 2 Network Topologies"; } ### I would reorder these sections to be (which will solve the forward reference issue mentioned by Ben): feature-stmt identity-stmt typedef-stmt I'm surprised that pyang didn't flag this. /* * Typedefs */ typedef vni { type uint32 { range "0..16777215"; } description "VXLAN Network Identifier or VXLAN Segment ID. It allows up to 16 M VXLAN segments to coexist within the same administrative domain. The use of value '0' is implementation-specific."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } typedef l2-flag-type { type identityref { base flag-identity; } description "Base type for L2 flags. One example of L2 flag type is trill which represents trill topology type."; } ### This isn't really a base type. Given where this flag is used, would this be better as an "network-flag-type", with a description more similar to the ones below? typedef node-flag-type { type identityref { base flag-identity; } description "Node flag attributes. The physical node can be one example of node flag attribute."; } typedef link-flag-type { type identityref { base flag-identity; } description "Link flag attributes. One example of link flag attribute is the pseudowire."; } ### Should there be identities defined for l2-flag, node-flag and link-flag that derive from flag-identity? That would them make these three typedefs reference different things rather than all referencing the same base flags. typedef l2-network-event-type { type enumeration { enum add { value 0; description "A Layer 2 node or link or termination-point has been added."; } enum remove { value 1; description "A Layer 2 node or link or termination-point has been removed."; } enum update { value 2; description "A Layer 2 node or link or termination-point has been updated."; } } description "Layer 2 network event type for notifications."; } ### Since these are events, I would suggest renaming these "add" -> "addition", "remove" -> "removal", "update" typedef neg-mode { type enumeration { enum full-duplex { description "Indicates full-duplex mode."; } enum auto-neg { description "Indicates auto-negotiation mode."; } enum half-duplex { description "Indicates half-duplex mode."; } } description "Indicates the type of the negotiation mode."; } ### What negotiation do you mean? Does this mean IEEE 802.3 auto-negotation? If so, it would be more correct to have a separate leaf for duplex vs auto-negotation. /* * Features */ feature VLAN { description "Indicates that the system supports the vlan functions (also known as an IEEE 802.1Q tag)."; } feature QinQ { description "Indicates that the system supports the qinq functions (also known as IEEE 802.1ad double tag)."; } ### I think that the description should be more clear on what is supported here: 2 VLAN tags, as defined by IEEE 802.1ad. The features should also include reference statements. Possibly we need to find a better name for these features (IEEE will possibly comment on this). feature VXLAN { description "Indicates that the device supports VXLAN functions."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } /* * Identities */ identity flag-identity { description "Base type for flags."; } ### Probably the name should be just "flag" rather than "flag-identity" identity eth-encapsulation-type { base ift:iana-interface-type; description "Base identity from which specific Ethernet encapsulation types are derived."; reference "RFC 7224: IANA Interface Type YANG Module"; } ### I would rename the base identity to probably "l2-encapsulation-type". It also probably doesn't help to derive from ift:iana-interface-type. identity ethernet { ... identity vxlan { base eth-encapsulation-type; description "VXLAN MAC in UDP encapsulation."; } ### Please add references for protocols defined in the identities. /* * Groupings */ grouping l2-network-type { Dong, et al. Expires December 31, 2020 [Page 12] Internet-Draft Layer 2 Network Topology Data Model June 2020 description "Indicates the topology type to be L2."; container l2-network { presence "Indicates L2 Network"; description "The presence of the container node indicates L2 Topology."; } } grouping l2-network-attributes { description "L2 Topology scope attributes."; container l2-network-attributes { description "Contains L2 network attributes."; leaf name { type string; description "Name of the L2 network."; ### Perhaps just "Name of the network". Are there any restrictions here on how long the name can be, can it contain spaces, etc? } leaf-list flag { type l2-flag-type; description "L2 network flags."; } } } ### Perhaps expand the description to "Flags that can be associated with the network" I would suggest changing the name of all "flag" to "flags" where they are leaf-lists. grouping l2-node-attributes { description "L2 node attributes"; container l2-node-attributes { description "Contains L2 node attributes."; leaf name { type string; description "Node name."; } leaf description { type string; description "Node description."; } leaf-list management-address { type inet:ip-address; description "System management address."; } leaf sys-mac-address { type yang:mac-address; description "System MAC address."; } leaf management-vid { if-feature "VLAN"; type dot1q-types:vlanid; description "System management VID."; ### Please change "management-vid" to "management-vlan-id", and fix the description. Probably could expand on all the descriptions of the "System" properties to explain what these system properties are and how they are used (e.g. to manage the device). } leaf-list flag { type node-flag-type; description "Node operational flags."; } } } grouping l2-link-attributes { description "L2 link attributes"; container l2-link-attributes { description "Contains L2 link attributes."; leaf name { type string; description "Link name."; } leaf-list flag { type link-flag-type; description "Link flags."; } leaf rate { type decimal64 { fraction-digits 2; } units "Mbps"; description "Link rate."; ### Please expand on this description. Does this describe how the link is operating at the physical layer, or its bandwidth? } leaf delay { type uint32; units "microseconds"; description "Link delay in microseconds."; ### Is this uni-directional delay, or bi-directional? Please clarify. leaf maximum-frame-size { type uint32; description "Maximum L2 frame size. If L2 frame is an Ethernet frame, the Ethernet header should be included; if L2 frame is other type (e.g., PPP), the L2 header should be included."; ### This needs to clarify whether the 4 byte CRC is included in the frame size. leaf eth-encapsulation { type identityref { base eth-encapsulation-type; } ### As per comments on the identities, I think that this should be "encapsulation". description "Encapsulation type of this termination point."; } leaf lag { type boolean; default "false"; description "Defines whether lag is supported or not."; ### Does this leaf indicate whether LAG is supported, or enabled on the link? } leaf-list member-link-tp { when "../lag = 'true'" { description "Relevant only when the lag interface is supported."; } type leafref { path "/nw:networks/nw:network/nw:node/" + "nt:termination-point/nt:tp-id"; } description "Member link termination points."; } leaf mode { type neg-mode; default "auto-neg"; description "Exposes the negotiation mode."; } ### Suggest changing the name to "ethernet-auto-neg-mode", and refining the description. I would also suggest splitting duplex and auto-negotiation into 2 separate leaves to more accurately represent leaf port-vlan-id { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vlan'."; } if-feature "VLAN"; type dot1q-types:vlanid; description "Port VLAN ID is the VLAN identifier that will be assigned to any untagged frames entering the switch on the specific port."; } ### Probably naming this as the "default-untagged-vlan" may be more helpful. list vlan-id-name { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vlan'."; } ### I think that I would name this list "vlans" leaf vlan-name { ### I would suggest renaming this leaf to just "name" "Interface configured SVLANs and CVLANs."; leaf svlan-id { type dot1q-types:vlanid; description "SVLAN ID."; } leaf cvlan-id { type dot1q-types:vlanid; description "CVLAN ID."; } } ### Suggest "SVLAN" => "S-VLAN" and "CVLAN" => "C-VLAN" container vxlan { when "derived-from-or-self(../eth-encapsulation" + ", 'l2t:vxlan')" { description "Only applies when the type of the Ethernet encapsulation is 'vxlan'."; } if-feature "VXLAN"; leaf vni-id { type vni; description "VXLAN Network Identifier (VNI)."; } description "Vxlan encapsulation type."; } } //case ethernet case legacy { leaf layer-2-address { type yang:phys-address; description "Interface Layer 2 address."; } leaf encapsulation { type identityref { base ift:iana-interface-type; } description "Other legacy encapsulation type of this termination point."; } } //case legacy such as atm, ppp, hdlc, etc. } //choice termination-point-type leaf tp-state { type enumeration { enum in-use { value 1; description "The termination point is in forwarding state."; } enum blocking { value 2; description "The termination point is in blocking state."; } enum down { value 3; description "The termination point is in down state."; } enum others { ### Please rename others => other value 4; description "The termination point is in other state."; ### Please modify the description to something like "The termination point is in another state, not listed in the enumeration." } } config false; description "State of the termination point."; } } } |
2020-07-09
|
14 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2020-07-09
|
14 | Magnus Westerlund | [Ballot discuss] This is a process discuss. There apparently have been a failure to coordinate this with IEEE per discussion on the IETF-IEEE mailing list. … [Ballot discuss] This is a process discuss. There apparently have been a failure to coordinate this with IEEE per discussion on the IETF-IEEE mailing list. Glenn Parsons requested that this was deferred to give IEEE time to review it at their plenary next week. I think this time should be given before approving this document. |
2020-07-09
|
14 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2020-07-08
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-07-08
|
14 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-07-08
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-07-08
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-07-08
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-07-07
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-07-07
|
14 | Christian Huitema | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Christian Huitema. Sent review to list. |
2020-07-06
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-07-06
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-07-06
|
14 | Benjamin Kaduk | [Ballot comment] Why is the "management-address" for a l2-node an IP address? Does that exclude any potential use of this data model for non-IP networks? … [Ballot comment] Why is the "management-address" for a l2-node an IP address? Does that exclude any potential use of this data model for non-IP networks? Section 3 o Links in the "ietf-network-topology" module are augmented as well with a set of Layer 2 parameters, allowing to associate a link with a name, a set of Layer 2 link attributes, and flags. Interesting that names for links were not part of the core network-topology module. Are there any potential issues if other ntework types also specify a link name and there is disagreement between them? Section 4 It reads a little oddly to use the flag-identity as the base type of a typedef before the identity itself is declared, but I am way out of my league here and defer to the YANG experts. description "VXLAN Network Identifier or VXLAN Segment ID. It allows up to 16 M VXLAN segments to coexist within the same administrative domain. The use of value '0' is implementation-specific."; Is this intended as a nod to the use of 0 for the management VLAN?/ (I seem to recall this topic raising to some level of controversy in the discussions around draft-ietf-bfd-vxlan.) /* * Features */ nit: there seems to be a spurious blank line here. grouping l2-node-attributes { [...] leaf sys-mac-address { type yang:mac-address; description "System MAC address."; } Is there only one "System MAC address" per node? leaf delay { type uint32; units "microseconds"; description "Link delay in microseconds."; I guess we don't expect to use this model for deep-space links :) container l2-termination-point-attributes { description "Containing L2 termination point attributes."; leaf description { type string; description "Port description."; Is a termination point always a "port", or should the description be modified? list qinq { [...] leaf svlan-id { type dot1q-types:vlanid; description "SVLAN ID."; } leaf cvlan-id { type dot1q-types:vlanid; description "CVLAN ID."; Could we perhaps expand "service" and "customer"? } //case ethernet RFC 6020 suggests that YANG comments are "C++-style", which would seem to indicate that the single-line comment could start on the same line as the closing brace. This, in turn, would save some confusion since the block comments apply to the content after the comment, but these comments apply to the content before the comment. (Also later on as well.) leaf tp-state { [...] enum others { value 4; description "The termination point is in other state."; } Is there a plan for how substructure of these "others" states might be added in the future? Section 6 Thank you for updating the privacy considerations in response to the secdir review! In the case of a topology that is configured, i.e. whose origin is "intended", the undesired configuration could become effective and be Perhaps toss the word "datastore" in here somewhere to remind the less-clueful reader (i.e., me) that origin is an NMDA concept? Though if it's sufficiently obvious, no need to do it just for me. reflected in the operational state datastore, leading to disruption of services provided via this topology might be disrupted. For those nit: deduplicate "disruption"/"disrupted". reasons, it is important that the NETCONF access control model is vigorously applied to prevent topology misconfiguration by unauthorized clients. Should we condense "NACM" here since we provided the acronym at the start of the paragraph? o l2-node-attributes: A malicious client could attempt to sabotage the configuration of important node attributes, such as the name or the management-address. I don't feel a need for a text change here (since "such as" suffices), but would a change to the node's MAC address be similarly impactful? Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. In particular, the YANG model for layer 2 topology may expose sensitive information, for example the MAC addresses of devices. Unrestricted use of such information can I think I've been told that in some environments the topology itself (especially VLAN/VXLAN identifiers) can be considered sensitive. What's written here is consistent with that, and I don't insist on a change to the text, but wondered if that was seen as a common enough thing to be worth mentioning. Section 8.1 RFC 3688 could arguably be demoted to informative, as could RFC 7951. Section 8.2 If we use types defined in [IEEE802.1Qcp], that seems like a normative reference to me. Noting the discussion at https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ about even optional features still being normative references, I think RFC 7348 would be better placed as a normative reference. Note that there is not a process/downref issue in doing so, since it is already listed at https://datatracker.ietf.org/doc/downref/ I could go either way (informative or normative) for RFC 8342; presumably there's a convention to stick to. Appendix B I was going to reference https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ and suggest IPv6 addresses as example management-addresses, but I have a lingering memory that the IPv4 form is still used to identify nodes even in v6-only environments. Do the right thing, of course. [Note that I did not do an extensive consistency/sanity check on the example topology or try to reconstruct it from the JSON.] |
2020-07-06
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-07-06
|
14 | Roman Danyliw | [Ballot comment] Thank you for addressing the SECDIR feedback (and thank you Christian Huitema for providing it). |
2020-07-06
|
14 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-07-03
|
14 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below a couple on non-blocking COMMENTs (and I would appreciate a reply … [Ballot comment] Thank you for the work put into this document. Please find below a couple on non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs because for some of them I was close to ballot a DISCUSS). I hope that this helps to improve the document, Regards, -éric == DISCUSS == == COMMENTS == Generic: is there a reason why the YANG validation results in 19 errors and 4 warnings? Sue Harres (the shepherd) mentions in her write-up that 9 errors are linked to missing IEEE but what about the 10 remaining errors ? Has there been a review by IEEE of this YANG model? While the shepherd is extensive and detailed, there is no mention of a coordination with IEEE. -- Section 3 -- "The Layer 2 (L2) network topology YANG module is designed to be generic and applicable to Layer 2 networks built with different L2 technologies." Is this statement correct? What about LoraWAN, Sigfox, and other LP-WAN technologies? Or technologies that may be using different MTU sizes on each direction? or having more parameters than this (such as being NBMA that should be captured). Should "sys-mac-address? " rather be "management-mac-address? " I must admit that I am not familiar with the ietf-topology YANG model, so, the following COMMENTs can be plain wrong :-( ... It is unclear to me the difference between 'node' and 'termination-point'. If not defined in the ietf-topology, then please define before first use (I had to read the YANG module to understand). Why is 'ethernet' used rather than 'ieee802', notably to cover IEEE 802.11 ? While most termination points have a single MAC address, are we sure that no termination point will ever have more than one MAC address ? 'rate' leaf is in Mbps and with 2 decimals, i.e., the lowest rate is 10 kbps and this is already higher than some layer-2 links. Any reason to ignore lower rate links ? -- Section 4 -- "leaf maximum-frame-size" please specify whether Ethernet pre-amble, inter-frame gap, and CRC should be included. The text for Ethernet and for PPP are identical, so, why repeating it ? == NITS == Sometimes 'L2' is used, sometimes 'Layer 2' is used. Not very consistent ;-) I am not an English speaker, but, I believe 'Layer 2 topology' should be written 'layer-2 topology' |
2020-07-03
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-07-02
|
14 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Meral Shirazipour. Submission of review completed at an earlier date. |
2020-07-02
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christian Huitema |
2020-07-02
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christian Huitema |
2020-07-01
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-07-01
|
14 | Cindy Morgan | Placed on agenda for telechat - 2020-07-09 |
2020-07-01
|
14 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-07-01
|
14 | Martin Vigoureux | Ballot has been issued |
2020-07-01
|
14 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2020-07-01
|
14 | Martin Vigoureux | Created "Approve" ballot |
2020-07-01
|
14 | Martin Vigoureux | Ballot writeup was changed |
2020-06-29
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-29
|
14 | Mohamed Boucadair | New version available: draft-ietf-i2rs-yang-l2-network-topology-14.txt |
2020-06-29
|
14 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-06-29
|
14 | Mohamed Boucadair | Uploaded new revision |
2020-06-26
|
14 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Meral Shirazipour. |
2020-06-25
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-06-24
|
13 | Christian Huitema | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christian Huitema. Sent review to list. |
2020-06-24
|
15 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Stig Venaas. |
2020-06-23
|
13 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2020-06-23
|
13 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-06-23
|
13 | Ladislav Lhotka | Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Ladislav Lhotka. Sent review to list. |
2020-06-22
|
13 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2020-06-22
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-06-22
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-i2rs-yang-l2-network-topology-13. 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-i2rs-yang-l2-network-topology-13. 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/ two, new namespaces will be registered as follows: ID: yang:ietf-l2-topology URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] ID: yang:ietf-l2-topology-state URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 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/ two, new YANG modules will be registered as follows: Name: ietf-l2-topology File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology Prefix: l2t Module: Reference: [ RFC-to-be ] Name: ietf-l2-topology-state File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state Prefix: l2t-s Module: Reference: [ RFC-to-be ] While the YANG module names will be registered after the IESG approves the document, the YANG module files 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-06-18
|
13 | Min Ye | Assignment of request for Last Call review by RTGDIR to Andy Smith was marked no-response |
2020-06-18
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2020-06-18
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2020-06-17
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2020-06-17
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2020-06-17
|
13 | Min Ye | Assignment of request for Last Call review by RTGDIR to Tomonori Takeda was rejected |
2020-06-17
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tomonori Takeda |
2020-06-17
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tomonori Takeda |
2020-06-17
|
13 | Min Ye | Assignment of request for Last Call review by RTGDIR to Dave Sinicrope was marked no-response |
2020-06-15
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Andy Smith |
2020-06-15
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Andy Smith |
2020-06-15
|
13 | Min Ye | Assignment of request for Last Call review by RTGDIR to Harish Sitaraman was rejected |
2020-06-14
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2020-06-14
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2020-06-14
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dave Sinicrope |
2020-06-14
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dave Sinicrope |
2020-06-11
|
13 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka |
2020-06-11
|
13 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka |
2020-06-11
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2020-06-11
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2020-06-11
|
13 | Martin Vigoureux | Requested Last Call review by YANGDOCTORS |
2020-06-11
|
13 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-06-11
|
13 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-06-25): From: The IESG To: IETF-Announce CC: i2rs-chairs@ietf.org, draft-ietf-i2rs-yang-l2-network-topology@ietf.org, martin.vigoureux@nokia.com, i2rs@ietf.org Reply-To: last-call@ietf.org … The following Last Call announcement was sent out (ends 2020-06-25): From: The IESG To: IETF-Announce CC: i2rs-chairs@ietf.org, draft-ietf-i2rs-yang-l2-network-topology@ietf.org, martin.vigoureux@nokia.com, i2rs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Data Model for Layer-2 Network Topologies) to Proposed Standard The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'A YANG Data Model for Layer-2 Network Topologies' 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-06-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model for Layer 2 network topologies. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ No IPR declarations have been submitted directly on this I-D. |
2020-06-11
|
13 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-06-11
|
13 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2020-06-11
|
13 | Martin Vigoureux | Last call announcement was changed |
2020-06-11
|
13 | Martin Vigoureux | Last call was requested |
2020-06-11
|
13 | Martin Vigoureux | Ballot approval text was generated |
2020-06-11
|
13 | Martin Vigoureux | Ballot writeup was generated |
2020-06-11
|
13 | Martin Vigoureux | Last call announcement was generated |
2020-06-11
|
13 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2020-06-11
|
13 | Martin Vigoureux | Last call announcement was changed |
2020-06-04
|
13 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2020-03-31
|
13 | Susan Hares | Note to Martin: a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. Qin Wu ha worked … Note to Martin: a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. Qin Wu ha worked through this multiple times, but it is not fixed. This note is at the top so you see it before any other part of the review. Susan Hares (shepherd) As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consensus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Yang tooling errors need to be fixed in IETF work to allow the appropriate use of IEEE references. NIT errors seem to come from the same sources. Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discussion the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: https://mailarchive.ietf.org/arch/msg/i2rs/5osiC9ILP_kX_SlbyNU5r12FVaQ/ (forwarded email) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS warnings occur, but this is a IETF Tools issue. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile with appropriate files Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-31
|
13 | Susan Hares | Responsible AD changed to Martin Vigoureux |
2020-03-31
|
13 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-03-31
|
13 | Susan Hares | IESG state changed to Publication Requested from I-D Exists |
2020-03-31
|
13 | Susan Hares | IESG process started in state Publication Requested |
2020-03-31
|
13 | Susan Hares | Note to Martin: a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. Qin Wu ha worked … Note to Martin: a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. Qin Wu ha worked through this multiple times, but it is not fixed. This note is at the top so you see it before any other part of the review. Susan Hares (shepherd) As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consensus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Yang tooling errors need to be fixed in IETF work to allow the appropriate use of IEEE references. NIT errors seem to come from the same sources. Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discussion the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: https://mailarchive.ietf.org/arch/msg/i2rs/5osiC9ILP_kX_SlbyNU5r12FVaQ/ (forwarded email) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS warnings occur, but this is a IETF Tools issue. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile with appropriate files Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-11
|
13 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-13.txt |
2020-03-11
|
13 | (System) | New version approved |
2020-03-11
|
13 | (System) | Request for posting confirmation emailed to previous authors: Anders Liu , Mohamed Boucadair , Jie Dong , Qin WU , Xiugang Wei |
2020-03-11
|
13 | Qin Wu | Uploaded new revision |
2020-03-10
|
12 | Susan Hares | Shepherd fixes needed: (3/10/2020) a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. This issue needs … Shepherd fixes needed: (3/10/2020) a) 9 errors listsed- are due to IEEE models not being loaded by IETF datatracker checking. This issue needs to be worked out with AD/Yang people. b) NITS need to be fixed - pending draft submitted. --------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consenus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Current Yang Error status: (Must be fixed) [9-errors, 2 warnings] in - https://www.ietf.org/id/draft-ietf-i2rs-yang-l2-network-topology-12.txt NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discusison the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: https://mailarchive.ietf.org/arch/msg/i2rs/5osiC9ILP_kX_SlbyNU5r12FVaQ/ (forwarded email) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile [TBD] Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-10
|
12 | Susan Hares | Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - … Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - IPR statement is needed --------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consenus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Current Yang Error status: (Must be fixed) [9-errors, 2 warnings] in - https://www.ietf.org/id/draft-ietf-i2rs-yang-l2-network-topology-12.txt NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discusison the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: https://mailarchive.ietf.org/arch/msg/i2rs/5osiC9ILP_kX_SlbyNU5r12FVaQ/ (forwarded email) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile [TBD] Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-09
|
12 | Susan Hares | Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - … Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - IPR statement is needed --------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consenus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Current Yang Error status: (Must be fixed) [9-errors, 2 warnings] in - https://www.ietf.org/id/draft-ietf-i2rs-yang-l2-network-topology-12.txt NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discusison the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: (missing) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile [TBD] Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-09
|
12 | Susan Hares | Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - … Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - IPR statement is needed --------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consenus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Current Yang Error status: (Must be fixed) [9-errors, 2 warnings] in - https://www.ietf.org/id/draft-ietf-i2rs-yang-l2-network-topology-12.txt NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discusison the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: (missing) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile [TBD] Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry requires RFC publication. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and Yang cataloge - [TBD] |
2020-03-09
|
12 | Susan Hares | Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - … Shepherd fixes needed: (3/9/2020) a) Need to find out why the 9 errors are listed, b) NITS need to be fixed c) Anders Liu - IPR statement is needed --------- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. (2/24/2012) Changes are expected over time. This version is dated 24 February 2012. (1) Type of RFC: Proposed Standard Text has: Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model for Layer 2 network topologies. [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the abstract (generic) network and network topology. Such models can be augmented with technology-specific details to build more specific topology models. This document defines the YANG data model for Layer 2 (L2) network topologies by augmenting the generic network (Section 6.1 of [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data models with L2-specific topology attributes. Working Group Summary I2RS Working group has worked on and revised this draft from 2015-2020. The working group has had strong consenus on the model. This model awaited some implementation feedback which has come in 2019-2020. Document Quality The docuemnt has been reviewed by RTG-DIR: Henning Rogge (-04): https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-rtgdir-early-rogge-2018-03-25/ Yang-DIR: (Ladislav Lhotka) https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l2-network-topology-04-yangdoctors-early-lhotka-2018-05-02/ Current Yang Error status: (Must be fixed) [9-errors, 2 warnings] in - https://www.ietf.org/id/draft-ietf-i2rs-yang-l2-network-topology-12.txt NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date Implementations of the Yang model are being worked on: https://mailarchive.ietf.org/arch/msg/i2rs/pL5HZUJnCCaNCMcDjo27_RPrfYc/ Are there existing implementations of the protocol? See link above. There are more planned as the yang models Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? A discusison the IEEE model link was done on the list by Tom Petch, Rob Wilton, and Suresh Krishnan (AD, INT). Personnel Document shepherd: Susan Hares AD: (current) Martin Vigoureux (founding AD): Alia Atlas (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. 1) Yang compilation checks examined 2) Nits Examined 3) Yang Doctor's discussion reviewed 4) Walked through Yang text (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. It will go through Yang Doctors + RTG-DIR for a final time period. The concepts in this document have been reviewed and discussed for years. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This model depends on the netconf/netmod security architecture for the NMDA datastore. As such, the concepts for the security have been walked through. The general topology and L3 model have been used in operational networks for 4+ years. (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. (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. IPR Statement: M. Boucadair https://mailarchive.ietf.org/arch/msg/i2rs/RaSjkXaypY9oDG2G-4yOPdoAVNE/ Qin Wu: https://mailarchive.ietf.org/arch/msg/i2rs/eXyYxTN0sS4PUgqEya8vBRjMx3E/ Jie Dong: https://mailarchive.ietf.org/arch/msg/i2rs/-Au60A6sCOXE2lxML9IkyheIOTo/ Anders Liu: (missing) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NITS: a) There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. b) Needs to be compiled with this year's date (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Yang modules - compile [TBD] Yang models - sent through Yang Doctors Yang models - sent through RTG Yang Review (13) Have all references within this document been identified as either normative or informative? yes - (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No - new work. Yang catolog changes based on new Yang models are consider normal updates. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirmed - normal mechanisms for yang models a) URI for models b) module names in YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. URI's for models ============= doc line # 966 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 967 Registrant Contact: The IESG. 968 XML: N/A; the requested URI is an XML namespace. 970 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 971 Registrant Contact: The IESG. 972 XML: N/A; the requested URI is an XML namespace. Module names for YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. doc line # 978 name: ietf-l2-topology 979 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 980 prefix: l2t 981 reference: RFC XXXX 983 name: ietf-l2-topology-state 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 985 prefix: l2t-s 986 reference: RFC XXXX (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. These are standard registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Yang compilation and [TBd - find out why not fixed] |
2019-10-15
|
12 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-12.txt |
2019-10-15
|
12 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2019-10-15
|
12 | Qin Wu | Uploaded new revision |
2019-08-30
|
11 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-11.txt |
2019-08-30
|
11 | (System) | New version approved |
2019-08-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Mohamed Boucadair , Qin Wu , Xiugang Wei , Anders Liu |
2019-08-30
|
11 | Qin Wu | Uploaded new revision |
2019-08-28
|
10 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-10.txt |
2019-08-28
|
10 | (System) | New version approved |
2019-08-28
|
10 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Mohamed Boucadair , Qin Wu , Xiugang Wei , Anders Liu |
2019-08-28
|
10 | Qin Wu | Uploaded new revision |
2019-08-19
|
09 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-09.txt |
2019-08-19
|
09 | (System) | New version approved |
2019-08-19
|
09 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Mohamed Boucadair , Qin Wu , Xiugang Wei , Anders Liu |
2019-08-19
|
09 | Qin Wu | Uploaded new revision |
2019-07-24
|
08 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-08.txt |
2019-07-24
|
08 | (System) | New version approved |
2019-07-24
|
08 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Mohamed Boucadair , Qin Wu , Xiugang Wei , Anders Liu |
2019-07-24
|
08 | Qin Wu | Uploaded new revision |
2019-06-24
|
07 | Qin Wu | New version available: draft-ietf-i2rs-yang-l2-network-topology-07.txt |
2019-06-24
|
07 | (System) | New version approved |
2019-06-24
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Qin Wu , Xiugang Wei , i2rs-chairs@ietf.org |
2019-06-24
|
07 | Qin Wu | Uploaded new revision |
2019-04-25
|
06 | (System) | Document has expired |
2018-10-22
|
06 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-06.txt |
2018-10-22
|
06 | (System) | New version approved |
2018-10-22
|
06 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Xiugang Wei , i2rs-chairs@ietf.org |
2018-10-22
|
06 | Jie Dong | Uploaded new revision |
2018-08-06
|
05 | Gunter Van de Velde | Closed request for Early review by OPSDIR with state 'Overtaken by Events' |
2018-08-03
|
05 | Linda Dunbar | Assignment of request for Early review by OPSDIR to Linda Dunbar was rejected |
2018-06-29
|
05 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-05.txt |
2018-06-29
|
05 | (System) | New version approved |
2018-06-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Xiugang Wei |
2018-06-29
|
05 | Jie Dong | Uploaded new revision |
2018-05-02
|
04 | Ladislav Lhotka | Request for Early review by YANGDOCTORS Completed: Ready. Reviewer: Ladislav Lhotka. Sent review to list. |
2018-04-20
|
04 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka |
2018-04-20
|
04 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka |
2018-03-25
|
04 | Min Ye | Request for Early review by RTGDIR Completed: Ready. Reviewer: Henning Rogge. |
2018-03-18
|
04 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-03-18
|
04 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com.> |
2018-03-18
|
04 | Susan Hares | Document shepherd changed to Susan Hares |
2018-03-08
|
04 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Christian Hopps |
2018-03-08
|
04 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Christian Hopps |
2018-03-07
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Henning Rogge |
2018-03-07
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Henning Rogge |
2018-03-07
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Linda Dunbar |
2018-03-07
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Linda Dunbar |
2018-03-07
|
04 | Susan Hares | Requested Early review by YANGDOCTORS |
2018-03-07
|
04 | Susan Hares | Requested Early review by RTGDIR |
2018-03-07
|
04 | Susan Hares | Requested Early review by OPSDIR |
2018-03-05
|
04 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-04.txt |
2018-03-05
|
04 | (System) | New version approved |
2018-03-05
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Xiugang Wei |
2018-03-05
|
04 | Jie Dong | Uploaded new revision |
2017-01-09
|
03 | (System) | Document has expired |
2016-11-30
|
03 | Susan Hares | Changed document writeup |
2016-07-08
|
03 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-03.txt |
2016-05-19
|
02 | Xian Zhang | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Henning Rogge. |
2016-04-25
|
02 | Xian Zhang | Request for Early review by RTGDIR is assigned to Henning Rogge |
2016-04-25
|
02 | Xian Zhang | Request for Early review by RTGDIR is assigned to Henning Rogge |
2015-12-22
|
02 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-02.txt |
2015-07-06
|
01 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-01.txt |
2015-05-26
|
00 | Susan Hares | Intended Status changed to Proposed Standard from None |
2015-05-26
|
00 | Susan Hares | This document now replaces draft-dong-i2rs-l2-network-topology instead of None |
2015-04-22
|
00 | Jie Dong | New version available: draft-ietf-i2rs-yang-l2-network-topology-00.txt |