Subject: Re: [netmod] Y45 again

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 01 Apr 2015 14:40:52 +0200

Phil Shafer <[email-masked]> writes:

> Andy Bierman writes:
>>This does not introduce any new YANG statements that are confusing to read.
>>I totally disagree that this makes the module unreadable.
>>I think it makes the changes to typedefs and groupings very easy
>>to see and understand over time.  These new names will match the
>>protocol names that are introducing a new version
>>(eg. ssh-parms, ssh2-parms, http1.1-parms, http2.0-parms)
>
> I don't think things are nearly that simple.  We're at version 17
> of draft-ietf-netmod-routing-cfg and it's not even finished.  That's
> up to 17 versions of each grouping/typedef threading together in
> the style Lada gave, which means the "last call" readers don't get
> the nice concise readable document we've been promising them.
>
> It won't take long for authors to realise that non-global grouping
> don't suffer this fate and to shift their BCP to not using our
> global groupings/typedefs facilities.
>
> That said, a module is publishing an API, a binding contract that
> shouldn't randomly change.  If we accept that groupings and typedefs
> are part of that API, then importers should able to depend on their
> not changing.

Right, this is the point I've been trying to make. If we want YANG
authors to use standard modules with typedefs/groupings, they should be
easy to read and understand. Being forced to inspect x different
versions and figure out which is the right one to use doesn't seem very
user-friendly. 

>
> On the other hand, if there groupings aren't flexible, what happens
> when you have a bug?  Can you not change it because other users
> might be relying on the broken behaviour?
>
> It's really a whole rainbox of ugly, eh?

Yes, but still: the priority ranking readers - writers - software
developers can give us some guidelines.

In my experience from programming and schema languages, systems that
require the writer of an importing module to be more explicit about his
intentions work generally better than those that try to be clever.

Lada

> Thanks,
>  Phil

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 01 Apr 2015 15:02:23 +0200

Andy Bierman <[email-masked]> writes:

> On Tue, Mar 31, 2015 at 12:41 PM, Phil Shafer <[email-masked]> wrote:
>> Andy Bierman writes:
> The change rules do not apply to Internet Drafts.  Never did.
> They only apply to published RFCs.  So if you can find
> 17 versions of any MIB or YANG definition across 17 RFCs,
> then let me know.
>
> The new names are not needed in Internet Drafts.

Well, RFC 6020 states the update rules for module revisions and these
are bumped in subsequent revisions of an I-D (which is IMO a good
thing).

Perhaps it might make sense to have a module-level statement like
"status experimental;"

But even then, promoting an I-D to RFC doesn't mean the contents are
perfect. The routing draft was close to becoming an RFC last year -
would it change anything on its quality if that had happened?
Routing protocol modules are far from being done, and work has just
begun on multicast routing. I think it is quite likely it might have
some impact on the routing module. And I really don't like the idea of
having "grouping route-content" and "grouping route-content-2" in the
same module.

Lada

> The change rules do not apply.  People break the change rules
> in sec. 10 of RFC 6020 all the time during development
> of a YANG module.  We only care about published modules.
>
>
> As I said before, the rigid change rules do not apply to bugs.
> If the intent from the start was that the foo-range be 1..20,
> but it got published as 1..10 by mistake, then changing it to 1..20
> without a name change is OK because the intent was 1 .. 20
> from the start.  We have done this several times with patterns
> in IETF typedefs.
>
>
> No, because you are wrong about how the change rules work.
>
>
>> Thanks,
>>  Phil
>
>
> Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Apr 2015 08:21:12 -0700

Hi,

Repetition is the key to learning I guess.
All the churn in Internet Drafts DOES NOT MATTER!
The change control only applies to RFC PUBLICATION.
The ietf-routing module is an example of the review process
working correctly, because it is not an RFC.
It did not "almost" become an RFC.  It it still
a work-in-progress,

The revision gets updates in I-Ds but the change control
rules get ignored.  Perhaps a YANG 1.1 stmt will make that
more clear, but it is not very important.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Apr 2015 16:58:38 +0200

> versions and figure out which is the right one to use doesn't seem very

This is actually simply. If foo.2 replaces foo.1, you mark foo.1 as
obsolete and tools will tell you that you use something that is marked
obsolete. In some cases, using what is obsolete is what you want, in
other cases you go and see whether the new definition foo.2 works for
you.

> intentions work generally better than those that try to be clever.

Exactly. This is why you write uses foo.1 or uses foo.2 instead of
just uses foo and have magic applied that figures out what foo stands
for. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Apr 2015 12:56:14 +0200

> other cases you go and see whether the new definition foo.2 works for

My main concern here is *human* readability. Inexperienced module 
authors need to scan existing modules to find typedefs and groupings 
that might be potentially useful to them. Cluttered modules won't work 
very well in this respect.

I believe most authors of new modules should be fine with the most 
recent revisions, and there is no need to expose them to all the history.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 08:52:04 -0700

On Fri, Apr 3, 2015 at 3:56 AM, Ladislav Lhotka <[email-masked]> wrote:
> My main concern here is *human* readability. Inexperienced module authors
> need to scan existing modules to find typedefs and groupings that might be
> potentially useful to them. Cluttered modules won't work very well in this
> respect.
>
> I believe most authors of new modules should be fine with the most recent
> revisions, and there is no need to expose them to all the history.
>

I am also concerned about readability.
My main concern is that readers will be forced to open and compare
several revisions of each module, and it will be extremely difficult
to determine what a given revision of each module actually contains.

IMO foo-type.1 foo-type.2 is much easier to detect as different,
rather than examining the dependency chain to see that
the foo-type is really different every place it is used.
The various typedefs and groupings will not be that different
by direct import.  Instead 2nd or 3rd layer imports will be different,
hiding the subtle changes.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 07 Apr 2015 10:04:56 +0200

> to determine what a given revision of each module actually contains.

Except for special cases, it should be sufficient to read the last
revision of each module and use what's there.

Note that nobody advocates changing typedefs and groupings in a
haphazard fashion. Changes may be needed not only due to errors but also
because of changed situation.

Lada