Re: [netmod] yang-json document

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Tue, Feb 10, 2015 at 1:19 PM, Martin Bjorklund <[e-mail]> wrote:
>> Andy Bierman <[e-mail]> wrote:
>>> On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund <[e-mail]> wrote:
>>> > Andy Bierman <[e-mail]> wrote:
>>> >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund <[e-mail]> wrote:
>>> >> > Andy Bierman <[e-mail]> wrote:
>>> >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund <[e-mail]> wrote:
>>> >> >> > Andy Bierman <[e-mail]> wrote:
>>> >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka <[e-mail]> wrote:
>>> >> >> >> > Hi,
>>> >> >> >> >
>>> >> >> >> > I'll try to summarize this long thread. Please comment.
>>> >> >> >> >
>>> >> >> >> > Ladislav Lhotka <[e-mail]> writes:
>>> >> >> >> >
>>> >> >> >> >> Hi,
>>> >> >> >> >>
>>> >> >> >> >> $SUBJ is already several months late, so I think we should proceed
>>> >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision,
>>> >> >> >> >> and it seems two issues need to be resolved:
>>> >> >> >> >>
>>> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I
>>> >> >> >> >>    propose the following change to 4th paragraph in sec. 4 (SHOULD NOT
>>> >> >> >> >>    instead of MUST NOT):
>>> >> >> >> >
>>> >> >> >> > It seems Andy is now the only supporter of this change, and I think
>>> >> >> >> > there are strong technical reasons for keeping namespace rules strict,
>>> >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or
>>> >> >> >> > reformulate the text in the same sense without using 2119 keywords.
>>> >> >> >
>>> >> >> > I think it would be wise to rewrite the text to explain how the
>>> >> >> > different nodes (top-level in module, top-level in remote augment and
>>> >> >> > other) are encoded.  The current 2119 language seems to indicate that
>>> >> >> > there is some kind of choice involved.
>>> >> >> >
>>> >> >> >> >>    OLD
>>> >> >> >> >>
>>> >> >> >> >>    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.
>>> >> >> >> >>
>>> >> >> >> >>    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 strongly object to changing the text above back to OLD.
>>> >> >> >> The debate has been over top-level nodes missing the prefix,
>>> >> >> >> not nested nodes that redundantly declare the same module
>>> >> >> >> as the parent node.
>>> >> >> >
>>> >> >> > No, the debate has been for all nodes.
>>> >> >> >
>>> >> >> >> We already agreed that the receiver has to parse the module name
>>> >> >> >> every time in case it is different.  It has to remember the parent
>>> >> >> >> module name in case it is missing in the child nodes.
>>> >> >> >
>>> >> >> > No, the point is that with deterministic rules, the receiver doesn't
>>> >> >> > have to do any special parsing at all.  The top-level node
>>> >> >> > "interfaces" in "ietf-interfaces" is *always* send as
>>> >> >> > "ietf-interfaces:interfaces", and its child node "interface" is
>>> >> >> > *always* sent as "interface" and the node "ipv4" that augments the
>>> >> >> > interface list is *always* sent as "ietf-ip:ipv4".
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> But what if there is an "acme:interface" that augments
>>> >> >> "ietf-interfaces:interfaces"?
>>> >> >> Then the child node will not always be "interface". It might be
>>> >> >> "acme:interface"
>>> >> >> instead.
>>> >> >
>>> >> > No, in that case there are two separate nodes, one always encoded as
>>> >> > "interface" and one always encoded as "acme:interface", regardless of
>>> >> > how many other augments there are.
>>> >> >
>>> >> >> The server better check, right?
>>> >> >>
>>> >> >> Not checking for a module name means the server might assume
>>> >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces.
>>> >> >> Seems like the server has to check every node.
>>> >> >
>>> >> > No, since with this scheme there is no flexibility, everything is 100%
>>> >> > predictable and stable.
>>> >> >
>>> >>
>>> >> You really think it's a good idea to assume the data from the sender
>>> >> is always valid and doesn't need to be checked?
>>> >
>>> > That is a completely separate question.  We're discussing the best way
>>> > to encode YANG node names in json.  It is up to us to specify this.
>>> > There is no given answer.  With clear and simple rules, chances are
>>> > higher that implementations are correct.
>>> >
>>> >> I don't see how interoperability is increased if the server is
>>> >> forced to reject input it understands.  I doubt customers will
>>> >> see this as a feature instead of a bug.
>>> >
>>> > I think you are missing the point.  If the rule is that a top-level
>>> > node is encoded as <module-name>:<node-name>, why would a server
>>> > "understand" just "interfaces"?  Surely a server would also understand
>>> > <module-name>-<node-name> or <module-name> <node-name>?
>>> >
>>> > Your code can be as liberal as you program it to be, but the
>>> > specification needs to be clear and specify what is *valid*.
>>> >
>>>
>>> The pattern is <module-name>:<local-name> so why would one
>>> change the delimiter to a character that is invalid within a YANG
>>> identifier?  Or to whitespace?  That doesn't make sense.
>>
>> Exactly - the encoding is <module-name>:<local-name>, why would anyone
>> send <local-name>?  If there is just one node, why would your server
>> care about the name at all?
>>
>>
>>> Since everything is 100% predictable as you say, the server
>>> knows that "foo" matches the only node with a a local-name of "foo".
>>> It seems to violate the Postel Principle to reject this input.
>>
>> The Postel Principle says that an implementation should be liberal in
>> what it accepts, i.e., accept things that do not follow the
>> specification.  We are talking about what the *specification* should
>> be.  If the spec says that two forms are legal, the Postel Principle
>> doesn't apply to these two forms, since it is not liberal to accept
>> something that is legal!
>>
>>
>
> So the standard will specify what the server MUST do if a client deviates
> from the mandatory encoding?

If a client deviates from the spec, it is an error. A server implementor
can follow Postel Principle and make the software tolerant to that
error, but it is an error nonetheless.

Along the same lines, server software can tolerate that a client send an
uint8 value as "42." (ending with a dot), which is not permitted by RFC
6020.

Lada

>
> I guess you can write MUST in the standard and I will add yet another
> config parameter to our server to allow more lax parsing.
>
>
>> /martin
>
> Andy

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