Re: [netmod] document organization

Ladislav Lhotka <lhotka@nic.cz> Wed, 15 November 2017 13:41 UTC

Return-Path: <lhotka@nic.cz>
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 9CD2E126579 for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 05:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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, 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 IsKY0PvJgbT6 for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 05:41:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 321DD124B17 for <netmod@ietf.org>; Wed, 15 Nov 2017 05:41:27 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id D56AD6445D; Wed, 15 Nov 2017 14:41:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510753285; bh=7M9KFH8Gv5e04hYAXpXldSwKLktO62Ofa7kPtOef1rE=; h=From:To:Date; b=E6vKTGX+zbwXOhioUlbrTzYFAMl8geoSUM2O6kFPZ+4MtzoOXlyuR+nav99ipHDyB lv+4sOM8irhJ44e6x+JIepN+rRU5PD/jkE+4Y9E6aOrjXl/oUwPjqUDgDn449j6xZY nsfcTKPwOBiZjL9/HW+LLIXjf45RmjGY+UkgYdS8=
Message-ID: <1510753352.21877.51.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Date: Wed, 15 Nov 2017 21:42:32 +0800
In-Reply-To: <20171115.131446.662734976962171507.mbj@tail-f.com>
References: <1510726990.12151.10.camel@nic.cz> <20171115.131446.662734976962171507.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2
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/netmod/Hes4VqHC9xMnjqzQWSRmUx2XZfk>
Subject: Re: [netmod] document organization
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 Nov 2017 13:41:30 -0000

On Wed, 2017-11-15 at 13:14 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> > 
> > regarding my proposed reorganization of documents: I strongly disagree with
> > Martin's comment on jabber that it would be a mere split of the contents into
> > two documents. It is certainly not true because
> > 
> > - we could get rid of the use-schema/inline choice in schema-mounts data: the
> > inline case needs to state data in the parent tree at all
> 
> If this was the case, we could remove 'inline' even today from this
> choice.  But we can't do that unless we don't use an extension also
> for "use-schema", which I know you want to get rid of, but the WG
> wants to keep.

The WG should then give me a single technical reason why the "mount-point"
extension is superior to using a schema node identifier, as we do in augments.

The argument that it permits the data modeller to restrict the locations where
schema mount can add nodes is actually a red herring - such nodes can be added
even to containers and lists that are not labelled with "mount-point":

module foo {
    ...
    container bar {
        // no "yangmnt:mount-point" here
        ...
    }

This simple augmenting module then does the trick, at the expense of one extra
container "root":

module baz {
    ...
    augment "/foo:bar" {
        container root {
            yangmnt:mount-point unwanted-children;
        }
    }
}


> 
> > - there are many CLRs that are relevant only to one of the methods, so have to
> > distinguish the cases in the text; for example, parent-references don't apply to
> > "inline"
> 
> Correct.  OTOH with two documents you probably need additional text to
> explain the relationship between them.

Not really, because there needn't in fact be any relationship whatsoever. Both
methods could still be used together but they would be explained separately.

> 
> > - (most important for me) the two methods are really two different mechanisms,
> > and the "inline" method invites various instance-related considerations whereas
> > "use-schema" doesn't; it's been my experience that people keep confusing schema
> > construction and instance data mounting.
> 
> "inline" doesn't imply instance data mounting.  Our implementation
> uses "inline" w/o instance data mounting.

Well, the embedded YANG library that describes the mounted schema is part of
instance data, so it has to be added either from elsewhere or later at run time.
If it was there from the start and wouldn't change, then there is no reason to
do it this way and one can apply the "use-schema" method.

Lada

> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67