Subject: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 13:11:27 +0200

Hi,

we managed to go over all issues except those issues that we will be
disussing during the face-to-face interim meeting. This email provides
a summary of where we are with the issues not marked DEAD.  I am also
including actions that need to be carried out.

If you disagree with any of the following proposed resolutions, please
speak up as soon as possible but no later than September 16 (so that
we have the input before the face-to-face interim meeting starts). If
you want to raise a concern, please start a threat with the issue
identifier in the subject line.

* OPEN :Y01: allow boolean if-feature

  2014-06-11 meeting proposal: adopt Y01-01.

* OPEN :Y02: allow must in input, output, and notification

  2014-06-11 meeting proposal: adopt Y02-01.

* OPEN :Y03: allow if-feature in refine

  2014-06-11 meeting proposal: adopt Y03-01.

* OPEN :Y04: accessible tree in xpath in notifs and rpc

  2014-06-11 meeting proposal: adopt Y04-02.

* OPEN :Y05: unprefixed path in top-level typedef

  2014-06-11 meeting action: MB to write down solution Y05-03 and once
  done we get back to this issue.

* OPEN :Y06: escaped characters in double quoted strings

  2014-06-11 meeting proposal: adopt Y06-02.

* OPEN :Y07: do not allow when or if-feature on keys

  2014-07-02 meeting proposal: adopt Y07-01 with a clarification about
  the condition

* OPEN :Y09: introduce optional keys <<Y09>>

  2014-07-02 meeting action: MB to write up a solution proposal	and
  once done we get back to this issue.

* OPEN :Y10: allow restrictions on enumerations

  2014-07-02 meeting action: LL to write down another syntax proposal
  and MB to expand Y10-01.

* OPEN :Y11: allow if-feature on enums

  2014-07-02 meeting proposal: Adopt Y11-01 with the extension to
  allow if-feature also for bits and identities.

* OPEN :Y12: initialized-by system

  2014-07-02 meeting proposal: Adopt Y12-01 but think about a better
  syntax. Applies to leaf and leaf-lists. MB to create concrete text.

* OPEN :Y13: allow multiple inheritance for identities

  2014-07-02 meeting action: LL to write a more complete example and
  once done we get back to this issue.

* OPEN :Y14: clarify the string value for identities when used in must/when

  2014-07-02 meeting proposal: adopt Y14-01.

* OPEN :Y16: module advertisement optimization

  2014-07-02 meeting action: MB to look at the details whether Y16-02
  can be made to work.

* OPEN :Y18: fix "when" expression context node problem

  2014-07-02 meeting action: LL to write up an example in which
  situations Y18-01 is problematic.

* OPEN :Y20: new set of built-in XPath functions

  2014-07-09 meeting proposal: MB to copy the functions he proposed to
  RFC 6020bis as a starting point and then we review and discuss
  changes.

* OPEN :Y23: support negative patterns as string restrictions

  2014-07-09 meeting proposal: adopt Y23-02.

* OPEN :Y25: make enum numbering purely informative and optional

  2014-07-09 meeting proposal: adopt Y25-01.

* OPEN :Y26: allow mandatory nodes in augment

  2014-07-09 meeting action: There is agreement that the current text
  is overly restrictive. The proposal is to add general guiding rules
  that backwards compatibility needs to be maintained. Lets see
  whether someone can write more concrete rules when mandatory nodes
  in augment are allowed.

* OPEN :Y27: allow mandatory nodes in an updated module

  2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to
  check what the feature issue is about, possible action to add
  guidelines how to go from current to deprecated to obsolete in RFC
  6087bis.

* OPEN :Y28: support default values in leaf-lists

  2014-07-09 meeting action: AB will look at the necessary text and
  what it means to modify leaf-list values. Perhaps there is a need to
  have a different keyword since the behavior is rather different
  here.

* OPEN :Y29: allow choice as a short-hand case

  2014-07-09 meeting proposal: adopt Y29-01

* OPEN :Y30: allow leafref in union

  2014-07-21 meeting proposal: adopt Y30-01, clarify existence
  constraints and impact on union member selection, see 2014-07-09
  meeting minutes. Followup on Lada's issue concerning unions as keys.

* OPEN :Y31: allow require-instance in leafref

  2014-07-21 meeting proposal: adopt Y31-01.

