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
On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <[email protected]> wrote:
> On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder <
> [email protected]> wrote:
>
> On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> >
> > >
> > > I disagree that the datastore model is a protocol specific aspect. I
> > > consider datastores an architectural component binding data models and
> > > protocols together. In fact, the 'traditional' datastore model
> >
> > I would agree with this if datastores were a general concept in YANG,
> but the revised-datastores draft explicitly introduces the "intended" and
> "applied" datastores that may be irrelevant to other protocols using YANG,
> and even needn't be used in all NETCONF implementations. I wouldn't call
> this "an architectural component" of YANG.
> >
>
> An architectural component of this new management framework (that does
> not have a name). The fact that not all protocols may expose all
> datastores is IMHO not a reason that the datastore model is not an
> architectural framework.
>
> > If you are saying that it will have nontrivial impact on YANG, I would
> like to see it explained in sec. 6.3. Without this information I am quite
> reluctant to agree with the adoption.
>
> An operational state datastore has implications how one writes data
> models. It may not directly affect YANG itself but surely the usage of
> YANG.
>
> > See above - architectural aspects need to be relevant to all protocols.
>
> Yes, but relevant to all protocols does not mean every protocol needs
> to expose say all datastores. But every protocol should be clear about
> how what it exposes relates to the architectural framework.
>
>
>
> There is a "current solution" consisting of hard-wired object semantics
> (e.g., ifAdminStatus and ifOperStatus). This solution does not require
> special protocols or datastores, but it is being replaced by a generic
> solution.
>
> If the "generic" solution requires special procedures which differ on each
> protocol,
> then it might end up be worse than the hard-wired solution that works on
> every protocol.
> So I agree with Juergen that this is primarily an architectural issue.
>
>
> /js
>
>
> Andy
>
>
>
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 <0421%202003587> Campus Ring 1 | 28759
> Bremen | Germany
> Fax: +49 421 200 3103 <0421%202003103> <
> http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
> --
Cheers,
Mehmet
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
