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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Nov 2012 09:40:24 +0100

Hi,

this is the start of the 2nd WG last call on the following set of
documents:

  http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
  http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
  http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

A related document, the YANG version of the interface type and
AFN/SAFI IANA registries, had no issues raised during 1st WG last call
and has not changed:

  http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04

Please review the documents and raise any issues you might discover by
opening a thread on the mailing list. Editorial fixes can be sent
directly to the document editors.

Please indicate your support by *Friday, November 30, 2012*. We are
not only interested in receiving defect reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

/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: t.petch <[email-masked]>
Date: Fri, 23 Nov 2012 15:00:40 +0000

/ routing defines the router-id as an ipv4 address; this is wrong, it is
a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 16, 2012 8:40 AM

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Nov 2012 13:16:06 +0100

> a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.

The description says:

"Global router ID in the form of an IPv4 address. …"

And all implementations I am aware of express the 32-bit number in their configurations as a dotted quad.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 24 Nov 2012 14:32:44 +0100

> And all implementations I am aware of express the 32-bit number in their configurations as a dotted quad.

Well, for an IPv6 only network, using an IPv6 address as the router ID
might seem not really useful. My understanding is that router IDs are
indeed unsigned 32-bit integers and commonly people use an IPv4
address. This seems similar to version numbers in DNS zone files that
are numbers but it is common practice to encode a date into the
number. So I think Tom has a point when the suggests to change

         leaf router-id {
           type inet:ipv4-address;
           description
             "Global router ID in the form of an IPv4 address.

              An implementation MAY select a value if this parameter is
              not configured.

              Routing protocols MAY override this global parameter
              inside their configuration.
             ";
         }

to a different type. Perhaps it even makes sense to define a special
YANG typedef that allows a value that is either numeric or a
dotted-quad notional (although we will have then again a problem
because we need to agree on a canonical format).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Nov 2012 14:48:54 +0100

> because we need to agree on a canonical format).

One possibility would be to define "dotted-quad" datatype in ietf-inet-types and then make "ipv4-address" into a derived type of "dotted-quad". However, this looks like hyper-correctness to me - after all, real IPv4 addresses inside a packet are also 32-bit numbers. Some more explanation in the description should IMO suffice.

Lada

---

From: t.petch <[email-masked]>
Date: Tue, 27 Nov 2012 10:51:43 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Saturday, November 24, 2012 1:48 PM
On Nov 24, 2012, at 2:32 PM, Juergen Schoenwaelder

> because we need to agree on a canonical format).

One possibility would be to define "dotted-quad" datatype in
ietf-inet-types and then make "ipv4-address" into a derived type of
"dotted-quad". However, this looks like hyper-correctness to me - after
all, real IPv4 addresses inside a packet are also 32-bit numbers. Some
more explanation in the description should IMO suffice.

<tp>
Lada

