Subject: Re: [netmod] yang-json document

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Feb 2015 20:35:43 -0800 (GMT-08:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Feb 5, 2015 8:27 AM
>To: Ladislav Lhotka <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] yang-json document
...
>>>>   NEW
>>>>
>>>>   Names with namespace identifiers in the form shown in Figure 1 MUST
>>>>   be used for all top-level YANG data nodes, and also for all nodes
>>>>   whose parent node belongs to a different namespace.  Otherwise, names
>>>>   with namespace identifiers SHOULD NOT be used.
>>>
>
>I think MUST violates the RFC 2119 rules (issue Randy already raised).
>If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces",
>and there is only 1 possible match, then the receiver is forced to
>reject input that it understands.  Even if there are multiple matches,
>the receiver may be able to detect which object is being sent.
>
>Of course, if there are multiple matches and the receiver cannot
>detect which one is sent, the input MUST be rejected.

Before anyone reads too much into what I wrote let me be clear(er)
about my concern:

If the constraint is not necessary to ensure interoperability, using
"MUST" is inappropriate.  As I understand Andy's argument, receivers
"may be able" to disambiguate.  I'm not convinced that that's sufficient
to ensure interoperability.  Unless the behaviour is adequately specified
so that all conformant implementaions will resolve in the same way the
potential "multiple matches" Andy describes, it sounds like the "MUST"
really *is* appropriate.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Feb 2015 13:34:58 +0100

> potential "multiple matches" Andy describes, it sounds like the "MUST"

Yes, thank you for the clarification. I do think unnecessary entropy in
an encoding it detrimental to interoperability.

In fact, if there are any concerns about the use of 2119 keywords we can
also avoid using them altogether.

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 06:50:30 -0800

> potential "multiple matches" Andy describes, it sounds like the "MUST"

The previous iteration of the rule was interoperable:

    If there are multiple matches of the local-name, the receiver MUST
    reject the input.

Since almost all designers try to avoid local-name conflicts, the liklihood
of any matches at all is still very low.

> Randy

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 16:45:13 +0100

> On 06 Feb 2015, at 15:50, Andy Bierman <[email-masked]> wrote:
> 

Yes, but Martin rightly pointed out that this encoding is not stable in the sense that an augment from a new module may require adding an explicit namespace prefix to old nodes. The current encoding rules fix this because the parent of every node is fixed and cannot be changed.

> of any matches at all is still very low.

We could then get rid of namespaces entirely.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 08:00:26 -0800

> Yes, but Martin rightly pointed out that this encoding is not stable in the sense that an augment from a new module may require adding an explicit namespace prefix to old nodes. The current encodin…

Actually, it is impossible in YANG to augment another namespace with a
top-level data node.

For descendant nodes in the same module, the prefix will not be provided.
For descendant nodes in a different module, the prefix will be provided.

There is the possibility that a future release of the server will add a module
that has a top-level data node with the same local-name.  In this case,
the old client will break.  I have not seen any vendors want to do this.

IMO, SHOULD use the top-level prefix is appropriate, not MUST.

Andy