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

Martin Bjorklund <mbj@tail-f.com> Tue, 09 January 2018 08:08 UTC

Return-Path: <mbj@tail-f.com>
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 7A604126B7F; Tue, 9 Jan 2018 00:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 uOtn1UGnzIoB; Tue, 9 Jan 2018 00:08:32 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB737124E15; Tue, 9 Jan 2018 00:08:31 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BC521AE0144; Tue, 9 Jan 2018 09:08:30 +0100 (CET)
Date: Tue, 09 Jan 2018 09:06:48 +0100
Message-Id: <20180109.090648.1082913423972100343.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: acee@cisco.com, yang-doctors@ietf.org, draft-ietf-ospf-yang.all@ietf.org, ietf@ietf.org, ospf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1515484295.18448.9.camel@nic.cz>
References: <151255960762.30655.17225294251460480729@ietfa.amsl.com> <D6792F3D.E8CD1%acee@cisco.com> <1515484295.18448.9.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/mnlxDxXrYzkSpiNO_2E6JjhzORs>
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: Tue, 09 Jan 2018 08:08:34 -0000

Hi,

Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi Acee,
> 
> please see inline.
> 
> On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee) wrote:
> > Hi Lada,
> > 
> > Apologies for the delay. We somewhat got hung up on 4 and 6. See inline.
> > 
> > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
> > 
> > > Reviewer: Ladislav Lhotka
> > > Review result: Ready with Issues
> 
> ...
> 
> > > 
> > > 3. Maybe the draft could mention that implementations should supply a
> > >   default routing domain as a system-controlled resource.
> > 
> > Isn’t this more of an RFC8022BIS statement? I guess we could state this as
> > an assumption.
> 
> Probably, but it is not a YANG issue, so I'd leave it to you routing folks to
> decide.
> 
> >  
> > 
> > > 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 for the
> "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.

So the equality test of the identityref is correct.

However, I agree that in most cases 'derived-from-or-self' should be
used, in order to handle derived identities.


/martin