Re: [netmod] augment and if-feature

Martin Bjorklund <mbj@tail-f.com> Wed, 15 March 2017 12:05 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0166129C60 for <netmod@ietfa.amsl.com>; Wed, 15 Mar 2017 05:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 dy-bfDq7Q_0n for <netmod@ietfa.amsl.com>; Wed, 15 Mar 2017 05:05:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC186129C34 for <netmod@ietf.org>; Wed, 15 Mar 2017 05:05:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F8811AE02A7; Wed, 15 Mar 2017 13:05:50 +0100 (CET)
Date: Wed, 15 Mar 2017 13:05:55 +0100
Message-Id: <20170315.130555.1100205223171802711.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: phil@juniper.net, netmod@ietf.org, joey.boyd@adtran.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <bb503c8c-55e2-2a6a-fad5-ed10669a85fe@cisco.com>
References: <bb5472be-3882-785f-3c53-148bae6959af@cisco.com> <20170315.112044.1525149482580030224.mbj@tail-f.com> <bb503c8c-55e2-2a6a-fad5-ed10669a85fe@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FV0TKIpmCmHEk2n9D0xZ9Q1YSrI>
Subject: Re: [netmod] augment and if-feature
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 12:05:54 -0000

Robert Wilton <rwilton@cisco.com> wrote:
> 
> 
> On 15/03/2017 10:20, Martin Bjorklund wrote:
> > Robert Wilton <rwilton@cisco.com> wrote:
> >> Hi,
> >>
> >> On 15/03/2017 07:28, Martin Bjorklund wrote:
> >>> Phil Shafer <phil@juniper.net> wrote:
> >>>> Martin Bjorklund writes:
> >>>>> Phil Shafer <phil@juniper.net> wrote:
> >>>>>> Martin Bjorklund writes:
> >>>>>>>> What are your thoughts on this? Surely, an augment should not have to
> >>>>>>>> contain if-feature statements of all parents of the augmented node.
> >>>>>>> The spec says:
> >>>>>>>
> >>>>>>>     When a server implements a module containing an "augment"
> >>>>>>>     statement,
> >>>>>>>     that implies that the server's implementation of the augmented
> >>>>>>>     module
> >>>>>>>     contains the additional nodes.
> >>>>>>>
> >>>>>>> Compare with a simple augment of a node w/o an if-feature.  In this
> >>>>>>> case, if the server implements the augmenting module, it MUST also
> >>>>>>> implement the augmented module.
> >>>>>> It implements the module, but it doesn't implement the nodes
> >>>>>> since it doesn't express the feature.  IMHO this is a tool
> >>>>>> bug and/or an errata,since otherwise one has to carry features
> >>>>>> forward, repeating the if-feature using the original modules
> >>>>>> prefix:feature-name on every augment of feature-based nodes.
> >>>>> Well, I agree that it would have been better to state that if a server
> >>>>> doesn't implement the augment target, then it doesn't implement the
> >>>>> augment either.  But the text is pretty clear; this is not how it
> >>>>> works.  This is not appropriate to "fix" in an errata.
> >>>> I'm missing the part of the text that's clear.  The above quoted
> >>>> section certainly doesn't say this.  That text is saying "if you
> >>>> implement a module that augments a set of nodes, then the server's
> >>>> schema for that original set of nodes now includes the new set of
> >>>> nodes".  It's referring to schema nodes.
> >>> It explicitly says that server's *implementation* of the augmented
> >>> module contains the additional nodes.
> >> Section "5.6.5.  Implementing a Module", doesn't mention features at
> >> all.
> >> Section "5.6.2.  Optional Features" doesn't mention implementation at
> >> all.  It only writes about portions of a model that are conditional,
> >> supported, or valid.
> >> Section "7.20.1.  The "feature" Statement" also doesn't mention
> >> implementation, it only writes about portions of the model being
> >> conditional.
> >>
> >> So, I find the text that you are quoting as ambiguous in respect to
> >> its applicability to features.

I have to agree.  Reading the quoted text again, it is actually not
clear what it tries to say.  I did some digging, and it turns out that
the text was added very late, as a part of the Gen-ART review (see
https://mailarchive.ietf.org/arch/msg/netmod/rmt_T-lMcFm6MPoo8DwrVuZNUxA).

So what it perhaps should have said was:

    When a server implements a module containing an "augment"
    statement, that implies that if the server implements the
    augmented node, its implementation of the augmented node contains
    the additional nodes.

Also, it turns out that this text is in section 4.2.8 which is marked
as non-normative (whole section 4).

So now I am going to argue that the spec allows the case in the
original question :)

There is no normative text that says that an augment of a target node
with an if-feature statement is illegal.  If it is legal it must mean
something.  And the only reasonable interpretation is that if the
server doesn't implement the feature, then it also doesn't implement
the augmented nodes.

(I still think it is unfortunate that the "doesn't implement a
feature" case is handled differently than the "doesn't implement the
module" case)


/martin