Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt

From: [email-masked]
Date: Sun, 25 Aug 2013 13:38:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

	Title           : A YANG Data Model for IP Management
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-ip-cfg-10.txt
	Pages           : 33
	Date            : 2013-08-25

Abstract:
   This document defines a YANG data model for management of IP
   implementations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 25 Aug 2013 22:57:34 +0200 (CEST)

Hi,

> 	Filename        : draft-ietf-netmod-ip-cfg-10.txt

This draft adds IP state data to /interfaces-state/interface (assigned
addresses) and to /ip-state (neighbors).

In the /if:interfaces/if:interface/ipv6/address/status leaf, I blindly
copied the corresponding enumeration from IP-MIB, IpAddressStatusTC.
But I do not know if this is correct, or if we should use only the
three states defined in RFC 4862 - preferred, deprecated and
tentative.  (and other or unknown makes sense).  For example, the
value 'invalid' is used in the MIB, but 4862 says that an invalid
address is "an address that is not assigned to any interface [...]".
So how can it be reported?  Also, 'duplicate' is a value in the MIB,
but 4862 says: "A tentative address that is determined to be a
duplicate as described above MUST NOT be assigned to an interface" so
it unclear again how it can be reported.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Aug 2013 15:27:14 +0200

> addresses) and to /ip-state (neighbors).

Thanks for the update!
 
> it unclear again how it can be reported.

Since this is in the config false state tree, I think we are fine even
if certain enums never show up in certain implementations.

While reading through the new revision, I found the following little
nits (in general the document seems to be in good shape):

a) There are some outdated references, see id-nits.

b) In the example in Appendix A, please s/DB8/db8/ since the canonical
   representation of IPv6 addresses uses lowercase characters.

c) The introduction is extremely terse. Perhaps add a few more
   sentences summarizing that the document covers the configuration of
   IPv4 and IPv6 interfaces as well as mappings to link-layer
   addresses and that it provides information which addresses are
   operationally used and which link-layer mappings do exist.

d) The data model uses a number of presence containers. I am wondering
   whether all of them make sense as presence containers.

   /if:interfaces/if:interface/ipv4
   /if:interfaces/if:interface/ipv6

   These two really do not carry any semantics or at least the textual
   description "Configure IPvX on this interface" leaves it unclear
   what one has to implement. Why are these presence containers?

   /if:interfaces-state/if:interface/ipv4
   /if:interfaces-state/if:interface/ipv6
   /ip-state/ipv4
   /ip-state/ipv6
   
   These leafs indicate that IPvX is enabled and hence they do
   actually carry semantics - if they do not show up, then
   /if:interfaces/if:interface/ipvX/enabled is most likely false.

   [Perhaps a future revision of the tree diagram should have a way to
    indicate presence containers so that they are easier to spot.]

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 27 Aug 2013 22:29:10 +0200 (CEST)

Hi,

> a) There are some outdated references, see id-nits.

Ok.

>    representation of IPv6 addresses uses lowercase characters.

Ok.

>    operationally used and which link-layer mappings do exist.

Ok; your words rephrased a bit:

  The data model covers configuration of per-interface IPv4 and IPv6
  parameters, and mappings of IP addresses to link-layer addresses.
  It also provides information about which IP addresses are
  operationally used, and which link-layer mappings exist.

>    what one has to implement. Why are these presence containers?

Since we have an 'enabled' leaf with a default value of 'true' under
these containers, it means that once the container is created, by
default IP is enabled.  If we made them np-containers, we'd have to
change the default of 'enabled' to 'false'.  (unless we want to by
default enable ipv4 and ipv6 on all (capable) interfaces, but I don't
think we want that).

>    /if:interfaces/if:interface/ipvX/enabled is most likely false.

Yes.

>     indicate presence containers so that they are easier to spot.]

Actually they are.  Compare:

   +--ro ip-state
      +--ro ipv4?

ip-state is an np-container and ipv4 is a p-container.

Maybe the description of the symbol '?' could be made more explicit.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Aug 2013 23:06:09 +0200

> default enable ipv4 and ipv6 on all (capable) interfaces, but I don't

OK, I see. This needs better explanation I think. The phrase
"Configure IPvX on this interface" is not sufficient - I missed the
subtle point of the enabled default value. Perhaps something like
this (feel free to find a better wording):

  "Presence of the ipvX enables IPvX unless the enabled leaf
   (which defaults to 'true') is set to 'false'"
 
> Maybe the description of the symbol '?' could be made more explicit.

The text says:

   o  Symbols after data node names: "?" means an optional node

I would prefer to not overload "?" with the presence/non-presence
distinction. I would rather prefer to have something more like a
warning sign:

    +--ro ip-state
       +--ro ipv4!

   o An exclamation mark "!" after a container indicates that the
     container is a presence container.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Aug 2013 08:37:58 +0200

>    (which defaults to 'true') is set to 'false'"

It might also be useful to explain that the purpose of the "enabled" leaf in fact is to allow for disabling IPvX while keeping the configuration, i.e. to override the presence function of the "ipvX" container. This could go to the description of "enabled".
 
>      container is a presence container.

+1

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Aug 2013 11:46:18 +0200

>    (which defaults to 'true') is set to 'false'"

One more question. Should this same pattern be applied to

      +--rw system
      |  +--rw ntp
      |     +--rw enabled?   boolean

in draft-ietf-netmod-system-mgmt-08.txt? The ntp container here is not
a presence container.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Aug 2013 12:42:02 +0200

> in draft-ietf-netmod-system-mgmt-08.txt? The ntp container here is not

IMO, yes.

I also think there should be "ntp" and "dns-resolver" items under "system-state" because in both cases there is currently no way for the client to learn addresses of servers that were obtained from DHCP.

Lada