I agree that all the implementations that I know of express the router
id as a dotted quad but that does not make it an IPv4 address:-(  An
IPv4 address has particular semantics, eg for 0.0.0.0 or
255.255.255.255, and many will read meaning into 10.0.0.1 or 192.168.1.2
that does not apply.

Dotted quad is also used for OSPF areas, and here 0.0.0.0 has a quite
different semantic to an IPv4 address of 0.0.0.0.  Were it SNMP, I would
put dotted quad as the display hint, with 32 bit unsigned as the type
but RFC4750 actually says
"AreaID ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
          "An OSPF Area Identifier.
           Note that the Area ID, in OSPF, has the same format
           as an IP address, but has the function of defining
           a summarization point for link state advertisements."
       SYNTAX       IpAddress"

Tom Petch
</tp>

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Nov 2012 12:47:05 +0100

>           a summarization point for link state advertisements."

I guess we have two options:

1. Add a note to "router-id" description, similar to the one in "AreaID" definition.

2. Introduce a new type, "dotted-quad" with the same definition as the current "ipv4-address". Such a type would probably belong to the "ietf-inet-types" module.

I am fine with either option, my only concern is that the latter could delay the advancement of the routing draft.

Any opinions?

Lada

---

From: t.petch <[email-masked]>
Date: Tue, 27 Nov 2012 16:58:23 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, November 27, 2012 11:47 AM

1. Add a note to "router-id" description, similar to the one in "AreaID"
definition.

2. Introduce a new type, "dotted-quad" with the same definition as the
current "ipv4-address". Such a type would probably belong to the
"ietf-inet-types" module.

I am fine with either option, my only concern is that the latter could
delay the advancement of the routing draft.

Any opinions?

<tp>
I would introduce a new type, as the right thing for the long term.  We
create this one, we use it for decades (hopefully).

Tom Petch

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2012 07:55:45 +0100

> One possibility would be to define "dotted-quad" datatype in ietf-inet-types and then make "ipv4-address" into a derived type of "dotted-quad". However, this looks like hyper-correctness to me - af…

If we talk about hyper-correctness, note that the ipv4-address type is
not just a 32-bit number since it includes support for zones. So even
if you use ipv4-address, you would have to subtype it to get rid of
the zone (or add non-machine readable description text stating that
zone information is ignored or something like that).

I assume the simplest solution is to define a router-id type in the
routing data model, something along the lines:

   typedef router-id {
     type string {
       pattern
         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
     }
     description
       "The router-id type represents the identity (a 32-bit unsigned 
        integer value) of a router in dotted-quad notation.";
   }

But then I also find this in RFC 5643:

 Ospfv3RouterIdTC ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS      current
          DESCRIPTION
               "A 32-bit, unsigned integer uniquely identifying the
               router in the Autonomous System.  To ensure
               uniqueness, this may default to the value of one of
               the router's IPv4 host addresses if IPv4 is
               configured on the router."
          REFERENCE
               "OSPF for IPv6, Appendix C.1, Global Parameters"
          SYNTAX      Unsigned32 (1..'FFFFFFFF'h)

So apparently, this is not a dotted quad notation in the MIBs anymore
for boxes that do OSPF for IPv6...

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2012 12:40:14 +0100

> zone information is ignored or something like that).

Yes, that's a good point, so the type of "router-id" is wrong in any case.

> routing data model, something along the lines:

I can do that but perhaps you could also include "dotted-quad" in the future revision of "ietf-inet-types" because it is also used in other places.

> for boxes that do OSPF for IPv6…

The CLIs of my three "reference" implementations (IOS, JUNOS, BIRD) all use the dotted quad notation.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2012 13:15:00 +0100

On Wed, Nov 28, 2012 at 12:40:14PM +0100, Ladislav Lhotka wrote:
> I can do that but perhaps you could also include "dotted-quad" in
> the future revision of "ietf-inet-types" because it is also used in
> other places.

I usually prefer to have types that carry more specific semantics.

Introducing a router-id type in the routing document may be
procedurally faster (otherwise the routing document gets a normative
dependency on the 6021bis document and likely sits a long time in the
RFC editor queue).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2012 13:26:42 +0100

> I usually prefer to have types that carry more specific semantics.

I think it is better to avoid repeating the clumsy regex patterns.
  
> dependency on the 6021bis document and likely sits a long time in the

Absolutely, and that's what I'm going to do in any case.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2012 14:03:52 +0100

> I think it is better to avoid repeating the clumsy regex patterns.

In favour of what?

There is no generic dotted-quad data type around and waiting for one
to be published as part of 6021bis will leave the routing document in
the RFC editor's queue for quite some time. Or are you now saying we
better use simply uint32?

I am confused now.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2012 18:01:38 +0100

>> I think it is better to avoid repeating the clumsy regex patterns.

In favour of having it just in one place, i.e. in the typedef of "dotted-quad".

> better use simply uint32?

No, my plan is to define the "dotted-quad" type in the routing document and use it for "router-id". This means no new downrefs for the routing document. 

If, in the future, the "dotted-quad" type appeared in a published revision of, say, "ietf-inet-type", the next revision(s) of the routing module could use that global "dotted-quad" type instead.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2012 18:16:39 +0100

