Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2012 09:28:32 +0100 (CET)

"Alexander Clemm (alex)" <[email-masked]> wrote:
> - leaf location (p13):
> It seems to make sense to add a clause analogous to the description in
> leaf "name" that spells out what happens if an application were to try
> to set location in a manner that is invalid.  There, it states "If a
> NETCONF server that implements this restriction is
> sent a value that doesn't match the restriction, it MUST
> reply with an rpc-error with the error-tag
> 'invalid-value'."

Ok.  How about this description:

OLD:
          "The device-specific location of the interface of a
           particular type.  The format of the location string
           depends on the interface type and the device.

NEW:
          "The device-specific location of the interface of a
           particular type.  The format of the location string
           depends on the interface type and the device.  If a
           NETCONF server is sent a value that doesn't match this
           format, it MUST reply with an rpc-error with the error-tag
           'invalid-value'.

> - leaf enabled (p13):
> Just as a thought, here is always a possibility that an application
> does not initially populate all leaves when creating an interface, but
> sends them e.g. in successive operations.  That raises the question
> when the interface should actually go into effect .  Would it make
> sense to add a clause to the description that states that if an
> interface is initially created but does not yet contain all the
> settings, an application SHOULD set the leaf to "enabled=false"?  (Or
> should perhaps even the default be false, not true, for that reason to
> require explicit turning on of the interface when the configuration is
> fully ready?)

It is trivial for an application to set enabled to false when it
creates the interface, if it cannot set all parameters at once.

> - leaf oper-status, enum value "not-present" (p14): I am wondering if
> the description can be made a little more specific - the precise
> meaning of "some component is missing" is not clear.  At a minimum,
> the enum description should add what is stated further below
> (typically, missing hardware components)?

This text is copied from the MIB.  But we can at least do what you
suggest:

              "Some component (typically hardware) is missing.";

> - leaf last-change (p15):
> Would it make sense to name this "last-oper-change"?  "last-change"
> could also be interpreted to mean "last config change", but this is
> not what is meant here.

The corresponding MIB object is called ifLastChange, and whenever a
YANG node has the same semantics as the corresponding MIB object, we
try to not rename them (except to follow YANG conventions).

This said, I agree with your concern, and I think last-oper-change is
a better name.  What do other people think?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2012 09:41:08 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> OLD
> 
>    There are two state data leaf-list nodes "higher-layer-if" and
>    "lower-layer-if" defined, that contains a read-only view of the
>    interface layering hierarchy.
> 
> NEW
> 
>    Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
>    represent a read-only view of the interface layering hierarchy.

Ok.

> *** Appendix E.1
> 
> Since the IANA type doesn't discriminate fast and gigabit ethernet,
> what is supposed to happen if a physical interface is pre-provisioned
> as "fastethernet-1/0" and then a gigabit ethernet port appears at
> location "1/0"?

This would be up to the vendor, but I'd expect that if a vendor
discriminates between fastethernet and gigabitethernet in the name, it
would not apply the fastethernet config to a gigabitethernet port.  I
understand your concern that this essentially puts type information
that is not available in 'type' into the name.

> ** draft-ietf-netmod-ip-cfg-07
> 
> *** Section 4
> 
>     - Why are the defaults for "prefix-length" set to 32 for IPv4 and
>       128 for IPv6? Such values are only useful for loopback
>       interfaces. I'd recommend to remove the defaults and make these
>       leafs mandatory.

I think these defaults were suggested by someone on the list?  Anyway,
I would like to hear other people's opinion as well before changing
this.

>     - As we've been discussing in a separate thread, the "ip" leafs
>       should not use the "inet:ipv[46]-address" types because of the
>       zone indices.

Yes, will be fixed.

/martin