[netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

[Ladislav Lhotka <[e-mail]>]

Hi,

I think this is a very useful addition to ietf-interfaces. In general,
the document is clearly written and YANG modules nicely designed. Here
are my comments:

*** Sec. 1
    - "This document defines two YANG RFC 7950 [RFC7950] modules …"
      looks weird. I'd suggest "… YANG 1.1 [RFC7950] …" instead.
*** Sec. 2
    - first line: s/of of/of/
*** Sec. 3.1
    - If the "bandwidth" parameter is only used for tuning routing
      algorithms and has nothing to do with real bandwidth on the
      interface, I would suggest to use a different name
      (metric?). Perhaps it may indeed be better to leave this to
      routing protocol modules because they can also specify how
      exactly such a parameter is used.
*** Sec. 3.6
    - The "l3-mtu" parameter is probably the same as "mtu" defined in
      ietf-ip. Again, I would suggest to leave the definition of MTU
      to each L3 protocol because there may be specific aspects and
      constraints.
*** Sec. 3.8
    - I think that "transport-layer" is not a good name because in the
      ISO OSI model it denotes a particular layer (L4). How about
      "iso-osi-layer"?
    - The type of "transport-layer" has three enums, namely
      "layer-[123]". I would suggest to use descriptive names
      ("physical-layer" etc.), include the remaining layers of the ISO
      OSI model, and maybe also define it as a typedef - or does this
      belong to ietf-inet-types?
    - Is a leaf sufficient? I think some interfaces can be in multiple
      layers at the same time (e.g. an ATM interface is L3 but can
      also be L2 for Classical IP over ATM). Or is the idea that such
      an interface will be split into two entries of the "interface"
      list?
*** YANG modules
    - Descriptions are not consistently formatted. I think that the
      current BCP is to start description text on the same line as the
      "description" keyword only if it all fits on one line.
    - I don't have a strong opinion on this but it might increase
      readability if the number of augments is reduced. Perhaps at
      least augments that contain only one node could be made into one
      (and the "feature" and "when" statements moved to the nodes'
      definitions.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67