Subject: [netmod] [Technical Errata Reported] RFC6110 (3362)

From: RFC Errata System <[email-masked]>
Date: Fri, 21 Sep 2012 08:48:50 -0700 (PDT)

The following errata report has been submitted for RFC6110,
"Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362

--------------------------------------
Type: Technical
Reported by: Jernej Tuljak <[email-masked]>

Section: 10.55.

Original Text
-------------
The 'unique' Statement

   This statement is mapped to the @nma:unique attribute.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @nma:unique attribute.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following attribute/value pair:

   nma:unique="ex:foo ex:bar/ex:baz"

Corrected Text
--------------
The 'unique' Statement

   This statement is mapped to the <nma:unique> element. It has one
   mandatory attribute @key (with no namespace). ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @key attribute.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following element:

   <nma:unique key="ex:foo ex:bar/ex:baz" />

Notes
-----
A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6110 (draft-ietf-netmod-dsdl-map-10)
--------------------------------------
Title               : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content
Publication Date    : February 2011
Author(s)           : L. Lhotka, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 24 Sep 2012 08:21:09 +0200

Hi,

actually the notes section of my errata contains a typo. Cardinality of 
unique-stmt is 0..n (not 0..1). That should be corrected.

Jernej

Dne 21.9.2012 18:04, piše Ladislav Lhotka:
> Hi,
>
> this erratum should be verified, the reporter is absolutely right.
>
> Ladislav Lhotka, editor of RFC 6110
>
> On Sep 21, 2012, at 5:48 PM, RFC Errata System<[email-masked]>  wrote:
>
>> Reported by: Jernej Tuljak<[email-masked]>
>>
>> Section: 10.55.
>>
>> Original Text
>> -------------
>> The 'unique' Statement
>>
>>    This statement is mapped to the<nma:unique>  element. It has one
> --
> Ladislav Lhotka
> PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Sep 2012 18:04:09 +0200

Hi,

 

--
Ladislav Lhotka
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2012 10:34:34 +0200 (CEST)

> this erratum should be verified, the reporter is absolutely right.

If I am not mistaken, this errata changes the encoding of "unique"
from an XML attribute to an XML element.  Can we really make such
changes in an errata?

/martin

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 10:35:32 +0200

On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote:

[...]
 
> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional c…

Would it make sense to identify the other changes that may be
required? I quick search leads to:

- Table 2
- 2nd paragraph of section 11.2
- section 12.16 (including its title)
- definition of unique-attribute in appendix A

Anything else I am missing?

/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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 10:45:50 +0200

> from an XML attribute to an XML element.  Can we really make such

Good question. The bug, however, seems to be clear. I think it is
important to figure out what kind of solution those implementing/using
this specification really want. Some backwards compatible options:

- You can create a kludge where the case with only one unique
  statement is handled as currently documented and additional unique
  statements are dealt with differently.

- You can create an update that says unique statement are handled with
  XML elements but in the special case of only one unique statement,
  the attribute is present in addition to the XML elements,
  essentially introducing the xml element solution and deprecating the
  use of an attribute.

Perhaps there are other options. Lets figure out which solution is
preferred and then we can see how to properly document that.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Sep 2012 10:49:43 +0200

> - definition of unique-attribute in appendix A

Yes, this list (+ section 10.55) is all that needs to be changed.

Lada

--
Ladislav Lhotka
PGP Key ID: E74E8C0C

---

From: Benoit Claise <[email-masked]>
Date: Mon, 24 Sep 2012 11:07:22 +0200

Hi,

How do we want to treat this?
Updating the errata 3362, or a new one?

Regards, Benoit.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Sep 2012 11:17:24 +0200

> preferred and then we can see how to properly document that.

Practically speaking, it would be IMO wiser *not* to implement any backward compatibility kludge. The two existing implementations (MG-SOFT and pyang) can be updated in a straightforward way, and for any future implementors it would be easier to deal only with the <nma:unique> elements.

