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

[Juergen Schoenwaelder <[e-mail]>]

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.

/js

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