Sorry about the top post, but in writing the response I realized it
would be good to shift the discussion (and my position) a little.
I think the core of this/my issue is having duplication of requirements,
i.e.:
in ietf-netconf-rfc7895bis
Updates: <empty>
All NETCONF servers supporting YANG 1.1 [RFC7950 <https://tools.ietf.org/html/rfc7950>] are required to
support YANG Library (seeSection 5.6.4 of RFC 7950
<https://tools.ietf.org/html/rfc7950#section-5.6.4>). NETCONF
servers implementing the NETCONF extensions to support the NMDA
[I-D.ietf-netconf-nmda-netconf
<https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-06#ref-I-D.ietf-netconf-nmda-netconf>] MUST implement at least the version
of the YANG library defined in this document.
Similarly, all
RESTCONF servers are required to support YANG Library (seeSection 10 of RFC 8040 <https://tools.ietf.org/html/rfc8040#section-10>). RESTCONF servers implementing the RESTCONF extensions
to support the NMDA [I-D.ietf-netconf-nmda-restconf
<https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-06#ref-I-D.ietf-netconf-nmda-restconf>] MUST implement
at least the version of the YANG library defined in this document.
in ietf-netconf-nmda-netconf, related to the first part:
Updates: 6241, 7950
This document also updates [RFC7950] in order to enable NETCONF
clients to both discover which datastores are supported by the
NETCONF server, as well as determine which modules are supported in
each datastore. The update requires NETCONF servers implementing the
NMDA to support [I-D.ietf-netconf-rfc7895bis].
in ietf-netconf-nmda-restconf, related to the second part of rfc7895bis
Updates: 8040
This document updates [RFC8040] in order to enable RESTCONF clients
to discover which datastores are supported by the RESTCONF server, as
well as determine which modules are supported in each datastore and,
finally, to interact with all the datastores supported by the NMDA.
Specifically, the update introduces new datastore resources, adds a
new query parameter, and requires the usage of
[I-D.ietf-netconf-rfc7895bis] by RESTCONF servers implementing the
NMDA.
So the above is problematic in a few ways.
1. The same requirement is basically spread across multiple documents,
one or the other should contain the requirement, not both.
2. The position reflected by the current ietf-netconf-nmda-netconf text
is that it is the authoritative origination of the 7950 impacting text,
yet this text uses "require" not "REQUIRES". So this lead me to the
conclusion that rfc7895bis is the authoritative source of the update --
and my comment.
3. (not previously noted) ietf-netconf-nmda-restconf has basically the
same comment WRT 8040. It says its the source of the authoritative 8040
impacting text yet the conformance language is in is rfc7895bis
I think there are two ways to address this:
a) Keep the conformance language in rfc7895bis and note that it Updates
7950 *and* 8040. nmda-netconf and nmda-restconf would also be modified
to remove the update notation and related text.
b) move the quoted language from rfc7895bis to nmda-netconf and
nmda-restconf, and leave the updates as is
I think either work. While not what I originally suggested, I think
option 2 is a bit cleaner as it keeps the protocol related text in a
protocol document vs in a module definition document.
See below for some specific responses below.
On 8/2/2018 5:13 AM, Juergen Schoenwaelder wrote:
On Mon, Jul 30, 2018 at 04:19:41PM -0400, Lou Berger wrote:
All this means is that draft-ietf-netconf-rfc7895bis should note it updates
RFC 7950 in the header and abstract...
I think there are different interpretations what the Updates: header
means. And in this case, the "update" is even conditional, i.e., you
have to implement rfc7895bis if you do implement NMDA - but if you
don't, then rfc7895 still works just fine.
The point of the updates field is to allow someone implementing a spec
to know about other specs that impact implementation. Optional or
otherwise. It lets the implementor make an informed choice without
knowing the whole history or context of an RFC's writing. I think the
update notation belongs with the conformance language that impacts the
implementation is in this document this is where the updates belong --
wherever that ends up.
FWIW Getting these update/obsolete fields wrong really hurts those new
to the technology.
Your read of the update to RFC7950 is that it should now reference
rfc7895bis in Section 5.6.4. Is that correct? How is that different
from 7895bis obsoleting 7895, and thus all references to 7895 should
now be to 7895bis?
It is conditional to the implementation of NMDA.
I don't follow you here. but I suspect it's covered by my top post.
Lou
/js