* OPEN :Y34: remove/deprecate/replace the 'anyxml' statement

  2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out
  a concrete proposal.

* OPEN :Y35: allow empty in union

  2014-07-21 meeting proposal: adopt Y35-01.

* OPEN :Y41: clarification of "must" in NP-container

  2014-07-21 meeting proposal: Clarify that for validation purposes,
  NP containers always exist.

* OPEN :Y42: a better model for configuration versus state data is needed

  postponed to the face-to-face interim meeting

* OPEN :Y44: add a mechanism to parameterize error-message

  2014-08-27 meeting proposal: close Y44 by moving it to DEAD.

* OPEN :Y45: better conformance mechanism

  postponed to the face-to-face interim meeting

* OPEN :Y47: bit name too restrictive

  2014-08-27 meeting proposal: close Y44 by moving it to DEAD.

* OPEN :Y49: clarify nested submodule behavior

  2014-08-27 meeting action: MB to writeup solution proposal Y49-03.

* OPEN :Y54: remove the advertisement of conformance information in NETCONF hello

  postponed to the face-to-face interim meeting

* NEW :Y55: clarify type in union

  2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01.

/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: Benoit Claise <[email-masked]>
Date: Thu, 04 Sep 2014 09:50:19 +0200

Jürgen, WG,

I like the way the interim meetings are run. This brings speed to the 
process. Thanks.

However, let me repeat a statement I made a few times.
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (or 
whatever support), must also document the rational for selecting a 
specific solution.
Something like:
     solution 1 was rejected because of reason 1, 2, and 3
     the issue <bla> could be addressed with both solutions 1 and 2
     current implementations don't use the feature this way
     solution 2 is easier from an implementation point of view because ...
     in conclusion, solution 2 is plebiscited by the WG

What's the reasoning ?
We don't want to redo the discussions over and over.
Following RFC 7282, how can we say to a new participant in the WG: "We 
hear you. This argument was discussed, and the consensus was ... Do you 
have another argument in favor of a different solution? Basically, have 
we overlooked anything?"
Without some documentation, this is not possible.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Sep 2014 10:02:25 +0200

Benoit,

I believe sufficient details are recorded in the minutes. Please take
a look at the minutes and let me know if I am wrong.

I am already spending _significant_ amount of time on issue tracking,
taking notes, editing of minutes, seeking confirmation for every step
on the mailing list, handling the other process requirements (meeting
allocations, minute submission to the secretariat, etc) and I am
reaching a limit. If even more documentation is required, I can't do
it anymore alone.

/js

On Thu, Sep 04, 2014 at 09:50:19AM +0200, Benoit Claise wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: David Bannister <[email-masked]>
Date: Thu, 4 Sep 2014 05:36:32 -0400

Juergen,
	I may be able to help if you would like to discuss off list.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Sep 2014 18:12:39 +0200

Hi,

>   once done we get back to this issue.

I addressed this open action and updated the issue description:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-13

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Sep 2014 23:20:34 +0200

> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-13

Thanks.

What are the update rules for this? Can I add/remove base statements?
What does it mean to have a default value CC-BY-SA (which has two
bases) for a leaf whos type has been restricted to a single base? I
find the example not very intuitive - CC-BY-SA means AND (both
conditions need to be satisfied) and not OR. Are the proposed
semantics that N bases are forming an AND or an OR?

/js

PS: Perhaps the example should have been added to solution Y13-01
    instead of the description of the issue. As it is, it looks like
    the description already limits things to a particular solution. It
    would make more sense if the description would explain (a) what
    the problem is we are solving and (b) why this is useful to have
    in 1.1.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Sep 2014 11:55:20 +0200

> What are the update rules for this? Can I add/remove base statements?

This has to be discussed, my take is that they could be
- added but not removed in identity definition,
- removed in identityref, unless it is the last base statement, but not added.

> bases) for a leaf whos type has been restricted to a single base? I

Its value can be any identity whose base (or one of the bases) is
"share-alike", or any identity derived from it. In the example, the
other value "CC-BY-NC-SA" is also acceptable.   

> semantics that N bases are forming an AND or an OR?

AND.

>     the problem is we are solving and (b) why this is useful to have

Done, I also expanded the solution text to answer your questions
above.

