Hi,
Adding -state modules to all new drafts seems like unnecessary
overhead. Even mentioning NMDA in a draft that has no logical
relationship to NMDA also seems like unnecessary overhead.
Not a great set of alternatives. The positive thing is that vendors that
do not have to worry about existing applications should really have no
problem responding to the pressure.
Vladimir
On 10/17/18 4:39 PM, Christian Hopps wrote:
I'll chime in as an operator here, I do not feel there is a need to support
non-NMDA implementations with this brand new work that won't be finished let
alone start being used for another so many months (at best). There's nothing
wrong with simply requiring NMDA for various modules going forward. Indeed I'd
like more modules to require NMDA if only to add pressure to get it deployed by
vendors.
Thanks,
Chris.
On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder
<[email protected]> wrote:
The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.
/js
On Wed, Oct 17, 2018 at 01:13:06PM +0000, Rohit R Ranade wrote:
Either defining a new module in an Appendix or a subtree, I am OK with either
and both of us concur that the draft needs the changes.
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email protected]]
Sent: 17 October 2018 18:18
To: Rohit R Ranade <[email protected]>
Cc: Christian Hopps <[email protected]>; [email protected]
Subject: Re: [netmod] Review comments for module-tags-02
Obviously, this is now a slightly different statement. There are NMDA
transition guidelines that have been discussed at length and finally been
integated into
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3
This section 4.23.3 says under case (a):
Both the NMDA and the non-NMDA modules SHOULD
be published in the same document, with NMDA modules in the document
main body and the non-NMDA modules in a non-normative appendix.
In other words, you do not pollute a new NMDA module with non-NMDA subtrees but
instead you create an additional module that goes into an appendix and is only
relevant for transition purposes. I think Rob created tools to generate such
things. Section 4.23.3.1 also provides some guidelines for creating temporary
non NMDA modules.
/js
On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we
will need this separate subtree to show the system defined tags.
-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email protected]]
Sent: 17 October 2018 17:22
To: Rohit R Ranade <[email protected]>
Cc: Christian Hopps <[email protected]>; [email protected]
Subject: Re: [netmod] Review comments for module-tags-02
On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
I think we need to define a subtree for non-NMDA clients to get the
operational tags.
It is not much of a change for a _client_ to read a different datastore hence I
do not think this is needed.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
