*[Sorry for reposting. Gmail client seems to add some confusing
quotations.]*
Hi All,
I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt
and finalize the DT draft in NETMOD WG, which I still support.
I believe the bigger issue is to agree on a plan concerning the related
work and the re-organization of existing standards. As a matter of fact
this plan will lead to updating the charter of two WGs and the work we are
going to start.
I see the DT document as a datastore solution proposal. There are different
gaps and issues which still need to be addressed and the solution proposal
needs yet to be discussed and finalized. The document is providing
information on the history, explaining the need for a generic solution as
well as is discussing different scenarios. As such I believe the datastore
solution proposal from the DT should be published with the intended status
Informational RFC.
Based on the finalized and agreed datastore solution we should do different
updates to existing documents in NETCONF and NETMOD WGs. With this action
we can also fix well-known issues.
Concerning the NETCONF WG I would see it as valuable if we develop:
- a RFC6241bis draft removing the current datasore concept specification,
and getting rid of well-known issues e.g. with the <get> operation,
- a new protocol- and language-independent standard document (RFC XYZ)
defining the generic datastore concept and framework and describing its use
(based on and following the DT solution draft),
- adding potential extensions to RFC6241bis (following the DT draft and
with a normative reference to RFC XYZ),
- adding potential extensions to a RESTCONF-bis RFC (following the DT draft
and with a normative reference to RFC XYZ),
Concerning the NETMOD WG I would see it as valuable if we develop:
- RFC7950bis deleting protocol-dependent details and specifying the
datastore usage with YANG on a generic level (with a normative reference to
RFC XYZ),
- adding potential extensions to RFC7950bis, e.g. concerning the proposed
<notification> element,
- possibly an RFC 6244bis to describe architectural aspects. However
RFC6244 is Informational and a RFC6244bis would be still Informational. I'm
not sure whether this is really necessary. The DT proposal does already
describe such a solution and can be seen as an update to RFC 6244.
- RFC6087bis giving guidelines on how to use YANG with the new datastore
concept.
Referring to Lada's proposal concerning the spin off document from RFC7950
("Adapting NETCONF for use with YANG"),
I think this can be provided in the corresponding protocol RFCs, i.e.
for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and for
RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
Hope this helps as a starting point on the way to a good plan.
PS: As Benoit suggested some time ago we might also consider to rename
NETCONF WG as it is not only on NETCONF protocol anymore.
Regards,
Mehmet
--
Cheers,
Mehmet
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