Thanks, Lada

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Sep 2014 11:52:54 +0200

Hi Jürgen,
> reaching a limit. If even more documentation is required, I can't do
You work is very much appreciated. Believe me. And I can see how much 
time you dedicate to NETMOD. Thanks.

However, it's not because you are the chair that you have to do 
everything yourself.
What I had in mind is some sort of collaborative effort.
For example, different people inserted their issue at 
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html. Those 
people could be responsible to update and document their respective issuess.
For example, during the webex calls, writing meeting minutes with a tool 
such as etherpad, so that everybody could collaborate on writing those 
minutes.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Sep 2014 12:06:48 +0200 (CEST)

> people could be responsible to update and document their respective

I feel kind of responsible for this list, and my plan has been to
update the issues with the resolution and relevant discussion.  This
is still my plan ;)   I view this as part of the editorial task of
making sure we cover everything in the document itself.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Sep 2014 12:31:26 +0200

Thank you Martin.

Regards, Benoit
> .

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Sep 2014 14:14:24 +0200 (CEST)

Hi,

> identifier in the subject line.

I couldn't find any reasoning behind the proposal to adopt Y23-02 in
the minutes.

I prefer the syntax in Y23-01:

       exclude-pattern '[xX][mM][lL].*';

The current "pattern" statement is defined as:

   It is used to restrict the built-in type "string", or types derived
   from "string", to values that match the pattern.

With Y23-01, this doesn't change.

However, with the syntax proposed in Y23-02:

        pattern '[xX][mM][lL].*' {
          filter exclude;
        }

the meaning of 'pattern' changes depending on the value of the
substatement "filter".

Also I think the word "filter" is not very descriptive.  Filtering
sounds like a process, but the type restriction statement defines the
value space of the type.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Sep 2014 14:26:30 +0200 (CEST)

Hi,

>   2014-07-09 meeting proposal: adopt Y25-01.

I strongly object to this proposal.  This proposal doesn't fix a bug,
but it removes an explicit feature of YANG 1.0.  It is clear from RFC
6020 that the value isn't used in NETCONF, but it clearly states that
the value is "carried as a convenience to implementors".  If this is
removed, current implementations that rely on this value no longer
work.  (Making it optional is also weird - as a data model designer,
when should I use the value statement and what does it mean?)

Also, if we do this, we should do the same for "position" in a "bits"
type.  The position is also not used by NETCONF, but carried as a
convenience to implementors.

(Note that the original issue that opened this discussion resulted in
errata 3871, which is applied in draft-ietf-netmod-rfc6020bis-00)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 14:48:32 +0200

> sounds like a process, but the type restriction statement defines the

I agree and also prefer Y23-01.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 15:30:05 +0200

> I strongly object to this proposal.  This proposal doesn't fix a bug,

I does fix a bug, which is mentioned in the description: an
auto-numbered enumeration is difficult to update, e.g. by adding an enum
somewhere in the middle, or changing the order of enums.

> when should I use the value statement and what does it mean?)

I am wondering what this "convenience" really is. An implementation may
just use enum names and no numbers, and if it uses a mapping of enum
names to numbers, than this mapping is totally local, and another
implementation may use a different mapping with no impact on
interoperability whatsoever. 

It just needs some elementary care whenever an implementation is being
upgraded to a new version of an enumeration.

It clearly makes YANG easier to use for readers and writers, and means
tiny complications for implementors - and I think this is the correct order
of priorities that we agreed upon.

Your last question (when to use values if they are optional) is answered
in solution Y25-01.

> convenience to implementors.

Yes.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 15:56:59 +0200

>   2014-07-02 meeting action: LL to write down another syntax proposal

I don't remember exactly what idea I had regarding syntax but I think it had to
do with:
- the ability to specify ranges
- the possibility of excluding specified enums

So maybe instead of the "subset" statement as proposed in Y10-02, we
could allow a sequence of "include" and "exclude" statements. For example:

include "Mercury .. Mars, Uranus .. Pluto";

or, equivalently,

exclude "Jupiter, Saturn";

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 16:20:03 +0200

>   situations Y18-01 is problematic.

I added this example already on July 3 (SVN revision 48).

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Sep 2014 16:38:29 +0200 (CEST)

