[netmod] schema mount situation and next steps

Benoit Claise <bclaise@cisco.com> Sat, 17 March 2018 23:13 UTC

Return-Path: <bclaise@cisco.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 EE83B12D87F for <netmod@ietfa.amsl.com>; Sat, 17 Mar 2018 16:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 HLomZzJ9TanE for <netmod@ietfa.amsl.com>; Sat, 17 Mar 2018 16:13:33 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EE012426E for <netmod@ietf.org>; Sat, 17 Mar 2018 16:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8281; q=dns/txt; s=iport; t=1521328412; x=1522538012; h=to:from:subject:message-id:date:mime-version; bh=/VLU8ZMbDz7jqaO5K9DF57oae0j424kpVVqbGOCacz8=; b=HRuD3cTZiB3cFdi8UReNX5z8oMmkCwlIvwz6lGwdBTdbx6XLIpft84qX +zKLO/ZBnO5qbHxvEjBG/XdAXj1KxZy9/j7/7UONIkOzZcAgXYs0Rqg96 lk3I/02kmjtoMLu/BR51gAby3MOCwBTpT74zPtuTJDe1HaxXtQNz80AJG I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqCAAkoK1a/xbLJq1dGgEBAQEBAgEBAQEIAQEBAYQ2ciiDXYoacoxRAYIDC4EkG45xhQ8UgX4LI4QghCU0GAECAQEBAQEBAmsohU+BMwJTDA0IAQEXhH0PqxaCJiaESINmggkFhTODaoFTASgMgWRVgnNeAgGBLQQUAQGDJoJhA5g2CY8qB4gZhRSKfIU5gSoeOIFSMxoIGxU6gkOQa0A0AY1lgjoBAQE
X-IronPort-AV: E=Sophos;i="5.48,322,1517875200"; d="scan'208,217";a="2671306"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2018 23:13:29 +0000
Received: from [10.61.211.207] ([10.61.211.207]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w2HNDSZF012236 for <netmod@ietf.org>; Sat, 17 Mar 2018 23:13:29 GMT
To: NETMOD Working Group <netmod@ietf.org>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <51a75ec9-0821-d28b-ac81-8bede95b838d@cisco.com>
Date: Sat, 17 Mar 2018 23:13:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------CB7E6A37025F38D89F9BEFE4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/r_SBZvqtQt8nZ3orpZb5WnqTnKI>
Subject: [netmod] schema mount situation and next steps
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: Sat, 17 Mar 2018 23:13:35 -0000

Dear all,

In the last two weeks, I've been multiplying the schema mount discussions.
It's now time to draw the conclusions and to move on.

I'm sad that schema-mount is not NMDA compliant. We approved RFC6087bis 
with the NMDA transition guidelines.
I'm sad that progression to IETF-LC has not been completed on the 
schema-mount document since the WGLC in November.

As discussed with the document shepherd Joel, there is not a strong 
support position for the schema mount document (version 08), but rough 
consensus. The interaction with YANG library bis has been noted during 
the WGLC. What happened since that WGLC closure on Nov6th is that the 
people position became tougher and that multiple possible tracks have 
been investigated. I believe we heard the arguments from everybody.

Taking my AD responsibilities, what's next?

1. We have been losing so much time (which I regret) since the WGLC that 
publishing 08 now makes sense, solving one aspect of the problem: the 
situation where the set of YANG modules is the same in all datastores. 
Is this perfect solution? Certainly not.
The LNE and NI documents, in the RFC editor queue, depend on the version 
8 of schema mount.
So let's pursue that publication path.

2. The document 08 should be edited before requesting the publication.
- The draft should be clearly specified that this solution is not fully 
NMDA complaint. For example, in the abstract
- The draft should mention an applicability statement, such as the one 
the chairs proposed:

    This work was produced during the period when NMDA solutions were being
    developed in parallel. While the model defined in this document can be
    used with both NMDA and non-NMDA supporting implementations, there are
    limitations in its NMDA applicability. When used with Yang Library
    [RFC7895] only non-NMDA implementations can be supported. When used with
    the revised Yang Library defined in [I.D.ietf-netconf-rfc7895bis], NMDA
    implementations can be supported with certain limitations. Specifically,
    this document requires use of the now deprecated module-list grouping,
    and the same schema represented in schema list of ietf-schema-mount MUST
    be used in all datastores. Inline type mount points, which don't use the
    schema list, don't have this limitation as they  can support different
    schema in different datastores by instantiating the
    [I.D.ietf-netconf-rfc7895bis] version of YANG library under the inline
    mount point. A future revision of this work is expected to provide for
    full NMDA support.

- Some edits are needed: the nits from the YD review
https://www.ietf.org/mail-archive/web/netmod/current/msg19443.html
Another one, addressing one of Lada's important complaints.

    The use of mount points does not impact the nature of the mounted data
    or in which datastore information is made available. For example, the
    datastore from which YANG Library module information may be obtained is
    not impacted by the use of schema mount.  This is case for both the top
    level YANG Library module and any YANG Library modules included under a
    mount point. The Schema Mount module itself MUST be present in the same
    datastore as the YANG Library module.

Next, we want to work on a NMDA solution, based on the pre-09 version 
... I guess.
This solution will obsolete the current 08 document and reference the 
YANG library bis.

Let's dedicate the full second NETMOD session (on Wednesday) to schema 
mount and let's use our energy to focus on the best solution.

Regards, Benoit (as OPS AD)