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

Ladislav Lhotka <lhotka@nic.cz> Mon, 15 January 2018 09:38 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E19126CD6 for <yang-doctors@ietfa.amsl.com>; Mon, 15 Jan 2018 01:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpoZisL73lVR for <yang-doctors@ietfa.amsl.com>; Mon, 15 Jan 2018 01:38:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E5C12D86B for <yang-doctors@ietf.org>; Mon, 15 Jan 2018 01:38:21 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:68c6:92ff:fe01:2298]) by mail.nic.cz (Postfix) with ESMTPSA id 6616663F3A; Mon, 15 Jan 2018 10:38:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516009099; bh=XqQJ88Mi6rDMqap3fJljjhrR8jHBmJJOv2XNWoAqrkU=; h=From:To:Date; b=pgS/kauGglZc5OMlyu4mYQebQpGcqrMZCLzmslsI0PuNDFXPG8bI7IELTMCV+ShFu 9VtqBGn+cn2LttTsUloDNkyibaZmyh/IxMcQiR3Of3tyV+HIxdLP/2H0hQQImO9tFG kpuZuuo04HXVaK6c1efruLWSoeW5u5ZT27ODPDhc=
Message-ID: <1516009099.5426.13.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: andy@yumaworks.com, yang-doctors@ietf.org
Date: Mon, 15 Jan 2018 10:38:19 +0100
In-Reply-To: <20180115.095941.341257692373089671.mbj@tail-f.com>
References: <87po6fmlkn.fsf@nic.cz> <CABCOCHSFfgjVS58S0po-9yEUZw=cjzG6k_LY8V9NSdy+kHQvLg@mail.gmail.com> <1516006155.5426.3.camel@nic.cz> <20180115.095941.341257692373089671.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/VMiUJzP2HxH94UmQfd4DAqSX1OQ>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 09:38:26 -0000

