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

[Robert Wilton <[e-mail]>]

Hi Lada,

Thanks for the review and comments.


On 21/12/2016 13:08, Ladislav Lhotka wrote:
> 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.
OK.
> *** 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.
Yes, possibility it would be better to define this as part of the 
routing models.  The idea here is that the bandwidth would span across 
the routing protocols rather than be tied to a specific protocol.

> *** 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.
The MTU being defined here is an "l2-mtu" parameter.  I.e. the maximum 
size of the L2 frames that can be sent/received.  For some devices this 
value is independent of a protocol specific L3 MTU that only affects 
that particular protocol instance.

> *** 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?
This needs some further thought/work.

The main idea here was to be able to label sub-interfaces as supporting 
only L2 services or L3 services, since on some platforms different types 
of interfaces get instantiated internally.

> *** 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.
Yes, I'll fix these, probably using Martin's suggested approach.

Thanks again,
Rob

>
> Lada
>