I do admit it is a somewhat slippery slope but I also believe the risk of interoperability problems is minimal.

Lada

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

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 24 Sep 2012 12:56:10 +0200

Dne 24.9.2012 11:17, piše Ladislav Lhotka:
> On Sep 24, 2012, at 10:45 AM, Juergen Schoenwaelder<[email-masked]>  wrote:
>
>>> Ladislav Lhotka<[email-masked]>  wrote:
>>>> Hi,
>>>>
> Practically speaking, it would be IMO wiser *not* to implement any backward compatibility kludge. The two existing implementations (MG-SOFT and pyang) can be updated in a straightforward way, and for any future implementors it would be easier to deal only with the<nma:unique>  elements.

I agree. I think it is in the interest of both, existing and future 
implementations, to keep stuff simple. If pyang and our implementation 
are really the only existing ones, then it doesn't make sense to put 
backward compatibility in there.

Jernej

>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Sep 2012 12:22:30 +0200

Hi,

this bug is now fixed in pyang. I only used a different name ("tag") for the attribute of the <nma:unique> element, in order to follow the YIN convention. So the annotation looks e.g. like this:

  <nma:unique tag="t:a/t:b t:c"/>

Please try it out.

Thanks, Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 26 Sep 2012 09:51:40 +0200

Dne 25.9.2012 12:22, piše Ladislav Lhotka:
> Hi,
>
> this bug is now fixed in pyang. I only used a different name ("tag") for the attribute of the<nma:unique>  element, in order to follow the YIN convention. So the annotation looks e.g. like this:
>

Didn't test the transformation, but since changes to it are semantically 
equivalent to what I did to fix this and it works for us, I can assume 
it works for you. Our hybrid schema were exactly the same, except for 
attribute naming.

Jernej

> Thanks, Lada
>
> RFC Errata System<[email-masked]>  writes:
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2012 10:07:09 +0200

On Sep 26, 2012, at 9:51 AM, Jernej Tuljak <[email-masked]> wrote:

> Didn't test the transformation, but since changes to it are semantically equivalent to what I did to fix this and it works for us, I can assume it works for you. Our hybrid schema were exactly the same, except for attribute naming.

OK, thanks. Will you change the attribute name, so that we don't differ on this?

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 26 Sep 2012 10:12:20 +0200

> Updating the errata 3362, or a new one?

We should probably determine what the text of the errata should be. The 
one I reported is now outdated, so unless it can be updated, a new one 
should be created.

As far as I can see the changes to Table 2, 12.16. title (plus TOC 
entry) and 11.2. are of an editorial nature only ("@nma:unique" --> 
"<nma:unique>").

I've already posted what I think the content of 10.55. should be and I 
don't mind the attribute being renamed to "@tag" (the way Ladislav 
suggested). Honestly, I put the first word that popped into my mind when 
I created the report. We could also forget about using an attribute and 
just put the unique-stmt's argument into the text value of the 
<nma:unique> element but I would prefer to have it as an attribute (also 
seems like a less invasive change).

The "unique-attribute" definition in Appendix A should be changed from

   <define name="unique-attribute">
     <optional>
       <attribute name="nma:unique">
         <list>
           <data type="token"/>
         </list>
       </attribute>
     </optional>
   </define>

to

   <define name="unique-element">
     <zeroOrMore>
       <element name="nma:unique">
         <attribute name="tag">
           <list>
             <data type="token"/>
           </list>
         </attribute>
       </element>
     </zeroOrMore>
   </define>

(I think).

The content of 12.16. also needs modification so it reflects the change 
made in 10.55.

    The mapping of this annotation is almost identical as for @nma:key,
    see Section 12.8, with two small differences:

    o  The value of @nma:unique is a list of descendant schema node
       identifiers rather than simple leaf names.  However, the XPath
       expressions specified in Section 12.8 work without any
       modifications if the descendant schema node identifiers are
       substituted for k_1, k_2, ..., k_n.

    o  The message appearing as the text of<sch:report>  is different:
       "Violated uniqueness for list CONTELEM".

