Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-01.txt

From: Jernej Tuljak <[email-masked]>
Date: Wed, 05 Nov 2014 14:18:25 +0100

(now replying to the proper thread)

I see that the issues I raised regarding XPath expressions 
(http://www.ietf.org/mail-archive/web/netmod/current/msg10172.html) have 
now made it into rfc6087bis-01 section 5.5.

Section 5.5.1, what should a YANG compiler return for 'namespace-uri()' 
and 'name()' function if they are used?

I still disagree with Section 5.5.2 Axes, where it describes usage 
guidelines of preceding-sibling and following-sibling. These may be used 
without issue if document order does not affect the outcome of the 
expression, the same way preceding and following can be. See Ladislav's 
suggestion for a possible solution 
(http://www.ietf.org/mail-archive/web/netmod/current/msg10191.html).

Section 5.5.4. Wildcards:
* (first paragraph) the last sentence ("This is due to augmenting nodes 
from other modules."), seems redundant or wrong. Augmentation is not the 
only thing that affects XPath expressions that use wildcards. Simply 
implementing another module that defines a data tree is enough.
* (second paragraph) the asterisk is not an operator in the context 
where it is being described, it is a node test. The asterisk that 
represents an operator in XPath has nothing to do with this text which 
may lead to confusion.
* (second paragraph) term "augmenting objects" should probably be 
"augmented objects".

Jernej

Dne 24.10.2014 1:30, piše [email-masked]:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>
>          Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
>          Author          : Andy Bierman
> 	Filename        : draft-ietf-netmod-rfc6087bis-01.txt
> 	Pages           : 36
> 	Date            : 2014-10-23
>
> Abstract:
>     This memo provides guidelines for authors and reviewers of Standards
>     Track specifications containing YANG data model modules.  Applicable
>     portions may be used as a basis for reviews of other YANG data model
>     documents.  Recommendations and procedures are defined, which are
>     intended to increase interoperability and usability of Network
>     Configuration Protocol (NETCONF) implementations that utilize YANG
>     data model modules.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Nov 2014 07:07:47 -0800

Hi,

Can you suggest replacement text for the specific details you do not like?
I will look into your comments on the Axes and Wildcards sections.

Andy

On Wed, Nov 5, 2014 at 5:18 AM, Jernej Tuljak <[email-masked]> wrote:
> (http://www.ietf.org/mail-archive/web/netmod/current/msg10172.html) have now
> made it into rfc6087bis-01 section 5.5.
>
> Section 5.5.1, what should a YANG compiler return for 'namespace-uri()' and
> 'name()' function if they are used?
>
> * (first paragraph) the last sentence ("This is due to augmenting nodes from
> other modules."), seems redundant or wrong. Augmentation is not the only
> thing that affects XPath expressions that use wildcards. Simply implementing
> another module that defines a data tree is enough.
> * (second paragraph) the asterisk is not an operator in the context where it
> is being described, it is a node test. The asterisk that represents an
> operator in XPath has nothing to do with this text which may lead to
> confusion.
> * (second paragraph) term "augmenting objects" should probably be "augmented
> objects".
>
> Jernej
>

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 07 Nov 2014 10:19:25 +0100

> I will look into your comments on the Axes and Wildcards sections.

See below.

>> 'name()' function if they are used?

OLD:
    The 'namespace-uri' and 'name' functions SHOULD NOT be used.
    Expanded names in XPath are different than YANG.  A specific
    canonical representation of a YANG expanded name does not exist.

NEW:
    The 'namespace-uri' and 'name' functions SHOULD NOT be used.
    Expanded names in XPath are different than YANG.  A specific
    canonical representation of a YANG expanded name does not exist.
    The YANG compiler SHOULD return an empty string for both of
    these functions.

>> (http://www.ietf.org/mail-archive/web/netmod/current/msg10191.html).

OLD:
    The 'preceding', and 'following' axes SHOULD NOT be used.  These
    constructs rely on XML document order within a NETCONF server
    configuration database, which may not be supported consistently or
    produce reliable results across implementations.  Predicate
    expressions based on static node properties (e.g., element name or
    value, 'ancestor' or 'descendant' axes) SHOULD be used instead. The
    'preceding' and 'following' axes MAY be used if document order is not
    relevant to the outcome of the expression (e.g., check for global
    uniqueness of a parameter value).

    The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.

    A server is only required to maintain the relative XML document order
    of all instances of a particular user-ordered list or leaf-list. The
    'preceding-sibling' and 'following-sibling' axes MAY be used if they
    are evaluated in a context where the context node is a user-ordered
    'list' or 'leaf-list'.

NEW:
    The 'preceding', 'following', 'preceding-sibling' and 
'following-sibling'
    axes SHOULD NOT be used.  These constructs rely on XML document
    order within a NETCONF server configuration database, which may
    not be supported consistently or produce reliable results across
    implementations.  Predicate expressions based on static node
    properties (e.g., element name or value, 'ancestor' or 'descendant'
    axes) SHOULD be used instead.  The 'preceding', 'following',
    'preceding-sibling' and 'following-sibling' axes MAY be used if
    document order is not relevant to the outcome of the expression
    (e.g., check for global uniqueness of a parameter value).

    A server is only required to maintain the relative XML document order
    of all instances of a particular user-ordered list or leaf-list. The
    'preceding-sibling' and 'following-sibling' axes MAY be used if they are
    evaluated in a context where the context node is a user-ordered 'list'
    or 'leaf-list'.

>> * (second paragraph) term "augmenting objects" should probably be "augmented

I may have misunderstood the wildcards section. It was not trying to 
solve the "module containment breach" issue I mentioned, which could 
also be considered as a "wildcard". That is why that sentence was 
bothering me. You could combine the two in the same section.

OLD:
    It is possible to construct XPath expressions that will evaluate
    differently when combined with several modules within a server
    implementation, then when evaluated within the single module. This
    is due to augmenting nodes from other modules.

    Wildcard expansion is done within a server against all the nodes from
    all namespaces, so it is possible for a 'must' or 'when' expression
    that uses the '*' operator will always evaluate to false if processed
    within a single YANG module.  In such cases, the 'description'
    statement SHOULD clarify that augmenting objects are expected to
    match the wildcard expansion.

       when /foo/services/*/active {
         description
           "No services directly defined in this module.
            Matches objects that have augmented the services container.";
       }

NEW:
    It is possible to construct XPath expressions that will evaluate
    differently when combined with several modules within a server
    implementation, then when evaluated within the single module. This
    is due to the fact that expression evaluation is done within a server
    against all the nodes from all namespaces. An expression such as

       //*[local-name() = 'services']//*[local-name() = 'active']

    could unexpectedly evaluate to true when another module that
    happens to match the expression's location path is added to the
    server implementation. Such expressions SHOULD not be used.

    Augmentation represents a special case. If augmented objects are
    expected to match the wildcard expansion it is possible for a 'must'
    or 'when' expression that uses the '*' node test to always evaluate
    to false if processed within a single YANG module.  In such cases,
    the 'description' statement SHOULD clarify the intent.

       when /foo/services/*/active {
         description
           "No services directly defined in this module.
            Matches objects that have augmented the services container.";
       }

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Nov 2014 15:40:52 +0100

>     The YANG compiler SHOULD return an empty string for both of

While I agree these functions (and perhaps local-name(), too) should not
be used, I don't understand the reasoning. Why are expanded names
different? The context for XPath evaluation has to be an XML document. 

>     (e.g., check for global uniqueness of a parameter value).

I would start with the last sentence and then just add "Otherwise these
axes SHOULD NOT be used."

>             Matches objects that have augmented the services container.";

+1

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Nov 2014 07:42:55 -0800

> different? The context for XPath evaluation has to be an XML document.

I think you are right.  Since the namespace-stmt is mapped to the
XML expanded name part when parsing XML, the YANG compiler
can just return the namespace-stmt value for the current module.

> axes SHOULD NOT be used."

Can you expand the text you want?
I don't know which text you are patching.

>>             Matches objects that have augmented the services container.";

+2

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Nov 2014 17:50:29 +0100 (CET)

> can just return the namespace-stmt value for the current module.

+1  This is what our implementation does.

But the 'name' is more problematic.  When the input is an XML
document, it returns a prefixed name if there is a prefix for the
namespace in teh XML source, or unprefixed if no such prefix is
declared.  It is pretty clear that it SHOULD NOT be used... or at
least the result is implementation dependent.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Nov 2014 08:58:59 -0800

> +1  This is what our implementation does.

I had to look at my code to make sure, since I wrote it 6 years ago,
but we do the same thing.

> least the result is implementation dependent.

So the restriction should be changed to be just for "name".

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Nov 2014 18:02:20 +0100

> can just return the namespace-stmt value for the current module.

Yup.

NEW:

    The 'preceding', 'following', 'preceding-sibling' and
    'following-sibling' axes MAY be used if document order is not
    relevant to the outcome of the expression (e.g., check for global
    uniqueness of a parameter value). Otherwise these axes SHOULD NOT be
    used.

    A server is only required to maintain the relative XML document
    order of all instances of a particular user-ordered list or
    leaf-list. The 'preceding-sibling' and 'following-sibling' axes MAY
    be used if they are evaluated in a context where the context node is
    a user-ordered 'list' or 'leaf-list'.

I think the sentence about what SHOULD be used instead of those axes is
somewhat unclear and in fact unnecessary.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Nov 2014 18:28:50 +0100

> least the result is implementation dependent.

Or the prefix could always be the argument of the corresponding "prefix"
statement (by definition).

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Nov 2014 20:59:11 +0100

> statement (by definition).

Actually, it is exactly what the first bullet in sec. 6.4.1 (XPath Context) implies.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 10 Nov 2014 13:53:56 +0100

>>> +1  This is what our implementation does.

+1 This is what our validator implementation currently does too.

> Actually, it is exactly what the first bullet in sec. 6.4.1 (XPath Context) implies.

What about augmented nodes - nodes from foreign namespaces  - not 
covered by this bullet? The augmenting module could easily introduce a 
prefix clash. Also, accessible trees might be made up of data nodes from 
modules that had their prefixes obfuscated due to prefix clash 
resolution (DSDL plugin of pyang does it as specified by RFC6110). An 
instance would probably contain those, not original prefixes.

It would be nice to have as many standard functions as possible do 
something but I think tolerating 'name' might be pushing it. It is 
inherently instance dependent per XPath spec. Can you come up with a 
useful use case for it within a YANG model? If not, it would be safer to 
just say SHOULD NOT be used.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Nov 2014 14:13:23 -1000

> prefix clash. Also, accessible trees might be made up of data nodes

If the XPath expression is inside an augment then its context is derived
from the augmenting module.

> instance would probably contain those, not original prefixes.

Yes, because then we deal with a real XML document and not a conceptual
one.

> just say SHOULD NOT be used.

Yes, I agree.

Lada