YANG Schema Mount
draft-ietf-netmod-schema-mount-12

[Ballot comment]
Section 3.3.

I think it would be nice to have some examples to illustrate the differences between inline and shared-schema and some guidance to pick between the two.

[Ballot comment]
Thanks to all contributors to this document for the work they invested.
I have a handful of relatively minor comments.

---------------------------------------------------------------------------

ID Nits reports:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

---------------------------------------------------------------------------

§1:

>  Server implementors are only required to specify
>  all YANG modules comprising the data model...

Although sources differ on the use of "comprising" in this fashion, RFC 7322 §1
defers matters of style to the Chicago Manual of Style, which specifies the
following:

  comprise; compose. Use these with care.  To comprise is “to be made up of,
    to include” {the whole comprises the parts}.  To compose is “to make up,
    to form the substance of something” {the parts compose the whole}.  The
    phrase “comprised of,” though increasingly common, is poor usage. Instead,
    use “composed of” or “consisting of.”

By my understanding, and using the definitions above, the data model
comprises the YANG modules, and the YANG modules compose the data model.

I would suggest the following revision:

  Server implementors are only required to specify
  all YANG modules included in the data model...

---------------------------------------------------------------------------

§2.1:

>  Tree diagrams used in this document follow the notation defined in
>  [RFC8340]

I think this means that RFC 8340 needs to be normative rather than informative.

---------------------------------------------------------------------------

§2.2:

>  | yanglib | ietf-yang-library      | [RFC7895],                    |
>  |        |                        | [I-D.ietf-netconf-rfc7895bis]  |

I think you want to remove RFC 7985 from this list of references. According to
draft-ietf-netconf-rfc7895bis:

  This document takes over this registration entry made by RFC 7895.

This seems to indicate that, upon publication of
draft-ietf-netconf-rfc7895bis, the YANG module name "ietf-yang-library" would no
longer be associated with RFC 7895 at all.

I don't have a strong opinion about how this discrepancy is resolved, but I do
strongly believe that this document and draft-ietf-netconf-rfc7895bis need to be
consistent with each other.

---------------------------------------------------------------------------

Page 13:

>      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
>      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
>      'OPTIONAL' in the module text are to be interpreted as described
>      in RFC 2119 (https://tools.ietf.org/html/rfc2119).

It seems that this language could benefit from RFC 8174's clarified boilerplate.

[Ballot comment]
Substantive:

§3.3, 4th paragraph: The MUST NOT seems like a statement of fact -- if no schema is mounted, it doesn't seem possible for it to include anything.

§5, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever make sense to violate this?

§9: The model includes RFC 2119 boilerplate, but the document itself uses the newer RFC 8174 boilerplate. Is it normal to include the normative keyword boilerplate in the model? If so, it should probably match that of the containing document.

Editorial:

§1, list item 2: "... and is stable as YANG library information of the server."
Assuming you mean specific YANG library information rather than the general concept, there is a missing article before "YANG". (This pattern repeats a few time throughout the document.)

[Ballot comment]
I really like that you've provided this capability.

It might be that I've spent too much time doing Unix, but I wonder if "Yang Schema Mount Point" would be a clearer title?

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3506



DETAIL
S 4.
> 
>      It is worth emphasizing that the nodes specified in
>      "parent-reference" leaf-list are available in the mounted schema only
>      for XPath evaluations.  In particular, they cannot be accessed there
>      via network management protocols such as NETCONF [RFC6241] or
>      RESTCONF [RFC8040].

What are the security implications of this XPath reference outside the
mount jail? Specifically, how does it interact with the access control
for the enclosing module.

[Ballot comment]
Whenever we introduce a new namespace "sub-hierarchy" there is some level
of risk about surpirses with respect to the security properties of the
combined system.  I appreciate that the mounted schemas are "jailed" into
their own subtree except for the specific exceptions for XPath access,
which helps a lot.  But there may still be potential for surprise with
respect to, e.g., access control on mounted schemas, if an administrator
previously assumed that such controls would only be needed at the
top-level.  The document itself doesn't give me a great picture of to what
extent these risks and the possible consequences of the new nested
structure have been considered; I'd be happy to hear if they've been
thought about a lot already and the conclusion was that the situation is so
boring that nothing needs to be mentioned in the document.

Section 3.3

  If multiple mount points with the same name are defined in the same
  module - either directly or because the mount point is defined in a
  grouping and the grouping is used multiple times - then the
  corresponding "mount-point" entry applies equally to all such mount
  points.

Does this mean that the multiple mount points must serve the same
data/contents, or just that they must use the same schema?
(Is this related to "inline" vs. "shared-schema"?)

Section 3.4

So this means that there can be multiple
ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
locations in the hierarchy?  When I was first reading the document, the
design seemed fairly clean with just a single list of mount-points at the
"top-level" that tracks everything, but this kind of recursion seems like
it would make implementation potentially quite complex.  What kind of
implementation experience do we have that can replace my half-informed
suppositions about complexity?

Section 4

  Therefore, schema mount also allows for such references.  For every
  mount point in the "shared-schema" case, it is possible to specify a
  leaf-list named "parent-reference" that contains zero or more XPath
  1.0 expressions.  [...]

editorial: """the "shared-schema" case""" reads oddly to me; it might be
clearer to refer to schemas mounted using "shared-schema" instead.  As in,
"""For every mount point under "shared-schema", [...]"""

Can we get a reference added for XPath?

It's still a little unclear to me exactly how a node in the mounted tree
constructs an XPath expression to refer to the parent-reference nodes, but
I did not read very far down the reference chain and maybe this is going to
be clear to a practitioner without any more text in the document.
Basically, do I need to know where I am mounted in order to construct
references to nodes in the parent?

Section 7

NACM "can be used" to control access to mounted nodes.  Is there a risk
that administrators will be "unpleasantly surprised" by mounted nodes by
default not receiving access control, in cases when access control is
already configured at the top level?

Section 9

Should the top-level module description be using the RFC 8174 boilerplate
instead of thet 2119 boilerplate?

Should the requirement for servers that mount any schema to also mount
ietf-yang-library under the mountpoint be mentioned somewhere other than
the description for the 'inline' and 'shared-schema' containers (i.e., in
the discussion text)?

Section 11

We should probably also have some bland statement about how "the security
considerations for mounted schemas continue to apply to the nodes in the
mounted tree".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netmod-schema-mount-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-yang-schema-mount
URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-yang-schema-mount
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
Prefix: yangmnt
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for this new YANG module?

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-29):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger , Joel Jaeggli
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Schema Mount) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Schema Mount'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a mechanism to add the schema trees defined by
  a set of YANG modules onto a mount point defined in the schema tree
  in some YANG module.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document requests the status of proposed standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines a mechanism to add the schema trees defined by
  a set of YANG modules onto a mount point defined in the schema tree
  in some YANG module.