> somewhere in the middle, or changing the order of enums.

I don't agree that this is a bug.  Maybe it is difficult in some cases
(but not in the normal case imo), but not a bug.  This feature works
as initially intended when we did YANG 1.0.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 16:54:23 +0200

> as initially intended when we did YANG 1.0.

IMO, an unnecessary CLR that makes life harder is a bug.

Take the database of country codes (ISO 3166) as an example. It is alphabetically sorted, so you don’t want to be limited just to appending new codes at the end. And adding bogus numeric values to all enums is a sheer nuisance that would make the module twice as long.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2014 08:26:19 -0700

> as initially intended when we did YANG 1.0.

+1

The normal usage mode is manual editing of the YANG file, not auto-generated
from another data structure by some tool.

The sec. 10 update rules are designed to protect old clients from disruptive
changes in the API contract.  A new revision of the contract cannot void
provisions in previous revisions.   Call them all CLRs if you want, but they
are based on decades of experience breaking old clients, so ignore this
section with caution. ;-)

It seems clear to me that removing the auto-numbering would be taking
away a YANG 1.0 feature, even though it is not used in the protocol.
If vendors are complaining that they are using this feature, then that
seems more important than removing a CLR to support auto-generated
enums and bits.

> /martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 18:33:35 +0200

> from another data structure by some tool.

I don’t understand. These enumeration rules are more of a problem for manual editing - think about a maintainer of the country code enumeration.

If I remember correctly, this discussion started in connection to the timezone database, and Martin's proposed solution was to write an auto-numbering script.

> section with caution. ;-)

This has nothing to do with the data model contract because the numbers are never exchanged between the server and client. 

> seems more important than removing a CLR to support auto-generated

Who are these vendors and why do they need this CLR?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2014 09:58:55 -0700

On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka <[email-masked]> wrote:

> I don't understand. These enumeration rules are more of a problem for
> manual editing - think about a maintainer of the country code enumeration.
>
>
This is a rare exception, not even close to a normal use of enumerations.
For 98% of the cases, there is a small list of manually maintained values
and
adding a new value so it does not renumber other values is not hard at all.

> If I remember correctly, this discussion started in connection to the
> timezone database, and Martin's proposed solution was to write an
> auto-numbering script.
>
>
A script could generate values instead of auto-numbering them.
It could check for the highest used value to create a new enum
with  a previously unused value. Acript should not use auto-numbering.

> This has nothing to do with the data model contract because the numbers
> are never exchanged between the server and client.
>
>
I think it does because this information is available for implementations
to use,
and the rules for changing these values is very clear.  They can currently
be utilized as static codepoints within implementations, even if
auto-numbering
is used.

> Who are these vendors and why do they need this CLR?

Maybe Martin can say which tail-f customers use this confd feature.

Somebody just asked me yesterday why there is no AGENTX for NETCONF.
When will NETCONF have standardized sub-agents?  Maybe this will not
remain an implementation detail forever. Maybe RESTCONF for CoAP
will use "YANG OIDs" and other numbers-replacing-strings.

When it comes to JSON, you seem to think YANG needs to be defined
independently of a protocol,
but when it comes to this feature, YANG is not supposed to be
protocol-independent.
The stable auto-numbering is a YANG feature, not a protocol feature.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 19:24:22 +0200

On 11 Sep 2014, at 18:58, Andy Bierman <[email-masked]> wrote:

> For 98% of the cases, there is a small list of manually maintained values and

In this case, what prevents you from keeping a consistent private numbering even if the CLR doesn’t exist in YANG? The point is that it doesn’t matter if another implementation uses a different numbering scheme. It is also trivial to handle new enums that are added in the middle - you just assign next available number so that old numbers are intact.

Lada

> I think it does because this information is available for implementations to use,
> be utilized as static codepoints within implementations, even if auto-numbering
> is used.
> 
> 
> >
> When it comes to JSON, you seem to think YANG needs to be defined independently of a protocol,
> but when it comes to this feature, YANG is not supposed to be protocol-independent.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2014 10:58:26 -0700

On Thu, Sep 11, 2014 at 10:24 AM, Ladislav Lhotka <[email-masked]> wrote:

