Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204)

[Ladislav Lhotka <[e-mail]>]

On Jan 21, 2013, at 4:29 PM, Juergen Schoenwaelder <[e-mail]> wrote:

> On Mon, Jan 21, 2013 at 03:51:06PM +0100, Ladislav Lhotka wrote:
>> 
>> On Jan 21, 2013, at 2:39 PM, Juergen Schoenwaelder <[e-mail]> wrote:
>> 
>>> On Mon, Jan 21, 2013 at 02:28:43PM +0100, Ladislav Lhotka wrote:
>>>> Hi,
>>>> 
>>>> I support moving this document forward, with two comments:
>>>> 
>>>> 1. The second pattern for "yang-identifier" type can be slightly optimized:
>>>> 
>>>> OLD
>>>> 
>>>>   pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
>>>> 
>>>> NEW
>>>> 
>>>>   pattern '..?|[^xX].*|.[^mM].*|..[^lL].*';
>>> 
>>> Not sure what the metric is that is optimized here or how to choose
>>> between the two.
>> 
>> The metric is string length and the number of alternatives.
> 
> Well...
> 
>>> 
>>>> 2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I suspect that many implementers will not bother to look up the definition when seeing a type like 'ipv4-address' and assume a plain IPv4 address in that place. Such a mistake can easily create a security hole. The name 'ipv[46]-address-with-zone' makes the optional presence of a zone index explicit and eliminates this potential trap. Besides, it would also better fit the naming scheme of corresponding textual conventions in RFC 4001.
>>> 
>>> It is still an incompatible change. We can't change 'ipv[46]-address'.
>>> We can deprecate it and provide a replacement.
>> 
>> This is not an option in this case - we can't deprecate a typedef such as "ipv4-address" and introduce a new one with the same name. 
> 
> I did not say same name...
> 
>>> 
>>> Personally, I do not think this is needed or desirable. The IPv6 WG
>>> just reached concensus to allow zone indexes in URIs and there was no
>>> a concern that this creates a security hole as far as I understand.
>> 
>> In URIs, IP addresses (with or without zone indices) are enclosed in brackets. In our case, the zone index is an arbitrarily long suffix without any delimiters.
> 
> How is that different?
> 
>>> What might happen is that people forget to implement support for
>>> addresses including a zoneid. That said, for stuff sitting above the
>>> IP layer, having zones included 'by default' is in my view a feature
>>> and not a bug.
>> 
>> OK, let me just mention that both I and Martin already fell into that trap, and so did the authors of the dnsccm module, I think:
>> 
>> http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dnsccm/dnsccm.in.yang
>> 
> 
> I can't judge where they did fall into a trap. Perhaps they got things
> right - I really can't judge.
> 
> Anyway, please make an actionable concrete proposal if you want. I do
> not think we are going to break YANG update rules for this. Hence your
> initial proposal does not seem actionable.

If there is nobody else who thinks it might be a problem, let's keep the current typedefs.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

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