Subject: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Dec 2014 10:14:06 -0800

Hi,

Sec 4 has changed the rules for module names:

   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 MUST NOT be used.

So it is a protocol error if a prefix is used twice in a row:

   /A:foo/A:bar     --> causes a protocol error and MUST be rejected
   /A:foo/bar MUST be used instead

IMO this is very fragile and does not follow the Postel Principle.
In this example the server knows module 'A' and it is the correct
module for node 'bar'.  Yet it MUST reject the input according
to the new rules.

I prefer these rules:

   - The namespace for a node MUST be uses in top-level
     nodes and if the namespace is changing.
   - If no prefix is present, then the namespace associated with
     the parent node is used

IMO it is too much work for the server to verify that
a prefix is not used. Parsing a prefix is not a burden,
since the code to parse the prefix must be already there.

It is also more hassle on clients that are constructing URLs
from multiple functions. They have to know which prefix
MUST NOT be used.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Dec 2014 09:08:40 +0100

> IMO this is very fragile and does not follow the Postel Principle.

I don't agree it is fragile. The rule for deciding about the presence or
absence of a namespace ID is robust and dead simple: compare the
namespaces of the current node and its parent - if they differ, add the
namespace ID.

>    - If no prefix is present, then the namespace associated with

This would be useful for senders that want to skip making the above
decision a instead attach namespace IDs to all names. But this just
shifts the burden to the receiving side.

> a prefix is not used. Parsing a prefix is not a burden,

I don't think it is difficult, see above.

> since the code to parse the prefix must be already there.

Parsing is one thing and comparing the namespace ID with the parent is
another. With the existing rules, the namespace change is signalled in a
much clearer way.

> from multiple functions. They have to know which prefix

I am not sure I understand the part about multiple functions but IMO
constructing an URL could still be very simple if it is done from left
to right: The namespace is on the first component and then whenever it
changes.

Lada

>
>
>
> Andy
>
> _______________________________________________
> 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: Thu, 11 Dec 2014 07:01:22 -0800

> namespaces of the current node and its parent - if they differ, add the

It is not robust at all.
If the correct prefix is provided it should be accepted.
That would be robust.  Rejecting an identifier for using
the correct prefix for a node is fragile, and quite counter-intuitive
for anybody familiar with XPath.

> shifts the burden to the receiving side.

The receiver already has to check for a prefix so I do not see
any burden.  It is an added burden to check the prefix
and decide it is invalid just because it is redundant.

> another. With the existing rules, the namespace change is signalled in a

That encoding is also accepted.
Redundant information is not the same thing as incorrect information.
The receiver must be liberal in what it accepts.  Rejecting redundant
but valid data does not follow the Postel Principle.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Dec 2014 16:24:46 +0100

> On 11 Dec 2014, at 16:01, Andy Bierman <[email-masked]> wrote:
> 

The receiver only needs to check whether the member name contains a colon, and nothing else has to be done if it doesn’t - and this is the most frequent case by far. 

> but valid data does not follow the Postel Principle.

Although I prefer to have namespace ID only where the namespace changes, I could live with your proposal. I just want to hear others to express their opinion.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Dec 2014 16:41:08 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> The receiver only needs to check whether the member name contains a
> colon, and nothing else has to be done if it doesn’t - and this is the
> most frequent case by far.
> 

+1  Easier to read, and less error-prone, and consistent.

> Although I prefer to have namespace ID only where the namespace
> changes, I could live with your proposal. I just want to hear others
> to express their opinion.

I also prefer to have the prefix only when the namespace changes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2014 07:50:48 -0800

> I also prefer to have the prefix only when the namespace changes.

The receiver cannot just look for a ":" char since the prefix
may in fact indicate a new module name.  The receiver MUST
be capable of parsing a module-name on any node.

I can see SHOULD but not MUST for suppressing redundant prefixes.
Otherwise the receiver MUST reject input it actually understands,
and that is fragile.

Andy