Re: [netmod] IETF91 NETMOD agenda ?

----- Original Message -----
From: "Ladislav Lhotka" <lhotka@nic.cz>
To: "Andy Bierman" <andy@yumaworks.com>; "Benoit Claise"
<bclaise@cisco.com>
Cc: <netmod@ietf.org>; <rtg-ads@tools.ietf.org>
Sent: Wednesday, November 05, 2014 8:40 AM
Subject: Re: [netmod] IETF91 NETMOD agenda ?

> Hi,
>
> I agree with Andy. I think we already have a LOT to do with the
existing
> WG items, and YANG 1.1 in particular, and we should devote most of the
> WG meeting time to them.

Disagree

What you do now with YANG 1.1 will not hit the streets for a while; the
charter says submit to the IESG in March 2015 and I have never known
something like this be early.  And then it will be a while before the
implementations catch up and then more before the designers of models
get there.

Benoit just listed some 70 YANG I-Ds and it is safe to assume that
within those will be many misunderstandings, bad design choices and
plain errors, and once they make it into RFC, they will be with us for
years, if not decades, reminding us of how not to do things.

The priority here and now should be

> 2. Get advice about YANG-related aspects.

in the shape of guidelines (or advice to the YANG Directorate) of what
to do and how to do it.  Even if the Directorate do pick up the worst
practices, it would be still more productive for them not to be made in
the first place, by the protocol experts in the other WGs who are
writing the models.

Yes, YANG 1.1 will fix or forestall some of this but for most, it will
be too late.

I speak from a few decades of experience with SNMP (a much simpler data
modelling language:-).

Tom Petch
                                                     Offloading this
work to interim telcos is IMO
> not good.
>
> In my view, authors of new YANG modules face three challenges:
>
> 1. Organize a group of domain experts to work on the substance of the
> module (scope, configuration logic, dealing with the legacy of
existing
> CLIs etc.).
>
> 2. Get advice about YANG-related aspects.
>
> 3. Find a home for the module so that it can eventually become an RFC.
>
> For the most part, #1 and #3 should be done outside NETMOD in an
> appropriate IETF area. It involves convincing domain experts that the
> work is worth doing in the first place, and then find enough support
and
> capacity to carry it out. But this is I guess IETF business as
> usual. NETMOD WG cannot act as a shortcut for this hard part. And
> judging from the recently announced guidelines, I think the routing
area
> got it pretty much right.
>
> There might be modules that need to be done in the NETMOD WG, e.g. if
> they span multiple areas, but they should be an exception.
>
> As for #2, I think it is a task for YANG doctors. In this case, I'd be
> willing to accept stricter rules and more deterministic workflow so
that
> module autors receive feedback in a timely manner.
>
> Lada
>
> Andy Bierman <andy@yumaworks.com> writes:
>
> >>
> >
> > It is not NIMBY. The YANG experts are not all SYSLOG experts.
> > Getting the right people in the room is important (you said that ;-)
> > Making a few SYSLOG experts sit through 140 minutes of
> > unrelated material may not be the best option for them either.
> >
> > It is unfortunate that the SYSLOG WG has decided the protocol
> > is complete and no further work is needed.  I don't agree IETF
> > process should be a good reason to choose NETMOD WG.
> > This draft is already chartered and I am not trying to stop
> > the SYSLOG work.  I don't want it to start a trend though.
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod