On 15/09/2017 16:23, Andy Bierman wrote:
Hi,
So are you saying the NMDA transition strategy should be ignored?
My personal preference for the routing modules would be to keep the same
module name and deprecate the old nodes.
However, I doubt that there are many implementations of this 8022 yet,
and if the authors prefer to use a new namespace without the old nodes
then I'm fine with that also. Are you opposed to this approach?
E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
probably much more widely implemented then I think that the modules
should be updated in place with the existing state tree deprecated. I.e.
I support what Martin has done in his IDs, and don't want this to change.
What is the problem with deprecated nodes?
Nothing really, but I guess that they are likely to be baggage that is
going to be around for a long time even if very few people ever
implement the deprecated nodes.
Why aren't you following your own transition strategy?
Really because I'm not an author, both solutions seem valid, and I
actually think just reaching a conclusion quickly is more important than
which particular solution is chosen. I don't see any advantage is
pushing back the adoption call - it seems like it will probably just
delay when we can do WG LC.
I actually think that the bigger question that needs to be resolved is
whether we need an optional extension to mark a module as NMDA
compatible, or for the extra NMDA state module, as I think that both you
and Tom have been asking for.
Thanks,
Rob
Andy
On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
On 15/09/2017 15:52, Acee Lindem (acee) wrote:
Hi,
With respect to WG adoption, we will do whatever the WG
decides for the
RFC 8022 model. We have a strong preference toward not
carrying the
deprecated nodes forward and new module versions appears to be
a good way
to achieve this.
Can we not adopt regardless? We know that we are going to bis
8022, and having an adopted draft gives it a bit more legitimacy
and helps other folks to migrate.
Or perhaps we can start the call for adoption and continue to try
and resolve this issue at the same time ;-). I think that it
would be good to try and get the updated model drafts to WG LC by
Singapore.
I know that it hasn't been asked yet, but I support adoption of
any 8022 bis draft that (i) provides the correct NDMA combined
tree (ii) removes or deprecates the old state nodes :-)
Sorry, if I'm being pushy :-)
Rob
I agree with Lada that deprecating all the schema nodes is
unnecessary.
However, we’ll do what it takes to reach consensus and satisfy
the most
pedantic among us.
Thanks,
Acee
On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
<[email protected] <mailto:[email protected]> on
behalf of [email protected] <mailto:[email protected]>> wrote:
Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
rfc8022bis-02 signals the intent to ditch the
current/soon-to-be-legacy
module, but does it actually say it? (I can't find it)
The modules contained therein have different names and
namespaces, so
there is
no formal ancestry. I would prefer to keep the modules
from RFC 8022 as
they are
- some weirdos may still want to use them.
The draft does say that it obsoletes 8022, but I'm
unsure if that's
going to
have a meaningful impact in the wild. I think Juergen
said they had
this
issue with MIB2 and only after a couple years of
misuse did they
republish the
legacy MIBs with deprecated status.
I'm okay with this change being made after adoption,
so long as there's
general agreement to do it. Are the authors okay with
it, or are there
any
better suggestions?
PS: Sadly, the 'module' statement does not have
'status' as a
substatement [I
just added this omission to the yang-next tracker]. I
think the only
way to
"deprecate a module" is to instead deprecate the all the
nodes/rpcs/notifications in the module. Kind of ugly,
but it's for a
deprecated module, so who care, right? ;)
I think it is unnecessary. If somebody needs adding such a
module to the
data
model, he/she should probably have a reason to do so, such
as data
implemented
on the server.
Lada
Kent
--
Hi Rob,
On 9/14/2017 9:37 AM, Robert Wilton wrote:
Hi Kent & Lou,
When do you think that it will be possible to
start the adoption
process
on these drafts?
I think that the first two at least would seem to
be ready for
adoption. For the 3rd draft, there still seems to
be an open
question
of what to do with the old state tree, but
presumably that could be
solved after the draft has been adopted?
I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02
<https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02>)
that
clarifies the intent is to replace the current
modules, and presumably
obsolete 8022. And now that this intended direction
is clear in the
draft we could poll it.
I think this still doesn't address if we need to
indicate that the
rfc8022 defined modules are deprecated by some other
mechanisms than
just replacing the RFC, e.g., by updating the old
modules with all nodes
marked as deprecated. I think you're right that this
could be done post
adoption. Of course others are free to disagree.
I check with Kent and see what he thinks.
Thanks,
Lou
Thanks,
Rob
On 30/08/2017 00:46, Kent Watsen wrote:
Hey folks,
As discussed at the last meeting, we are
heading to revising
existing RFCs
to align them with NMDA. The first batch have
been published as
individual drafts:
1.
https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
<https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00>
2.
https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
<https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00>
3.
https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
<https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00>
Please take a look (comments welcome!) and
stay tuned for the
related
adoption calls.
Thanks,
Kent (and Lou)
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
.
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