> zone information is ignored or something like that).

BTW, I think there are many uses of IP addresses where zone indices are not allowed, so it might be useful to have separate types "ipv4-address" and "ipv4-address-with-zone-index", and similarly for "ipv6-*".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2012 18:35:10 +0100

> BTW, I think there are many uses of IP addresses where zone indices are not allowed, so it might be useful to have separate types "ipv4-address" and "ipv4-address-with-zone-index", and similarly fo…

Hard to judge 'many' - in many cases people forget that they actually
should support zone indexes when it is too late. ;-) Technically, it
is easy to subtype the zone index away if it is in the way.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2012 18:37:47 +0100

> If, in the future, the "dotted-quad" type appeared in a published revision of, say, "ietf-inet-type", the next revision(s) of the routing module could use that global "dotted-quad" type instead.

Well, my personal preference would be to have a semantically more
meaningful router-id type instead of an open ended dotted-quad type
but I am able to compromise on this if you feel strongly an open ended
dotted-quad type is more useful.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2012 18:57:48 +0100

> dotted-quad type is more useful.

Well, yes, I do prefer to put semantics on data nodes rather than their types.

In fact, the special semantics that Tom mentioned, like 0.0.0.0 or 255.255.255.255, do not hold universally for all IP addresses but only for their special uses, e.g. as a source or destination address, but not both.

The practical advantage is that the "dotted-quad" type can be used in other contexts, e.g. for OSPF Area ID.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Nov 2012 19:26:12 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > No, my plan is to define the "dotted-quad" type in the routing document and
> > use it for "router-id". This means no new downrefs for the routing document.
> > 
> > If, in the future, the "dotted-quad" type appeared in a published revision
> > of, say, "ietf-inet-type", the next revision(s) of the routing module could
> > use that global "dotted-quad" type instead.
> > 
> 

+1

I.e., define router-id, but no dotted-quad.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Nov 2012 08:12:55 +0100

> I.e., define router-id, but no dotted-quad.

