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

On Mar 22, 2013, at 11:27 PM, Benoit Claise <bclaise@cisco.com> wrote:

> On 22/03/2013 22:03, Juergen Schoenwaelder wrote:
>> On Fri, Mar 22, 2013 at 07:07:27PM +0100, Ladislav Lhotka wrote:
>>> Benoit Claise <bclaise@cisco.com> writes:
>>> 
>>>> 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.
>>>> 
>>> 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".
>> Lada, we have been there, I believe there is no problem. And breaking
>> interoperability is IMHO a no go.
> Agreed. It's 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

>>  
>>>> 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.
>>> +1.
>>> 
>>> Lada
>>>  
>> Sure, I will do whatever pleases the IESG and other readers that do
>> not have the time to lookup the revision statements. ;-)
> The time ... or the willingness ;-)
> 
> Regards, Benoit
>> 
>> /js
>> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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