Subject: [netmod] draft minutes of the NETMOD 2014-10-01 virtual interim meeting

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2014 14:08:01 +0200

Hi,

attached are the draft minutes of yesterday's virtual interim meeting.
Please let me know if something needs fixing by the beginning of next
week so that I can send the final version to the secretariat.

You can also find all the virtual interim meeting minutes next to the
YANG 1.1 issue list in the NETMOD WG subversion repository:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/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: Mahesh Jethanandani <[email-masked]>
Date: Fri, 3 Oct 2014 10:20:46 -0700

Juergen,

Are we voting on Y25 options that you state in the meeting minutes?

The options are:
      (1) No change
      (2) Remove auto numbering
      (3) Add statement to make auto numbering optional (on/off)

I am voting 1, 3, 2.

On Oct 2, 2014, at 5:08 AM, Juergen Schoenwaelder wrote:

> <netmod-2014-10-01-minutes.txt>_______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Oct 2014 22:32:13 +0200

Mahesh,

we are not voting in the IETF. I did a poll of opinions in order to
see where we are (were you already gone at that time?). A poll of
opinion is a way to determine where we are in the process of finding
censensus, see RFC 7282 for a great reading about IETF consensus
finding.

Since we have rather different opinions here, can you explain why you
want no change? Note that RFC 6020 says: "The value is unused by YANG
and the NETCONF messages, but is carried as a convenience to
implementors." It seems necessary to gain an understanding how
implementations are affected by (2) or (3) (and I assume people
favoring (1) likely do this because (2) or (3) affect their
implementation).

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 4 Oct 2014 18:15:39 -0700

Juergen,

You mentioned in the minutes that you were planning to take the discussion to the list. Sorry, I was not there for the poll, as I had to hang up to head to work.

>     This needs to be taken to the list. (The result may mean that
>     there is a majority for making a change here and out of the two
>     options to make a change, it seems there is a majority to remove
>     the auto numbering - which is after all a convenience to
>     implementors.)

See comments inline.

On Oct 4, 2014, at 1:32 PM, Juergen Schoenwaelder wrote:

> implementors."

True. The values are carried as a convenience and as such are just that.

> It seems necessary to gain an understanding how

My rational for opting for (1) is mainly because how I am used to enums, i.e. that they are auto numbered and I do no have to add a value statement. Call me lazy, but I like that feature. So even though they are carried as a convenience, they are there if anyone wants to use them. (I guess that means implementations can choose to ignore the value that is carried and assign their own??) So unless not auto numbering them buys us a big advantage, I am inclined to leave them as is.

HTH.

mj

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Oct 2014 08:29:26 +0200

On Sat, Oct 04, 2014 at 06:15:39PM -0700, Mahesh Jethanandani wrote:
> 
> My rational for opting for (1) is mainly because how I am used to
> enums, i.e. that they are auto numbered and I do no have to add a
> value statement. Call me lazy, but I like that feature. So even
> though they are carried as a convenience, they are there if anyone
> wants to use them. (I guess that means implementations can choose to
> ignore the value that is carried and assign their own??) So unless
> not auto numbering them buys us a big advantage, I am inclined to
> leave them as is.

The autonumbering 'feature' causes side effects: The order of
definition of enums can't be modified anymore (unless explicit values
are assigned) and additional enums can only be made at the end. If you
want to maintain enums for things that do not have a natural number
associated to then (e.g., timezones or country codes), then
autonumbering makes this difficult.

Note that this is different from enums in programming languages where
the autonumbering is local to a compiler run. If you add something in
the middle, you will recompile and everything gets renumbered and you
are fine. (Note that tools can still autonumber (e.g., create
C/C++/Java enums) when they generate code as long as the code is
compiled into something that is internally version consistent.)

The core of the issue is that auto-numbering makes it difficult for
data modelers to maintain certain enums while the benefit is only a
'convenience to implementors'. In the early YANG days, the priority
was always YANG 'reader', then YANG 'writer' and finally YANG
'implementors'. The enum/bits auto-numbering puts 'implementors'
higher than 'writers'.

/js