Subject: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121)

From: David Kessens <[email-masked]>
Date: Fri, 4 Nov 2011 03:16:28 -0700

Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt
http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt

The drafts seem to stabilized enough so it is time to determine whether
they are ready to be send to the IESG for approval.

Please indicate your support by Nov 21 2011, but preferably before our
working group session on Nov 15. I would like to see at least three reviews
of the drafts to make sure that we have had sufficient review to move them
to the next level so please indicate whether you have reviewed the current
drafts when you state your support.

Thanks!

David Kessens
co-chair netmod wg
---

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 04 Nov 2011 17:19:47 +0100

I read

    draft-ietf-netmod-interfaces-cfg-02.txt

And I believe it is ready and in good shape for
sending it to our AD for publication as PS.

A few nits/questions (no showstoppers):
- I have not been following all the YANG discussions
   close enough (I fear). So when I see in sect 3:

       +--rw enabled?                    boolean
       +--ro if-index*                   int32

   Then I wonder: what the ? mark and the asterisk mean
   here? Is  that documented somewhere?
   Think of many readers, few writers for YANG documents.

- I see
      leaf link-up-down-trap-enable {
   I understand this comes from the IF-MIB,
   but would we not rather call them events
   or notifications? Do we really want to
   carry around the "trap" terminology around
   for the rest of our lives?

- page 11 toward the end:
      not operate on top of any other intertface (as defined in
   s/intertface/interface/

- page 20
   Eth0 nicely uses the example IP address from range 192.0.2.0/24
   Eth1 however uses <ip>192.168.1.1</ip> ??
   I understand that with preflength of 24 this is the only
   way to differentiate the (sub-)networks
   So I can live with it. But formally it would not be allowed to
   be used in examples.

Bert

On 11/4/11 11:16 AM, David Kessens wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 05 Nov 2011 20:33:52 +0100 (CET)

Hi,

>   Think of many readers, few writers for YANG documents.

This is not defined in any standard; it happens to be the output from
pyang (-f tree).  '?' means optional leaf (zero or one), and '*' means
leaf-list (zero or many).

But this figure is intended to show the structure of the YANG module,
so if it helps I think we can remove the '?' and '*'.

>   for the rest of our lives?

The MIB leaf is called ifLinkUpDownTrapEnable, and in order to not
confuse users I think it is best to use the same name.  David
Harrington also shared some experience around this in
http://www.ietf.org/mail-archive/web/netmod/current/msg05533.html.

>      not operate on top of any other intertface (as defined in

Fixed.

>   So I can live with it. But formally it would not be allowed to

I changed this to 198.51.100.1, using the 198.51.100.0/24 block as
defined in RFC 5737.

(I also did s/NETCOMF/NETCONF/)

/martin

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 6 Nov 2011 11:02:36 +0100

Inline

----- Original Message ----- 
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, November 05, 2011 8:33 PM
Subject: Re: [netmod] My review for Last 
Call:draft-ietf-netmod-interfaces-cfg-02.txt

> so if it helps I think we can remove the '?' and '*'.

Well, I do think that the inof is useful./helpful. So why not add a line of text
that says something like:

   In the below diagram, a '?' means optional leaf (zero or one), and a '*'
   means  leaf-list (zero or many).

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 06 Nov 2011 11:49:32 +0100

Dne 6.11.2011 11:02, Bert Wijnen (IETF) napsal(a):
> Inline
>
> ----- Original Message ----- From: "Martin Bjorklund" <[email-masked]>

+1

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Sun, 6 Nov 2011 13:43:19 -0500

>   means  leaf-list (zero or many).

Are you inventing a new syntax for YANG using ascii art?  Do you
want to use the UML style of "0..1" and "0..infinity"?  Or is this
even a good idea at all?

How about it we give YANG reader YANG terms instead?  We don't
need to confuse them with this new diagraming syntax.  Make
a column for "leaf", "leaf-list", "container", etc and a
column for mandatory.  Or use real text:

    +-- description (an optional, writable leaf of type string)
    +-- type (a mandatory, writable leaf of type ianaift:iana-if-type)

Inventing a new syntax here is just a very bad idea.

Why is "if-index" not writable?

(No, I've not read the document, but think this is a bug).

And why is enabled the knob instead of disabled, since it
will have to be set on 99.9% of interfaces?  It makes a
common source of errors that you can easily remove.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 6 Nov 2011 20:24:52 +0100

> Inventing a new syntax here is just a very bad idea.

I (as a reader) find the compact tree diagram extremely useful to get
a quick to read and fast to understand overview.

/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: Andy Bierman <[email-masked]>
Date: Sun, 06 Nov 2011 11:49:24 -0800

> a quick to read and fast to understand overview.

I agree, but the syntax should be explained.
There are 2 goals here, which may not be obvious:

    1) provide quick lookup of data tree structure
    2) avoid redundant or inconsistent normative text that results from
       a traditional introduction section

> /js

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 7 Nov 2011 01:40:47 -0500

>a quick to read and fast to understand overview.

Looks like it's trying to be relax-ng compact form.  The
best way to help folks learn YANG is to use YANG terms,
like "leaf-list" instead of "*".  You may be able to
make this jump, but newer readers will not.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Nov 2011 10:10:04 +0100 (CET)

Hi,

Phil Shafer <[email-masked]> wrote:
> Are you inventing a new syntax for YANG using ascii art?

No.

> Do you
> want to use the UML style of "0..1" and "0..infinity"? 

No.

> Or is this
> even a good idea at all?
>
> How about it we give YANG reader YANG terms instead?

As Juergen et. al. already pointed out, this figure is there to show
the *structure* of the data model (which, incidentally, the document
also says).  It is not a YANG replacement.

Ok, maybe the point is more clear if we do:

OLD:

The module "ietf-interfaces" has the following structure:

NEW:

The data model defined in the module "ietf-interfaces" has the
following structure:

> We don't

First, this would not solve the same problem (display the structure of
the data model), and second, I definitely don't think we need another
syntax for YANG.

> Why is "if-index" not writable?

ifIndex is not config in the MIB, and this node just reflects the MIB
defintion.

> common source of errors that you can easily remove.

The default value is "true" which means that for 99.9% of the
interfaces you don't see it anyway.

If we rename this to "disabled", I think maybe it should be of type
"empty".

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 10:46:19 +0100

I did read this document and agree that it is ready
for publication as stds track RFC.

My understanding is that new ifTypes (enumerations) or
changes (depracating) can ONLY be made in this module
if a corresponding addition or change if made to the
ianaIftype-MIB module.

This I conclude from the IANA Considerations clause.

Is this clear to everyone, also new readers (i.e.
people who are not so familiar with SNMP and MIB
modules?

Bert

---

From: Phil Shafer <[email-masked]>
Date: Mon, 7 Nov 2011 06:55:04 -0500

>also says).  It is not a YANG replacement.

My point is that the first few YANG modules will make a huge precedent
that folks are sure to follow.  By making this structure diagram
using non-YANG terms you are teaching readers to thing "*", "?",
etc instead of using YANG terminology.

>ifIndex is not config in the MIB, and this node just reflects the MIB

But if-index needs to be configable if one wants to tell
the box which if-index to use.kkk

>If we rename this to "disabled", I think maybe it should be of type

Yes, I'd prefer to see if done that way.

Thanks,
 Phil

---

From: Per Hedeland <[email-masked]>
Date: Mon, 07 Nov 2011 13:52:55 +0100

> Yes, I'd prefer to see if done that way.

I disagree - a non-negated boolean seems much clearer to me, and as
Martin pointed out, there is no operational difference - since the
default is "true", you need neither set it nor see it for an enabled
interface. Well, the difference is that you would have to do (the
NETCONF equivalent of) 'delete disabled' instead of 'set enabled true'
to enable a previously disabled interface - not a win as far as I can
see.

--Per Hedeland

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Nov 2011 14:01:34 +0100

> etc instead of using YANG terminology.

I also like the compact graphical representation (and often find myself 
runing "pyang -f tree ..."). And I don't think it competes with YANG 
terminology in any way.

> Yes, I'd prefer to see if done that way.

I agree with Phil here. Actually, we also have the 'presence' flag on 
containers for this purpose but I haven't seen any use of them so far. I 
guess it is because 'presence' doesn't allow for pre-configuring the 
function but keeping it disabled.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Nov 2011 14:12:27 +0100

> to enable a previously disabled interface - not a win as far as I can

We also have to take into account the different  modes of handling 
defaults. With "report-all", the 99.9 % "enabled" leafs can be a real 
nuisance. <disabled/> works the same in all modes.

Moreover, an empty 'disabled' leaf is IMO slightly more readable in 
XPath expressions, e.g.

when "not(disabled)";

versus

when "enabled = 'true'"

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Nov 2011 21:01:31 +0100 (CET)

Hi,

> This I conclude from the IANA Considerations clause.

The Introduction also says:

  This document defines the initial version of the iana-if-type YANG
  module.  This module reflects IANA's "ifType definitions" registry.

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 21:14:49 +0100

Inline

On 11/7/11 9:01 PM, Martin Bjorklund wrote:
> Hi,
>
> "Bert Wijnen (IETF)"<[email-masked]>  wrote:
In the end, the netmod-iana-if-types YANG module will live its own live
on the IANA web pages. Probably best to be specific in the MODULE
DESCRIPTION clause. At least in my opinion, which is of course just one
opinion.

Bert

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Nov 2011 21:36:00 +0100 (CET)

"Bert Wijnen (IETF)" <[email-masked]> wrote:
> DESCRIPTION clause. 

Ah, ok.  So what do you suggest?  Is just adding:

  This module reflects IANA's "ifType definitions" registry.

enough?  Should we also mention that the module is maintained by IANA?

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 22:22:45 +0100

> enough?  Should we also mention that the module is maintained by IANA?

Yep, and stating that it is maintained by IANA also makes sense in my view.

Bert