Reviews and responses for ietf-netmod-intf-ext-yang

[samans]

There is a section per review. My answers/proposed resolution is marked with a bullet point.

review-ietf-netmod-intf-ext-yang-17-genart-lc-enghardt-2025-10-10-00

https://datatracker.ietf.org/doc/review-ietf-netmod-intf-ext-yang-17-genart-lc-enghardt-2025-10-10/

Minor issues:

Section 9 (Security Considerations) has RFC AAAA, but I don't see where that
reference is defined. Please double-check that this reference is clear.

• RFC 9907 will be used. Replace all references to RFC 8407 and 8407bis to RFC 9907.

Nits/editorial comments:

Are Sections 2 and 3 the high level descriptions and Sections 4 and 5 the
formal specifications? The headings are not clear about this, as the difference
between them is "Module" VS "YANG module". Please consider changing the
headings to make the structure of the document clearer.

• The section names have been changed for clarity. Each module has a section for introduction and a separate section for the module itself.
  • 2 Interface Extensions YANG Module Introduction
  • 3 Interfaces Ethernet-Like YANG Module Introduction
  • 4 Interface Extensions YANG Module
  • 5 Interfaces Ethernet-Like YANG Module

In Section 9, if there are no particularly sensitive nodes, does this text need
to be included at all?

• Security Considerations is included because it is required per RFC 7322

review-ietf-netmod-intf-ext-yang-17-tsvart-lc-scharf-2025-09-25-00

https://datatracker.ietf.org/doc/review-ietf-netmod-intf-ext-yang-17-tsvart-lc-scharf-2025-09-25/

The security considerations for write access are generic. Specifically, I
wonder if it makes sense to mention the security implications of changing the
MAC address (e.g., ARP spoofing). Other writeable parameters can also have
security implications, e.g., if the MTU gets affected.

• Security Considerations section follows the template in RFC 9907, nothing is particularly sensitive so suggestion from RFC 9907 is used.

All examples are in JSON encoding. Is XML encoding for NETCONF really already
dead?

• JSON is preferred by the authors

Nits:

I got a bit confused by the abstract that mentions the MTU, while the YANG
module actually defines a maximum frame size.

• Just an example. Could take it out.

Several acronyms such as "MTU", "QOS", "OTN", "DWDM", ... are not expanded.
Some may be obvious, but, for instance, I am not sure if all network engineers
know OTN. And, BTW, I often see the spelling "QoS" for Quality-of-Service.

• RFC 7322 points to https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list which includes the list of abbreviations that don't need to be expanded on first use.

[RFCAAA] in Section 9 should probably be [RFC8407]

• RFC 9907 is used.

review-ietf-netmod-intf-ext-yang-17-opsdir-lc-jiang-2025-10-11-00

https://datatracker.ietf.org/doc/review-ietf-netmod-intf-ext-yang-17-opsdir-lc-jiang-2025-10-11/

There are a few acronyms terms has no explanation. They should be expanded when
they first appear. Section 9 has an open quate [RFCAAAA], which should be
replaced by an real RFC number.

• RFC 7322 points to https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list which includes the list of abbreviations that don't need to be expanded on first use.
• RFC 9907 is used.

review-ietf-netmod-intf-ext-yang-17-intdir-lc-matsushima-2025-10-11-00

https://datatracker.ietf.org/doc/review-ietf-netmod-intf-ext-yang-17-intdir-lc-matsushima-2025-10-11/

The lower/higher-layer-if definitions in RFC8343 would need to be better to
clarify the differences between sub-interface defined in this draft.

• TBD

How the module can manage linux networking abstraction for example, bridge,
vrf interfaces would be better to mention in somewhere, like if a vlan
interfaces has one parent ethernet interface, the vlan interface also have the
bridge or vrf interface as another parent (or master). Please check whether the
module support that or not.

• This draft is meant to support devices that have a generic networking capability, this could include routers, bridges, switches, etc. This could be mapped to the linux networking stack, but that description is out of scope of this draft.

A peer-interface of an interface pair would usually be associated to a netns.
It would be better to mention that, and would be better to make the module to
be able to do that.

• See https://datatracker.ietf.org/doc/rfc8529/ and look at page 6 in the tree for:
  augment /if:interfaces/if:interface:
  +--rw bind-ni-name? -> /network-instances/network-instance/name
  augment /if:interfaces/if:interface/ip:ipv4:
  +--rw bind-ni-name? -> /network-instances/network-instance/name
  augment /if:interfaces/if:interface/ip:ipv6:
  +--rw bind-ni-name? -> /network-instances/network-instance/name
  This is how any interface is bound to a network instance. Which appears to be a linux network namespace.

review-ietf-netmod-intf-ext-yang-16-yangdoctors-early-bierman-2025-03-31-00

https://datatracker.ietf.org/doc/review-ietf-netmod-intf-ext-yang-16-yangdoctors-early-bierman-2025-03-31/

I found 1 nit in ietf-if-ethernet-like:mac-address

OLD:

  leaf mac-address {
    if-feature "configurable-mac-address";
    type yang:mac-address;
    description
      "The MAC address of the interface.  The operational value
       matches the /if:interfaces/if:interface/if:phys-address
       leaf defined in ietf-interface.yang.";
  }

NEW:
leaf mac-address {
if-feature "configurable-mac-address";
type yang:mac-address;
description
"The MAC address of the interface. The operational value
matches the /if:interfaces/if:interface/if:phys-address
leaf defined in the ietf-interfaces YANG module (RFC 8343).";
}

• Implement suggestion

Additional:
Update the acknowledgement page.