> In this case, what prevents you from keeping a consistent private
> numbering even if the CLR doesn't exist in YANG? The point is that it
> doesn't matter if another implementation uses a different numbering scheme.
> It is also trivial to handle new enums that are added in the middle - you
> just assign next available number so that old numbers are intact.
>
>
That's fair question. The answer may not be what we want to hear, but what
is the point of
making "value" and "position" first-class YANG statements when we treat
them like
vendor extensions?  They are in the language to "help" implementations in
unspecified ways?
Perhaps they were misguided from the start.  They certainly confuse people
who know SNMP
and assume it works the same way (or else why bother showing me this info
in the public contract?)

What if there was a different CLR that said a tool MUST convert YANG 1.0
module
auto-numbering to explicit numbering when parsed by a YANG 1.1 tool?
In other words a YANG 1.0 module is assigned value or position numbers
based on the current
rules, but if "yang-version 1.1" is in the module, then YANG 1.1
implementations are free to
assign any number they want (including none).

I don't know how to express this in RFC text yet, but I think it preserves
YANG 1.0
behavior for YANG 1.0 modules, and only removes stable auto-numbering across
all implementations from YANG 1.1.  New modules must use explicit numbering
or the vendor can add a YANG extension to assign values that are not
numbered.

Lada
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Sep 2014 20:29:22 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> Perhaps they were misguided from the start.

Perhaps.  But I still don't think we should remove features from YANG
1.0 that works they way they were designed to work.

Also, as you said, maybe some other protocol mapping use them.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Sep 2014 20:44:55 +0200 (CEST)

> Maybe Martin can say which tail-f customers use this confd feature.

In a sense all of them.  Could it be done differently?  Sure, but
since this fetaure is there we use it.  (we had a different solution
before yang, but the current one is better).

Having both a numeric value and a symbolic identifier for an enum is
not really a new idea...   It is not a co-incident that the enum
values work like in C (almost ;).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 20:51:57 +0200

> 1.0 that works they way they were designed to work.

Along the same lines you could reject Y09 because it removes a feature that works the way it was designed, namely mandatory presence of all keys.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Sep 2014 21:21:59 +0200

> before yang, but the current one is better).

Not being a confd user I have no idea what features and solutions you are talking about. Do you generate C header files from enumerations?

I think it is hard to deny that removing the CLR would streamline and improve the spec, and make enumerations more usable. I am not personally convinced about the “convenience to implementors” but in any case it is not supposed to be the highest priority.

> values work like in C (almost ;).

YANG is not a programming language.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2014 12:49:00 -0700

On Thu, Sep 11, 2014 at 12:21 PM, Ladislav Lhotka <[email-masked]> wrote:

> Not being a confd user I have no idea what features and solutions you are
> talking about. Do you generate C header files from enumerations?
>
> I think it is hard to deny that removing the CLR would streamline and
> improve the spec, and make enumerations more usable. I am not personally
> convinced about the "convenience to implementors" but in any case it is not
> supposed to be the highest priority.
>

The intent of the value/position statements is to convey data model
codepoints
if they exist (e.g., match a protocol spec).  It is not clear what the
intent of
auto-numbering was at the time.   We can't seem to agree on that so we
cannot agree it is a feature worth keeping in YANG 1.1.

If the data modeler does not intend to give value or position any meaning,
then how do they do that with auto-numbering?  That is the problem I
have with keeping it in YANG 1.1. (You can't turn it off.)

It is impossible to tell (outside the server internals) what values are
assigned by the server during auto-numbering so how will we ever
test conformance for auto-numbering?

That's why I think "implementation-specific numbering" is OK in YANG 1.1.

> YANG is not a programming language.

Yes it is -- that's what's new and better about about it ;-)
Automation is about consistency and work reduction.
The model drives various tasks that are traditionally written by hand.

Andy

---

From: David Reid <[email-masked]>
Date: Thu, 11 Sep 2014 16:40:58 -0400

> Also, as you said, maybe some other protocol mapping use them.

We use SNMP to get some yang defined data. In the case of enumerations,
we use the automatically assigned value.

-David Reid

---

From: [email-masked]
Date: Mon, 15 Sep 2014 09:02:35 +0800

I think 'pattern' just define a regular expression. 'pattern' itself 
should 
has no any meaning of filter type. Like pipeline in unix, unix use | 
{include | exclude | begin} <pattern> to 
implement pipeline filter. 

