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

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 
> > On 11 Dec 2014, at 16:01, Andy Bierman <[e-mail]> wrote:
> > 
> > On Thu, Dec 11, 2014 at 12:08 AM, Ladislav Lhotka <[e-mail]>
> > wrote:
> >> Andy Bierman <[e-mail]> writes:
> >> 
> >>> 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.
> >> 
> >> 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.
> >> 
> > 
> > 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.
> > 
> > 
> >>> 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
> >>> 
> >> 
> >> 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.
> >> 
> > 
> > 
> > The receiver already has to check for a prefix so I do not see
> 
> 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.
> 
> > any burden.  It is an added burden to check the prefix
> > and decide it is invalid just because it is redundant.
> > 
> >>> IMO it is too much work for the server to verify that
> >>> 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.

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

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