Working Group Summary

Draft-08 of Schema mount was polled for WG consensus on Nov 7 2017.
While consensus was rough it seemed at the time sufficient to proceed.
subsequent discussion while producing 09 to address WGLC concerns
revealed signficant divisions on whether to include  support for YL-bis,
as well as how to address NMDA considerations. Work at IETF 101
produced a compromise in the form of draft 09 and 10 which the
working group appears to be substantially happier with.

We believe that normative references to this document that were stable with
draft 08 should remain so.

Document Quality

Vendor support and commitment is a signficant part of needing to advance
schema mount at this time.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Joel Jaeggli is the Document Shepherd, Ignas Bogdonas is the responsible
Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shardherd has preformed a review of all versions from 08-10
and believes this document is ready for IETF last call. The yang model itself
is subject to formal review methods which have been  exercised several times.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document Shepherd has the concern that the current document while
quite mature represents a recent compromise. While it has substantially
more support than previously it is nonetheless a newer document. Because
documents currently in the RFC editor queue or in various forms of
publication state depend on this document it needs to reviewed in light of
those dependencies. see:

https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/referencedby/

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Yes, we are hopeful that IETF last call will offer the opportunity for
participants outside of netmod with dependencies on this document
to weigh in on the suitability of the final version to their needs,

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns are present with draft 10.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR confirmation was performed with the WG and Authors with each WGLC.

The shepherd is not aware of any IPR claims on the document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Draft-10 has an appreciably better wg consensus then draft-08.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals are immediately anticipated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

IDNITS checks are clean for this document. the wierd spacing noted is ascii-
art for the datamodel.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The yang doctors have reviewed this document.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Normative references to drafts documents are present we believe that
the timeline for completion of publication will allow those documents
to be published. e.g.  draft-nmdsdt-netconf-rfc7895bis which is already
being processed by the IESG.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no Downrefs that need to be called out.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The status of other documents is not changed by this one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document registers a URI in the IETF XML registry [RFC3688].
  Following the format in RFC 3688, the following registration is
  requested to be made.

        URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount

        Registrant Contact: The IESG.

        XML: N/A, the requested URI is an XML namespace.

  This document registers a YANG module in the YANG Module Names
  registry [RFC6020].

    name:        ietf-yang-schema-mount
    namespace:  urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
    prefix:      yangmnt
    reference:  RFC XXXX


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no such registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The yang module as currently written validates via:

http://www.yangvalidator.com/

Notification list changed to "Lou Berger" <lberger@labn.net>, Kent Watsen <kwatsen@juniper.net>, Joel Jaeggli <joelja@gmail.com> from "Lou Berger" <lberger@labn.net>, Kent Watsen <kwatsen@juniper.net>