Subject: Re: [netmod] Y25 new solution Y25-02

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 22:53:02 +0100

Hi,

I see that the original text for Y25-02 can be mis-interpreted. Based
on your input, I have updated Y25-02 to read as follows:

  Keep the auto-numbering procedure for enums and bits and add an
  explicit warning that inserting enum or bits definitions or
  reordering enum or bits definitions violates section 10 and causes
  interoperability problems unless explicit value assignments are
  used.

  The guidelines document may add further rules such that enum/bits
  values must be explicitly defined in IETF modules (to be discussed
  in the context of the guidelines document).

  Remove the following sentence:

    The value is unused by YANG and the XML encoding, but is carried
    as a convenience to implementors.

It seems this resolves this issue. Since there are edit to be done, I
will start a VRFY to move this into the EDIT state.

/js

On Sat, Feb 14, 2015 at 12:57:30PM +0100, Per Hedeland wrote:
> On 2015-02-14 10:07, Juergen Schoenwaelder wrote:
> > On Fri, Feb 13, 2015 at 01:41:06PM -0800, Andy Bierman wrote:
> >> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder
> >> <[email-masked]> wrote:
> >>> Hi,
> >>>
> >>> Y25 (make enum numbering purely informative and optional) has been
> >>> discussed but no clear concensus has been reached so far. Y25-01
> >>> proposes to remove the auto-numbering mechanism. With the appearance
> >>> of a CBOR encoding proposal [1], the numeric values may actually be
> >>> used on the wire. An alternative is to keep the auto-numbering
> >>> mechanism but to clarify the risks, this is what I have written up as
> >>> solution Y25-02:
> >>>
> >>> ** Solution Y25-02
> >>>
> >>>   Keep the auto-numbering procedure for enums and bits and add an
> >>>   explicit warning that inserting enum definitions or reordering of
> >>>   enum definitions very likely causes interoperability problem and
> >>>   that explicit value assignments avoid this problem.
> >>
> >> This is not really keeping the current procedure.
> >> Currently, the auto-numbering is mandatory, and sec 10.
> >> clearly prohibits changing any value or position statement.
> >>
> >> IMO Y25 should be declared DEAD and the YANG 1.0 behavior
> >> not changed at all.
> >>
> >> You are proposing that Sec. 10 be changed so renumbering is
> >> a warning, not a violation of the standard.
> >>
> > 
> > Have you read the text? I fail to see how the text implies that
> > existing behaviour changes. It is about adding an explicit warning.
> > Please explain.
> 
> Since I came to the exact same conclusion as Andy (after reading the
> text, but before reading Andy's message), I'll explain why I did that.
> 
> 1. The proposal doesn't actually solve any of the alleged problems in
> Y25 unless the rule in section 10 is removed.
> 
> 2. The proposal explicitly mentions keeping the auto-numbering scheme,
> but has no mention of the rule in section 10.
> 
> 3. Adding a vague warning against something that is explicitly forbidden
> by another part of the spec doesn't make any sense IMHO, and is likely
> to result in confusion and risk for the rule to be overlooked.
> 
> Thus for me, the only reasonable conclusion was that you were
> (implicitly) proposing that the rule in section 10 should be removed.
> If this is not the case, i.e. you are proposing that both the
> auto-numbering and the section 10 rule should be retained, but that
> warning(s) should be added, I would suggest this text:
> 
>     Keep the auto-numbering procedures and the restrictions in section 10
>     for enum values and bit positions, but add
> 
> - followed by one or both of:
> 
> a)  a warning that inserting or reordering enum or bit definitions will
>     cause a violation of the rules in section 10, unless explicit
>     value/position assignments are used
> 
> b)  a motivation (in section 10) of the rules in section 10, saying that
>     changes to the values/positions may cause interoperability problems
>     (perhaps also: and lose or at least significantly reduce the
>     "convenience to implementors", since the values cannot be assumed to
>     be stable)
> 
> Item a) would be quite useful IMO - actually I believe that this came as
> a surprise to some of the participants in the "time zone discussion",
> and the fact that it did so was a major cause of the perception of
> "difficulty".
> 
> There's nothing wrong with b), but none of the other "itemized" rules
> have any motivating text. This sounds like a separate issue, "Add
> motivation to all the rules in section 10" (I don't personally think it
> is important to do so though).
> 
> --Per
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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