Subject: [netmod] LL review of interfaces-cfg-01

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 10:11:24 +0200

Hi,

I think the module is well designed and has the potential to fulfill the stated objectives.

Comments:

1. My main concern is the (lack of) extensibility of the "type" leaf. Even if 
   iana-if-type covered all interface types that are currently in use, adding
   a new (e.g. experimental) interface type is not easily possible. I'd therefore 
   recommend to change the type to an identity.

2. The term "object" is used in several places of the text, e.g. in Section 3.3:
   "It is expected that interface type specific models define their own objects for 
   interface layering, ... ". YANG doesn't use this term, so I suggest to either
   change it or provide a definition.

Lada
    
--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jul 2011 10:53:58 +0200 (CEST)

Hi,

Thank you for your review!

>    recommend to change the type to an identity.

Well, I agree with you.  But the WG decided it was more important to
align with the current interface type enumeration maintained by IANA,
than to have this extensibility.

>    change it or provide a definition.

Ok, I will change this to 'nodes'.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 11:06:45 +0200

> than to have this extensibility.

Why can't it be an identity instead of an enumeration (with the same contents)?
Other modules modules can then either use an IANA-registered type or simply define a new one.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 11:09:08 +0200

> than to have this extensibility.

We have bad experience with several type numbers allocated for what
essentially is an ethernet interface. If we make this an identity, we
kind of encourage vendors to be too creative. The IANA allocation
procedure is not that hard to execute (at the moment it is essentially
Dan reviewing the request).

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 11:27:38 +0200

> kind of encourage vendors to be too creative. The IANA allocation

If there is demand, vendors will find workarounds that might be even worse. The pros and cons here are quite similar to those of deviations.

> Dan reviewing the request).

But what about the YANG module "iana-if-type"? A new revision is likely to take longer.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 11:55:11 +0200

> But what about the YANG module "iana-if-type"? A new revision is likely to take longer.

No, we (Martin and myself) did talk to IANA at the last IETF and IANA
does not see this to be a problem.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jul 2011 12:03:59 +0200 (CEST)

> does not see this to be a problem.

Right, and to elaborate; when IANA registers a new interface type,
they will update the registry, the MIB, and the YANG module at the
same time.  The latest version is published only on the IANA web site.

/martin