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

[Juergen Schoenwaelder <[e-mail]>]

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.
 
> 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.

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.
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.

/js

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