Why, if there is only one instance of this type? What's wrong on the following definition?

      leaf router-id {
        type dotted-quad;
        description
          "Globally unique identifier of the router instance. It is
           a 32-bit number written using the dotted-quad (dot-decimal)
           notation. 

           An implementation MAY select a value if this parameter is
           not configured. For example, it can be a global IPv4 address
           that is configured on one of the interfaces of this router
           instance.

All necessary information is in one place, and a reader probably even won't need to look up
the definition of the "dotted-quad" type.

I don't understand what's "open-ended" with the "dotted-quad" type - it just represents an unsigned 32-bit integer expressed in a special notation that's widely understood. Nothing more and nothing less.

Without this type, when it comes to defining the OSPF Area ID, is the data modeller supposed to create a new type like "ospf-area-id", and copy-and-paste the same regex pattern to it? I think this is confusing and error-prone.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Nov 2012 08:17:56 +0100

> is easy to subtype the zone index away if it is in the way.

OK, so let's start with the "ietf-ip" module. Does it make any sense to allow a zone index in the value of the "address/ip" leaf? If it does, what's the zone index supposed to be?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2012 10:22:33 +0100

> OK, so let's start with the "ietf-ip" module. Does it make any sense to allow a zone index in the value of the "address/ip" leaf? If it does, what's the zone index supposed to be?

My point was that 'many' is essentially an arbitrary claim and we can
endlessly discuss this. Its pointless for making progress. I tend to
agree that address/ip in the ietf-ip likely does not need a zone
identifier since it is associated with an interface anyway. Martin?

/js

---

From: t.petch <[email-masked]>
Date: Thu, 29 Nov 2012 15:50:17 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 28, 2012 5:37 PM
> > No, my plan is to define the "dotted-quad" type in the routing
document and use it for "router-id". This means no new downrefs for the
routing document.
> >
> > If, in the future, the "dotted-quad" type appeared in a published
revision of, say, "ietf-inet-type", the next revision(s) of the routing
module could use that global "dotted-quad" type instead.
> dotted-quad type is more useful.

dotted quad, besides router Id, IPv4 address and OSPF area Id, is used
for LSR Id and LMP Node Id, which are similar to router Id; it is not
(officially) used for 4-octet AS numbers or BGP communities.

As long as router Id is not IPv4 address, I am not too fussed which way
this goes (but I hanker after SNMP display hints while realising that
they do not fit the YANG model).

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Nov 2012 22:42:40 +0100 (CET)

Hi,

>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

Here are my comments on draft-ietf-netmod-routing-cfg-06.

I think Ladislav has done a great job with this document.  My comments
are mostly editorial.

o  2.3

  Remove rip from the prefix list.  The prefix is not used in text,
  and since it is just an example module, it is nice to get rid of it
  from this list.

o  4.2

  The text mentions "destination-prefix".   It is called "dest-prefix"
  in the module.

  Also, should this section mention that this is for the ip families,
  and other modules are supposed to define their own nodes?

o  4.3

    Servers supporting only one routing table per address family MAY
    therefore decide to remove the container
    "recipient-routing-tables", together with its contents, from the
    data model.

  If we want to allow servers to not implement some nodes, we should
  use a feature.  So we should either add a feature for this case, or
  remove this text.

o  4.3

     A routing table MUST NOT appear among its own recipient routing
     tables.

   and:
               must "name != ../../name" {

   I think this is too limited.  We really want to say that there must
   not be any cycles, but we cannot express that with a simple must
   statement.  So I would prefer to add this to the description, and
   remove the must statement.

o  4.4.1

     Every router instance MUST implement exactly one instance of the
     "direct" pseudo-protocol type.  The name of this instance MUST
     also be "direct".

  Should this be:

   Every router instance MUST implement exactly one instance of the
   "direct" pseudo-protocol type.  The "direct" protocol is
   operationally used even if it is not configured.  It can be
   configured in order to disable it (?) or use filters.  If
   configured, the name of this instance MUST be "direct".

     The "direct" pseudo-protocol MUST always be connected to the main
     routing tables of all supported address families.

  I think this should be:

   The "direct" pseudo-protocol is connected to the main
   routing tables of all supported address families.

o  4.5

  Remove the last sentence:

    The default value for the route
    filter type is the identity "deny-all-route-filter".

  This is not true anymore.

o  5.2

     In addition, the "ietf-ip" module allows for configuring IPv4 and
     IPv6 addresses and subnet masks on network layer interfaces.

   s/and subnet masks/and subnet prefixed or masks/ ?

  (twice)

o  Running pyang --ietf on these module reveals two occurrences of
   statements in non-canonical order; [email-masked]:443
   and [email-masked]:156.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Nov 2012 22:47:38 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > On Nov 28, 2012, at 6:35 PM, Juergen Schoenwaelder
> > >> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder
> > >> BTW, I think there are many uses of IP addresses where zone indices are
> > >> not allowed, so it might be useful to have separate types "ipv4-address"
> > >> and "ipv4-address-with-zone-index", and similarly for "ipv6-*".
> > >> 
> > > 
> > OK, so let's start with the "ietf-ip" module. Does it make any sense to
> > allow a zone index in the value of the "address/ip" leaf? If it does, what's
> > the zone index supposed to be?
> > 
> 

I agree.  So how should we do this?  If we believe that a subtype w/o
the zone identifier is useful in general this should go into
ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
not even use a typedef).

/martin

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 29 Nov 2012 22:20:38 +0000

Hi,

I have reviewed http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08 and have just a few comments:

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

- 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?)  

- 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)?  

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

Thanks
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, November 16, 2012 12:40 AM
To: [email-masked]
Subject: [netmod] 2nd wg last call on interfaces / ip / routing data models

Hi,

A related document, the YANG version of the interface type and AFN/SAFI IANA registries, had no issues raised during 1st WG last call and has not changed:

Please review the documents and raise any issues you might discover by opening a thread on the mailing list. Editorial fixes can be sent directly to the document editors.

