Skip to main content

IETF Last Call Review of draft-ietf-netmod-intf-ext-yang-17
review-ietf-netmod-intf-ext-yang-17-intdir-lc-matsushima-2025-10-11-00

Request Review of draft-ietf-netmod-intf-ext-yang
Requested revision No specific revision (document currently at 19)
Type IETF Last Call Review
Team Internet Area Directorate (intdir)
Deadline 2025-10-11
Requested 2025-09-22
Requested by Mahesh Jethanandani
Authors Robert Wilton , Scott Mansfield
I-D last updated 2026-06-19 (Latest revision 2026-06-19)
Completed reviews Yangdoctors Early review of -04 by Andy Bierman (diff)
Yangdoctors Early review of -16 by Andy Bierman (diff)
Intdir IETF Last Call review of -17 by Satoru Matsushima (diff)
Opsdir IETF Last Call review of -17 by Sheng Jiang (diff)
Tsvart IETF Last Call review of -17 by Michael Scharf (diff)
Genart IETF Last Call review of -17 by Reese Enghardt (diff)
Assignment Reviewer Satoru Matsushima
State Completed
Request IETF Last Call review on draft-ietf-netmod-intf-ext-yang by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/Kb87EXfV2OW0GyGkvX3a3GBHBFY
Reviewed revision 17 (document currently at 19)
Result Ready w/nits
Completed 2025-10-11
review-ietf-netmod-intf-ext-yang-17-intdir-lc-matsushima-2025-10-11-00
Reviewer: Satoru Matsushima
Review Result: Ready with Nits

I have reviewed this document as part of the IntArea directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the internet area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

Overall this draft was well written and very useful not only from ops view but
from the int-area point of view as well, suppress-flapping, dampening to make
network stable.

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

- 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.

- 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.