could be

    The mapping of this annotation element's @tag attribute is almost
    identical as for @nma:key, see Section 12.8, with two small differences:

    o  The value of @tag is a list of descendant schema node
       identifiers rather than simple leaf names.  However, the XPath
       expressions specified in Section 12.8 work without any
       modifications if the descendant schema node identifiers are
       substituted for k_1, k_2, ..., k_n.

    o  The message appearing as the text of<sch:report>  is different:
       "Violated uniqueness for list CONTELEM".

    Only the @tag attribute of this annotation element is mapped.

but it may have to be rewritten to make it clearer.

Jernej

> Regards, Benoit.
>> On Sep 24, 2012, at 10:35 AM, Juergen Schoenwaelder 
>> <[email-masked]> wrote:
>>
>>>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot 
>>>> be mapped into a single @nma:unique attribute. It should be mapped 
>>>> into an element instead, much like the must-stmt. Additional 
>>>> changes may be required throughout the document.
>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2012 10:19:08 +0200

On Sep 26, 2012, at 10:12 AM, Jernej Tuljak <[email-masked]> wrote:

> We should probably determine what the text of the errata should be. The one I reported is now outdated, so unless it can be updated, a new one should be created.

I don't have any experience with the errata procedure but I think the first decision should be whether this qualifies as an erratum, because indeed it changes the DSDL mapping "protocol", as Martin pointed out.

Who is entitled to make this decision?

Lada
 
> 
> As far as I can see the changes to Table 2, 12.16. title (plus TOC entry) and 11.2. are of an editorial nature only ("@nma:unique" --> "<nma:unique>").
> 
> I've already posted what I think the content of 10.55. should be and I don't mind the attribute being renamed to "@tag" (the way Ladislav suggested). Honestly, I put the first word that popped into my mind when I created the report. We could also forget about using an attribute and just put the unique-stmt's argument into the text value of the <nma:unique> element but I would prefer to have it as an attribute (also seems like a less invasive change).
> 
> The content of 12.16. also needs modification so it reflects the change made in 10.55.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2012 11:37:27 +0200

> Who is entitled to make this decision?

I have moved this question over to Benoit since I think we need advice
from the ADs here.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 26 Sep 2012 11:49:42 +0200

Dear all,

While I'm researching on the question "how far can we go with an 
errata", could someone please send to the list the OLD/NEW changes for 
the list below. That would help for the evaluation.

Regards, Benoit.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2012 14:53:02 +0200

> the list below. That would help for the evaluation.

Here it is:

Sec. 5.3, entry in Table 2:
---------------------------

OLD

        | @nma:unique               | 10.55              |      |

NEW

        | <nma:unique>              | 10.55              |      |

Sec. 10.55:
-----------

OLD

   unique "foo ex:bar/baz"

NEW

   This statement is mapped to the <nma:unique> element.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @tag attribute which is attached to the
   <nma:unique> element.

   unique "foo ex:bar/baz"

   is mapped to the following annotation element:

   <nma:unique tag="ex:foo ex:bar/ex:baz"/>

Sec. 11.2, second paragraph:
----------------------------

OLD

   In a Schematron schema generated by the second mapping step, the
   basic unit of organization is a rule represented by the <sch:rule>
   element.  The following NETMOD-specific annotations from the hybrid
   schema (henceforth called "semantic annotations") are mapped to
   corresponding Schematron rules: <nma:must>, @nma:key, @nma:unique,
   @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:
   leaf-list, and also @nma:mandatory appearing as an attribute of <rng:
   choice> (see Section 11.2.1).

NEW

   In a Schematron schema generated by the second mapping step, the
   basic unit of organization is a rule represented by the <sch:rule>
   element.  The following NETMOD-specific annotations from the hybrid
   schema (henceforth called "semantic annotations") are mapped to
   corresponding Schematron rules: <nma:must>, <nma:unique>, @nma:key,
   @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:
   leaf-list, and also @nma:mandatory appearing as an attribute of <rng:
   choice> (see Section 11.2.1).