Actually, I think we should add 'include','exclude' and 'begin' keywords 
to express it. 

But for backwards compatibility , I add filter as substatement of pattern 
to express filter type.

"netmod" <[email-masked]> 写于 2014-09-11 20:14:24:

> Martin Bjorklund <[email-masked]> 
> 发件人:  "netmod" <[email-masked]>
> 
> 2014-09-11 20:14
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> [email-masked]
> 
> 主题
> 
> [netmod] Y23 - support negative patterns as string restrictions
> 
> Hi,
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 12 Sep 2014 10:03:53 +0200

Hello,
Many of our enumerations have less than 10 enums. For such cases a 
complete lists of all new values might be the most readable solution. It 
avoids the need to always look up the original enum.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Sep 2014 10:56:56 +0200

> the meaning of 'pattern' changes depending on the value of the

But without a filter substatement, the semantics are the same as in
YANG 1.0. Note that if we set the bar very high here, then other
issues can likely be closed quickly as well. ;-)
 
> sounds like a process, but the type restriction statement defines the

Yes, "filter" may not be the best word. One advantage of using
substatements is that doing so allows to add more modifiers easily
(should the WG decide this is useful). For example, another popular
modifier is to ignore case. With 'modifiers', we could easily have

  pattern 'xml.*' {
      modifier exclude;
      modifier ignore-case;
  }

while the approach of introducing separate statements would lead to a
total of 4 statements (pattern, exclude-pattern, ignore-case-pattern,
ignore-case-exclude-pattern).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 12 Sep 2014 11:12:02 +0200 (CEST)

> modifier is to ignore case. With 'modifiers', we could easily have

I like the name 'modifier'!

Should it be:

  modifier exclude;

or

  modifier negate;

?

/martin

---

From: Per Hedeland <[email-masked]>
Date: Fri, 12 Sep 2014 11:29:45 +0200

> I like the name 'modifier'!

+1! FWIW, matches perl terminology.

or

    modifier invert[-match];

- as in grep(3)...? No, I think I prefer 'negate' if we're having a
vote.:-)

--Per

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Sep 2014 19:56:16 +0200

> have with keeping it in YANG 1.1. (You can't turn it off.)

I think this is an important observation. There are cases where auto
numbering gets into the way (and we understand this all too well since
the timezone experience). If there would be a way to turn this
auto numbering off, we could perhaps all be happy.

And even then, I personally would still recommend to assign explicit
values where values are meaningful, just to be sure that updates do
not cause bad side effects. For me, auto numbering sounded like a good
idea back in a day but it is actually brittle wrt. module updates. For
small enums, it is not much effort to assign explicit values. Large
enums usually tend to be updated more frequently and this is where
auto numbering becomes handy and problematic at the same time.

/js (speaking as technical contributor)

PS: Sure, if someone maps a subset of YANG to SNMP, then clearly a
    predictable numeric value is needed. The question is whether YANG
    is required to supply it.

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 14 Sep 2014 09:52:11 +0200

> auto numbering off, we could perhaps all be happy.

So could this way be a new modifier of the enumeration type? For example,

auto-numbering true/false;

If the default value is true, then the semantics of YANG 1.0 enumerations is preserved, and new enumerations can use whatever is appropriate.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Sep 2014 10:16:14 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 
> On 12 Sep 2014, at 19:56, Juergen Schoenwaelder
> <[email-masked]> wrote:
> 

The problem with this is that the code needs to be written to support
both cases.  I prefer a solution where we know that all enums
have values and all bits have positions - i.e., like today in YANG
1.0.  If the WG decides that this is problematic, I think it is better
to remove the values and positions than trying to compromise and have
both.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Sep 2014 10:44:11 +0200

> both cases.  I prefer a solution where we know that all enums

Right, but we are in fact dealing with two different types. The numbering procedure is only a technicality, the substance is that you have either an extensible (unordered) set of enums or append-only list. There seem to be use cases for both. 

I don’t think it actually makes much of a difference for code, it’s more about restrictions for module updates.

> to remove the values and positions than trying to compromise and have

I’d be fine with this, too, but the charter rules for YANG 1.1 prevent us from removing the “value” and “position” statements.

Lada