Skip to main content

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