Sec. 12.16 (including its title):
-----------

OLD

12.16.  The @nma:unique Annotation

   o  The message appearing as the text of <sch:report> is different:
      "Violated uniqueness for list CONTELEM".

NEW

12.16.  The <nma:unique> Annotation

   The mapping of this annotation is similar to @nma:key,
   see Section 12.8, with two small differences:

   o  The value of the @tag attribute of <nma:unique> is a list of
      descendant schema node identifiers rather than simple leaf names.
      However, the XPath expressions specified in Section 12.8 work
      without any modifications if the descendant schema node
      identifiers are substituted for k_1, k_2, ..., k_n.

   o  The message appearing as the text of <sch:report> is different:
      "Violated uniqueness of NODES", where NODES is the value of the
      @tag attribute.

Appendix A:
-----------

OLD

NEW

Thanks, Lada

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Sep 2012 12:20:06 +0200

Dear all,
> I have moved this question over to Benoit since I think we need advice

Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as 
background information...
- As far as I can tell, we agree that this is a bug in the 
specification. So an errata should be filed.
- As far as I can tell, we fall into: "Only errors that could cause 
implementation or deployment problems or significant confusion should be 
Approved."
- As far as I can tell, we don't fall into: "Changes that modify the 
working of a protocol to something that might be different from the 
intended consensus when the document was approved should be either Hold 
for Document Update or Rejected"

I'm in favor to keep the process simple, and to verify the errata, 
instead of producing a new RFC.

However, before doing so, we want to be a safe side, basically making 
sure that there are no other implementations for which this bug fix 
(read non-backward compatibility change) would cause a problem.

So let me propose the following:
- We keep the errata 3362 open for now
- Since errata 3362 needs to updated (and since we can't update this 
errata without approving/rejecting AFAIK), we create a new errata with 
all the changes, as agreed on the mailing list. Do we have an agreement 
on what Lada proposed?
- I send a kind of LC email to the mailing list, with this new errata
- If no issue during this LC, I reject errata 3362 (pointing to the new 
errata), and I verify the new one.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Sep 2012 12:21:11 +0200

Hi Lada,

Thanks for this.
WG, any objections to the changes below?

Regards, Benoit.

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 27 Sep 2012 14:03:15 +0200

Dne 27.9.2012 12:20, piše Benoit Claise:
> Dear all,
>>> I don't have any experience with the errata procedure but I think 
>>> the first decision should be whether this qualifies as an erratum, 
>>> because indeed it changes the DSDL mapping "protocol", as Martin 
>>> pointed out.
>>>
> implementation or deployment problems or significant confusion should 
> be Approved."
> intended consensus when the document was approved should be either 
> Hold for Document Update or Rejected"
>
> all the changes, as agreed on the mailing list. Do we have an 
> agreement on what Lada proposed?
> - If no issue during this LC, I reject errata 3362 (pointing to the 
> new errata), and I verify the new one.
>

I agree with this proposal.

Jernej

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 27 Sep 2012 14:33:25 +0200

> WG, any objections to the changes below?

Table of contents is also a place where "@nma:unique" text appears, so 
perhaps the following is missing:

Table of contents
-------------------

OLD

       12.16. The @nma:unique Annotation ..............................74

NEW

       12.16. The<nma:unique>  Annotation .............................74

Not sure if this is necessary though, since "Sec. 12.16 (including its 
title)" might imply this change too.

The rest seems okay to me.

Jernej

>>>>> A list's unique-stmt has a cardinality of 0..1. Therefore it 
>>>>> cannot be mapped into a single @nma:unique attribute. It should be 
>>>>> mapped into an element instead, much like the must-stmt. 
>>>>> Additional changes may be required throughout the document.
>>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Sep 2012 16:16:55 +0200

> perhaps the following is missing:

Well, yes and no. The table of contents is generated automatically from XML but I assume errata are specified against the text version, so the TOC update should probably be included, too.

Thanks, Lada