Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Andy Bierman <[e-mail]>]

>
> ....




> > So what do you suggest? The last paragraph in sec. 9.10.3 is clearly
> wrong.
>
> I agree it is wrong, but only for identityref values that are defined
> in a module that has not been imported.  I stronlgy agree w/ Andy that
> this does NOT mean that we should change *working* and defined
> behaviour in an errata.
>


I think there is other text in the RFC that says a prefix is resolved in
the local module.
This is the only design that makes any sense, and the only design that
could ever work.
The module author has no control over prefix usage and imports in other
modules.



> The intention (for better or worse) was that the value would use the
> prefix used in imports.  This means that if you want to do any kind of
> comparision of the string value to some known identities, then you
> must import that module so that there is a prefix defined.  This was
> the intention.
>
> From this follows that (for all practical matters), the string value
> of an identity defined in a module that is not imported doesn't really
> matter.
>
> > Note also that this paragraphs tries to define the string value of an
> > identityref node instance for any XPath expression, which needn't
> necessarily be
> > a simple EqualityExpr.
>
>

The derived-from and derived-from-or-self functions are flawed
because they use prefixes instead of module names and a missing
prefix means the current module instead of the local module.
I don't see how using derived-from-or-self(type, "foo") is any better
than type="foo".  The latter is being used a lot and the XPath functions
are not being used (by our customers).

Seems new XPath functions are needed, like
   derived-from2(type, "iana-if-type", "ethernetCsmacd")




>
>
> /martin
>
>
Andy


>
>
> >
> > Lada
> >
> > >
> > >
> > > > Lada
> > >
> > >
> > > Andy
> > >
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> Lada
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> > /martin
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > > Lada
> > > > >> > >
> > > > >> > >
> > > > >> > > >
> > > > >> > > > and
> > > > >> > > >
> > > > >> > > >   module b {
> > > > >> > > >     ...
> > > > >> > > >     import ietf-ospf {
> > > > >> > > >       prefix y;
> > > > >> > > >     }
> > > > >> > > >     ...
> > > > >> > > >     leaf bar {
> > > > >> > > >       when "../type = 'y:ospfv3'";
> > > > >> > > >       ...
> > > > >> > > >     }
> > > > >> > > >   }
> > > > >> > > >
> > > > >> > > > You may not like it, but these two modules are both correct
> > > > according
> > > > >> > > > to the rules defined in RFC 7950.  The string value of the
> "type"
> > > > leaf
> > > > >> > > > *when evaluating the when expression* is different in the
> different
> > > > >> > > > modules.  See the last paragraph of section 9.10.3 in RFC
> 7950.
> > > > >> > > >
> > > > >> > > > > > > Also, potentially there can be a collision in
> prefixes and
> > > > then this
> > > > >> > > >
> > > > >> > > > also
> > > > >> > > > > > > breaks down.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > No, two modules cannot be imported with the same prefix.
> > > > >> > > > >
> > > > >> > > > > I have to disagree. An identity derived from the
> > > > >> > > > > "ietf-routing:control-protocol-type" base identity can
> be defined
> > > > >> > > > > in a module that is not imported anywhere. If a server
> declares
> > > > such
> > > > >> > > > > a module as implemented, then "rt:type" may have this
> value per
> > > > >> > > > > sec. 9.10.2.
> > > > >> > > > >
> > > > >> > > > > And, consequently, there may be two different modules with
> > > > >> > > > > conflicting prefixes defining identities that are derived
> from
> > > > >> > > > > "ietf-routing:control-protocol-type".
> > > > >> > > >
> > > > >> > > > Sure, but this is not the point.
> > > > >> > > >
> > > > >> > > > > > > A moral of the namespace/prefix story in XML was that
> relying
> > > > of
> > > > >> > > > > > > namespace prefixes having a particular value is a
> really bad
> > > > >> > > > > > > idea. I know that the cited paragraph was intended to
> make
> > > > such
> > > > >> > > > > > > XPath string comparisons more deterministic, but it
> is also
> > > > >> > > > > > > problematic and should be avoided if possible.
> > > > >> > > > > >
> > > > >> > > > > > Note that this prefix is under the control of the module
> > > > designer
> > > > >> > > > > > writing the XPath expression.  The same identityref
> value might
> > > > use a
> > > > >> > > > >
> > > > >> > > > > No, it is not. The prefixes appear in instance data.
> > > > >> > > >
> > > > >> > > > The prefix *in the when expression* is under the control of
> the
> > > > module
> > > > >> > > > designer, as explained above.
> > > > >> > > >
> > > > >> > > > You are correct that the prefix in an XML encoding is not
> under
> > > > >> > > > control of the module designer, but noone has claimed that.
> > > > >> > > >
> > > > >> > > > I agree that it is unfortunate that context-specific
> prefixes are
> > > > used
> > > > >> > > > for the identityref values.  It would have been better if
> we used a
> > > > >> > > > context free representation, e.g.
> "<module-name>:<identity>".  But
> > > > >> > > > that's another discussion.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > /martin
> > > > >> > >
> > > > >> > > --
> > > > >> > > Ladislav Lhotka
> > > > >> > > Head, CZ.NIC Labs
> > > > >> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > >> > >
> > > > >> --
> > > > >> Ladislav Lhotka
> > > > >> Head, CZ.NIC Labs
> > > > >> PGP Key ID: 0xB8F92B08A9F76C67
> > > > >>
> > > > >> _______________________________________________
> > > > >> yang-doctors mailing list
> > > > >> [e-mail]
> > > > >> https://www.ietf.org/mailman/listinfo/yang-doctors
> > > > >>
> > > >
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > >
> > > > _______________________________________________
> > > > yang-doctors mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/yang-doctors
> > >
> > >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
>