Please indicate your support by *Friday, November 30, 2012*. We are not only interested in receiving defect reports, we are equally interested in statements of the form:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2012 23:58:32 +0100

> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe

Yep, I would simply add a suitable simple pattern to address/ip and
declare the issue resolved.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 10:41:12 +0100

> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe

Would you mind defining the "dotted-quad" type there and using it for "ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure there will be other uses.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2012 11:15:45 +0100

> Would you mind defining the "dotted-quad" type there and using it for "ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure there will be other uses.

There is an IP address type in RFC 6021 and I think this is what we
should use unless we have concensus it is broken. I do not think it is
broken.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 11:20:43 +0100

> should use unless we have concensus it is broken. I do not think it is

It is certainly not broken and the routing module will continue using it, e. g. for "next-hop" in routes.
The "dotted-quad" type would simply enable code reuse. I see no point in having the same formidable regex patterns in multiple places.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2012 11:44:26 +0100

> The "dotted-quad" type would simply enable code reuse. I see no point in having the same formidable regex patterns in multiple places.

I believe the proper type for ipv4/address/ip is ipv4-address.

Perhaps there could be a universal dotted-quad type somewhere at
sometime. But our goal right now is to finish and deliver. Having a
dotted-quad pattern copied is not worth further delaying the
completion of this work.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 11:49:43 +0100

> I believe the proper type for ipv4/address/ip is ipv4-address.

I had the impression we all agreed that zone indices are not desirable there and therefore the "ipv4-address" type won't be used for it - at least the one from "ietf-inet-types".
 
> dotted-quad pattern copied is not worth further delaying the

If it is defined in "ietf-ip", it won't create any (new) downrefs.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2012 11:53:18 +0100

> I had the impression we all agreed that zone indices are not desirable there and therefore the "ipv4-address" type won't be used for it - at least the one from "ietf-inet-types".

The ipv4-address type is more generic, so you subtype it to make it
specific to what ipv4/address/ip needs. This can very easily be done
inline of the leaf definition. Not a big deal, get it done, move on.

> If it is defined in "ietf-ip", it won't create any (new) downrefs.

But then it will still be in the wrong place. And ietf-ip won't 
need this type since ipv4/address/ip is an ipv4-address (and
ipv6/address/ip is an IPv6 address without a zone id).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 13:35:20 +0100

Hi Martin,

thanks for the review, I applied most of your suggestions, and below are my comments to the rest.

>   use a feature.  So we should either add a feature for this case, or

OK, I will add a new feature "multiple-routing-tables".

>    remove the must statement.

No, I think it is correct. Cycles are permitted, the simplest case being a pair of routing tables that receive routes from each other. Because of route filters, this may be actually quite useful. 

>    configured, the name of this instance MUST be "direct".

OK, I will use this formulation. This is where the missing link between configuration and state data makes things complicated. 

I will also disable the "connected-routing-tables" node for the "direct-protocol", by means of a "when" or "must" constraint.

>    and [email-masked]:156.

Yes, and thanks for correcting it.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 16:15:51 +0100

Hi,

>   http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07

I reviewed both drafts and I think they now fulfil the stated objectives. I especially like the approach to interface layering, it is simple yet clever.

Here are my comments:

** draft-ietf-netmod-interfaces-cfg-08

*** Section 3.3

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.

*** 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"?

** 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.
    - 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. I think it is not very practical to use a
      restriction of said types because it probably means that
      validation of each configured IP address would involve matching
      it against two regular expressions where the expression in the
      definition of "inet:ipv[46]-address" type is completely
      redundant.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2012 16:51:05 +0100

> inline of the leaf definition. Not a big deal, get it done, move on.

Not a big deal for human readers, if they never mind the regular expressions, but it means a performance penalty for automatic validation. Given that something like 95 % IP addresses appearing elsewhere in configurations or state data will not use zone indices, I am not sure it is worth the extra cycles. Perhaps a better model for those places that permit zone indices would be

<ip-address>1.2.3.4</ip-address>
<zone-id>eth0</zone-id>

with zone-id being optional.

Lada