On Mon, 2018-01-15 at 09:59 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Fri, 2018-01-12 at 09:45 -0800, Andy Bierman wrote:
> > > 
> > > 
> > > On Fri, Jan 12, 2018 at 2:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > Martin Bjorklund <mbj@tail-f.com> writes:
> > > > 
> > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> On Wed, 2018-01-10 at 12:58 +0100, Martin Bjorklund wrote:
> > > > >> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> > > On Wed, 2018-01-10 at 10:35 +0100, Martin Bjorklund wrote:
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > Replying to this only on yang-doctors, since this is mostly a
> > > > >> > > > discussion about the interpretation of RFC 7950.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> > > > > On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> > > > >> > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> > > > > > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund
> wrote:
> > > > >> > > > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> > > > > > > > > On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee)
> > > > wrote:
> > > > >> > > > > > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@nic.
> cz>
> > > > wrote:
> > > > >> > > >
> > > > >> > > > [...]
> > > > >> > > >
> > > > >> > > > > > > > > > > 4. In "when" expressions, the module uses literal
> > > > strings
> > > > >> >
> > > > >> > for
> > > > >> > > > > > > > > > >   identities. This is known to be problematic,
> the
> > > > XPath
> > > > >> > > >
> > > > >> > > > functions
> > > > >> > > > > > > > > > >   derived-from() or derived-from-or-self() should
> be
> > > > used
> > > > >> > > >
> > > > >> > > > instead.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Why is this problematic? Is it because the types
> can be
> > > > >> >
> > > > >> > extended?
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > That's one reason: derived identities should often
> also
> > > > satisfy
> > > > >> >
> > > > >> > the
> > > > >> > > > > > > > > constraint.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > But the more serious problem is that things like
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >     when "../../../../../../../rt:type =
> 'ospf:ospfv3'"
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > rely on plain string comparison that depends od the
> > > > actual
> > > > >> >
> > > > >> > prefix
> > > > >> > > > used
> > > > >> > > > > > > >
> > > > >> > > > > > > > > "rt:type" value. For one, according to RFC 7951 the
> JSON
> > > > >> >
> > > > >> > encoding of
> > > > >> > > > > > > > > this value
> > > > >> > > > > > > > > would be "ietf-ospf:ospfv3" so the above expression
> is
> > > > always
> > > > >> > > >
> > > > >> > > > false.
> > > > >> > > > > > > >
> > > > >> > > > > > > > This is not correct; the when expression is not
> evaluated
> > > > on the
> > > > >> >
> > > > >> > JSON
> > > > >> > > > > > > > encoding.  See the last paragraph of section 9.10.3 in
> RFC
> > > > 7950:
> > > > >> > > > > > > >
> > > > >> > > > > > > >    The string value of a node of type "identityref" in
> a
> > > > "must" or
> > > > >> > > > > > > >    "when" XPath expression is the referred identity's
> > > > qualified
> > > > >> >
> > > > >> > name
> > > > >> > > > > > > >    with the prefix present.  If the referred identity
> is
> > > > defined
> > > > >> >
> > > > >> > in an
> > > > >> > > > > > > >    imported module, the prefix in the string value is
> the
> > > > prefix
> > > > >> > > >
> > > > >> > > > defined
> > > > >> > > > > > > >    in the corresponding "import" statement.  Otherwise,
> the
> > > > prefix
> > > > >> >
> > > > >> > in
> > > > >> > > > > > > >    the string value is the prefix for the current
> module.
> > > > >> > > > > > >
> > > > >> > > > > > > This is weird, to say the least. The leafref instance may
> > > > have an
> > > > >> > > >
> > > > >> > > > identity
> > > > >> > > > > > > value
> > > > >> > > > > > > that is defined in a module that (has to be implemented
> by
> > > > the
> > > > >> >
> > > > >> > server
> > > > >> > > > but)
> > > > >> > > > > > > needn't be imported in the module that contains the XPath
> > > > >> >
> > > > >> > expression. So
> > > > >> > > > I
> > > > >> > > > > > > don't
> > > > >> > > > > > > know what 'corresponding "import" statement' this
> paragraph
> > > > is
> > > > >> >
> > > > >> > talking
> > > > >> > > > > > > about.
> > > > >> > > > > >
> > > > >> > > > > > It has to import the module in order to give a prefix,
> which
> > > > then can
> > > > >> > > > > > be used in the XPath expression.
> > > > >> > > > >
> > > > >> > > > > In the XPath expression above, do you mean the "rt" prefix of
> > > > >> > > > > "rt:type"?
> > > > >> > > >
> > > > >> > > > No, I meant the "ospf" prefix for the module "ietf-ospf".
> > > > >> > > >
> > > > >> > > > > If so,
> > > > >> > > > > it is irrelevant for the string comparison, what's important
> is
> > > > the
> > > > >> >
> > > > >> > *value*
> > > > >> > > > of
> > > > >> > > > > the "rt:type" instance, which can be an identity defined in a
> > > > module
> > > > >> >
> > > > >> > that
> > > > >> > > > > needn't be imported by ietf-routing, ietf-ospf or whatever.
> Sec.
> > > > 9.10.2:
> > > > >> > > > >
> > > > >> > > > >    On a particular server, the valid values are further
> > > > restricted
> > > > >> > > > >    to the set of identities defined in the modules
> implemented by
> > > > >> > > > >    the server.
> > > > >> > > >
> > > > >> > > > Because of the way the representation of identities work in
> > > > must/when
> > > > >> > > > expressions, you *must* import the module where the identity is
> > > > >> > > > define, if you want to use the identity for equality
> comparision
> > > > like
> > > > >> > > > in the example.
> > > > >> > > >
> > > > >> > > > You may have:
> > > > >> > > >
> > > > >> > > >   module a {
> > > > >> > > >     ...
> > > > >> > > >     import ietf-ospf {
> > > > >> > > >       prefix x;
> > > > >> > > >     }
> > > > >> > > >     ...
> > > > >> > > >     leaf foo {
> > > > >> > > >       when "../type = 'x:ospfv3'";
> > > > >> > > >       ...
> > > > >> > > >     }
> > > > >> > > >   }
> > > > >> > >
> > > > >> > > The problem here is not with the literal 'x:ospf' but rather with
> the
> > > > string
> > > > >> > > value of the leafref node instance ("../type" here), and clearly
> it
> > > > is what
> > > > >> >
> > > > >> > sec.
> > > > >> > > 9.10.3 talks about ("string value of a [leafref] node").
> > > > >> > >
> > > > >> > > I can define a module like
> > > > >> > >
> > > > >> > > module foo-ospf {
> > > > >> > >   namespace "http://example.com/foo-ospf";
> > > > >> > >   prefix ospf;
> > > > >> > >   import ietf-routing {
> > > > >> > >     prefix rt;
> > > > >> > >   }
> > > > >> > >   identity ospfv3 {
> > > > >> > >     base "rt:routing-protocol";
> > > > >> > >   }
> > > > >> > >   ...
> > > > >> > > }
> > > > >> > >
> > > > >> > > Now, if the server advertizes both ietf-ospf and foo-ospf as
> > > > implemented
> > > > >> >
> > > > >> > (which
> > > > >> > > is legal), the module foo-ospf needn't be imported anywhere and
> still
> > > > the
> > > > >> >
> > > > >> > "type"
> > > > >> > > leaf instance can have both values "ietf-ospf:ospfv3" and "foo-
> > > > ospf:ospfv3",
> > > > >> > > provided that it is defined as
> > > > >> > >
> > > > >> > > leaf type {
> > > > >> > >   type identityref {
> > > > >> > >     base rt:routing-protocol;
> > > > >> > >   }
> > > > >> > > }
> > > > >> > >
> > > > >> > > And I wonder what the last paragraph in sec. 9.10.3 means in this
> > > > situation,
> > > > >> > > i.e. what string value of "type" is used in the evaluation of the
> > > > XPath
> > > > >> > > expression in your module "a", if the value-space value of 'type'
> > > > instance
> > > > >> >
> > > > >> > in a
> > > > >> > > datastore is either of the two '...:ospfv3' identities.
> > > > >> > >
> > > > >> > > Do you see what I mean?
> > > > >> >
> > > > >> > Do you mean that the problem is that the spec does not define what
> the
> > > > >> > string value is if the module where the identity is defined is not
> > > > >> > imported?
> > > > >> >
> > > > >> > I agree that this is an issue.
> > > > >> >
> > > > >> > BUT, actually, if you look the text in the spec:
> > > > >> >
> > > > >> >    The string value of a node of type "identityref" in a "must" or
> > > > >> >    "when" XPath expression is the referred identity's qualified
> name
> > > > >> >    with the prefix present.  If the referred identity is defined in
> an
> > > > >> >    imported module, the prefix in the string value is the prefix
> > > > defined
> > > > >> >    in the corresponding "import" statement.  Otherwise, the prefix
> in
> > > > >> >    the string value is the prefix for the current module.
> > > > >> >
> > > > >> > If you blindly follow this, the last sentence would have to apply,
> and
> > > > >> > the string would be "a:ospfv3", which clearly is broken.
> > > > >>
> > > > >> It depends on what "current module" means.
> > > > >
> > > > > "current module" and "local module" means the module where the "must"
> > > > > or "when" expression is defined.  There was a separate thread about
> > > > > this as well.
> > > > 
> > > > OK, then it really makes no sense to add the local prefix.
> > > > 
> > > > >
> > > > >> It could also be interpreted as the
> > > > >> module in which the identity is defined, but then we can get the
> > > > collision of
> > > > >> prefixes as in my example.
> > > > >>
> > > > >> >
> > > > >> > For all practical purposes, I think the string value can be "" if
> the
> > > > >> > identity is defined in a module that is not imported, and is not
> > > > >> > defined in the current module.
> > > > >>
> > > > >> I think a better solution would be to avoid prefixes in lexical-space
> > > > identity
> > > > >> values altogether and use the same string as in JSON encoding (RFC
> 7951).
> > > > The
> > > > >> XPath expression from your example would become
> > > > >>
> > > > >>     "../type = 'ietf-ospf:ospfv3'"
> > > > >>
> > > > >> Everything would then be straightforward and non-ambiguous.
> > > > >
> > > > > Yes, as I wrote in my previous email, I agree, this would be better.
> > > > > But that's for YANG 2.0, unfortunately.
> > > > 
> > > > Maybe not. If we agree that the last paragraph in 9.10.3 is wrong ang
> > > > needs an erratum, then I think instead of saying that the XPath string
> > > > value is the empty string as you suggested (which is weird and
> > > > non-intuitive), this paragraph can say that the value (only for XPath!)
> > > > is as in RFC 7951.
> > > > 
> > > > In fact, after re-reading sec. 9.10, I believe it is even not required
> > > > to import the module in order to be able to use the prefix in a string
> > > > literal, as "x" in
> > > > 
> > > >     "../type = 'x:ospfv3'"
> > > > 
> > > > because it is just an XPath 1.0 string with no additional semantics, so
> > > > module authors can equally well write
> > > > 
> > > >     "../type = 'ietf-ospf:ospfv3'"
> > > > 
> > > > without importing "ietf-ospf".
> > > > 
> > > > Of course, we could also replace the paragraph with a statement that the
> > > > result of using bare identityref string values in XPath is undefined and
> > > > thus force everybody to use the XPath functions.
> > > > 
> > > 
> > > 
> > > I do not agree with this interpretation.
> > > The term "prefix" is used 10 times in that section.
> > > It is clear that the WG meant "prefix" not "module name".
> > > This cannot be changed by an errata.
> > 
> > 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.

A more serious problem is that this text mixes up the prefix as defined in the
YANG module with the prefix that applies to instance values. A newcomer that
reads this text may wonder why an identity value is combined with a prefix of a
module in which the identity is NOT defined.

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

This is IMO not true. As I already wrote, for using a when expression like

   when "../type = 'ospf:ospfv3'"

it is not necessary to import the "ietf-ospf" module and thus have the "ospf"
prefix defined. If you think it is necessary, then point me to the relevant
text.

Lada


> 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.
> 
> 
> 
> /martin
> 
> 
> 
> > 
> > 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
> > > > >> yang-doctors@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/yang-doctors
> > > > >>
> > > > 
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > yang-doctors mailing list
> > > > yang-doctors@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/yang-doctors
> > > 
> > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67