Subject: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt

From: Benoit Claise <[email-masked]>
Date: Fri, 22 Mar 2013 18:24:57 +0100

Juergen, NETMOD participants,

Two comments

1.
For the ip-address-no-zone, ipv4-address-no-zone, and 
ipv6-address-no-zone, don't you need a reference to the zone information 
in the description?

      description
         "The ip-address-no-zone type represents an IP address without
          zone information in an IP version neutral way.  The format
          of the textual representations implies the IP version.";

Doesn't give me a pointer to what a zone information is. So I don't know 
what ip-address-no-zone is.
Note: I faced the zone issue only a year ago. Before that, I had no clue 
what it was.

2.
The section "Appendix A. Changes from RFC 6021" is pretty light:

      This version adds new type definitions to the YANG modules. For
    the further details, see the revision statement of the YANG modules.

Take it or leave it. However, I can tell that its resolution will please 
some IESG members, specifically because the rfcdiff tool doesn't do a 
good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt

Proposal

      This version adds new type definitions to the YANG modules. The
    first YANG module, ietf-yang-types adds the following new data
    types: yang-identifier, hex-string, uuid, and dotted-quad. The
    second YANG module, ietf-inet-types, adds the following new data
    types: ip-address-no-zone, ipv4-address-no-zone, and
    ipv6-address-no-zone. 

Regards, Benoit (OPS AD)

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Mar 2013 19:07:27 +0100

> Note: I faced the zone issue only a year ago. Before that, I had no clue 

Actually, I think it would be MUCH better to have "ipv4-address" with no mention of zone whatsoever, and then perhaps "ipv4-address-with-zone".

The problem with this is that it is not backwards compatible with the old revision of the module. But maybe it should be done anyway. My main concern is that an implementor will see the "ipv4-address" type and will not bother to look up the definition to realize that the client may append the zone id without breaking type validity. This could lead to nasty security holes.

And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". 

>     types: ip-address-no-zone, ipv4-address-no-zone, and

+1.

Lada
 
>
> Regards, Benoit (OPS AD)
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Mar 2013 22:03:54 +0100

> And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". 

Lada, we have been there, I believe there is no problem. And breaking
interoperability is IMHO a no go.
 
> >     types: ip-address-no-zone, ipv4-address-no-zone, and

Sure, I will do whatever pleases the IESG and other readers that do
not have the time to lookup the revision statements. ;-)

/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: Benoit Claise <[email-masked]>
Date: Fri, 22 Mar 2013 23:27:51 +0100

> interoperability is IMHO a no go.
Agreed. It's a no go
> not have the time to lookup the revision statements. ;-)
The time ... or the willingness ;-)

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 23 Mar 2013 14:00:19 +0100

>> interoperability is IMHO a no go.

OK, but I wonder - do we have any strategy for correcting mistakes in our modules? They will be typically revealed only after a module is put under stress and used in advanced data models. If breaking compatibility is a no go, then we are pretty much stuck.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Mar 2013 10:21:07 +0100

On Sat, Mar 23, 2013 at 02:00:19PM +0100, Ladislav Lhotka wrote:
> 
> OK, but I wonder - do we have any strategy for correcting mistakes
> in our modules? They will be typically revealed only after a module
> is put under stress and used in advanced data models. If breaking
> compatibility is a no go, then we are pretty much stuck.

YANG has specific rules how to make changes. This is what we follow.
In this particular case, I do not at all agree with you that there
is a mistake to correct.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Mar 2013 10:22:28 +0100

Benoit,

do you prefer to get a revised module before you do the IETF last call
or do you just want the editors to track those changes and we post a
revision at some later point during the process?

/js

On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote:
> ipv6-address-no-zone, don't you need a reference to the zone
> information in the description?
> 
>      description
> Doesn't give me a pointer to what a zone information is. So I don't
> know what ip-address-no-zone is.
> Note: I faced the zone issue only a year ago. Before that, I had no
> clue what it was.
> 
> 
> 2.
> Take it or leave it. However, I can tell that its resolution will
> please some IESG members, specifically because the rfcdiff tool
> doesn't do a good job of comparing RFC6021 with
> draft-ietf-netmod-rfc6021-bis-00.txt
> 
> Proposal
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 24 Mar 2013 17:18:29 +0100

> In this particular case, I do not at all agree with you that there

My question had nothing to do with the particular problem of IP addresses and zones, though I'd argue that ipv4-address-no-zone is at least ugly and sounds to me like beef-no-horse.

YANG change rules require strict backward compatibility. I am afraid it is counterproductive at this stage because our initial YANG modules generally get published before they have been thouroughly tested. It would be quite daring to think that our work is flawless, despite all the effort we put in it. What if we publish the routing module and then get feedback from protocol implementors or I2RS, indicating that something should be changed, and this something breaks compatibility?

I believe errors should be corrected and significant improvements implemented, and the sooner the better. It will be much harder after a module becomes widely used.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Mar 2013 20:07:24 +0100

> I believe errors should be corrected and significant improvements implemented, and the sooner the better. It will be much harder after a module becomes widely used.

If something is seriously flawed, it can be deprecated or even made
historic and you start a second attempt. All this is possible.
Changing the semantics of an existing published definition is
generally a no go.

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Mar 2013 10:19:14 +0100

Hi Juergen,

Please publish a new version, and the WG agrees on the solution.

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Mar 2013 11:47:05 +0100

> historic and you start a second attempt. All this is possible.

This all too heavy-weight, so we shall be forced to various kludges and workarounds instead, and the elegance and readability of the modules will suffer from this cruft. The *-no-zone types are an example.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Mar 2013 15:31:19 +0100

On Mon, Mar 25, 2013 at 11:47:05AM +0100, Ladislav Lhotka wrote:

> This all too heavy-weight, so we shall be forced to various kludges
> and workarounds instead, and the elegance and readability of the
> modules will suffer from this cruft. The *-no-zone types are an
> example.

This is how the IETF works. We care about interoperability and hence
changing the semantics of published definitions is a no go.

And once again, I strongly disagree with your notion that *-no-zone
types are 'kludges'.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Mar 2013 18:27:47 +0100

Hi,

I have posted a new I-D that addresses your comments (I hope).

I also fixed the quoting bug reported by Jernej Tuljak
<[email-masked]> on the mailing list on 2013-02-24.

The diff is already available here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6021-bis-01.txt

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Mar 2013 00:37:28 +0100

> Please publish a new version, and the WG agrees on the solution.
Typo: Please publish a new version _once _the WG agrees on the solution.
I should really start re-reading my emails before sending. That will be 
my resolution next year ;-)

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Mar 2013 00:38:24 +0100

Hi Juergen,
> I have posted a new I-D that addresses your comments (I hope).
Yes, thank you.

Regards, Benoit