Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Apr 2010 10:00:03 +0200

Copying the netmod crowd. 

Is there any reason for the two representations to be different or to
prefer one to the other? 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Peter Saint-Andre
> Sent: Thursday, April 22, 2010 6:42 AM
> To: David Harrington
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd
> 
> On 4/21/10 9:26 PM, David Harrington wrote:
> > The WG spent a number of iterations and a lot of analysis 
> to get this 
> > right.
> > I would hesitate to modify it now, without going back to read the 
> > threads that discussed it before.
> 
> OK.
> 
> I note in passing that draft-ietf-netmod-yang-types 
> (currently also under review by the IESG) provides a 
> different regexp for IPv4 address:
> 
> (([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?[0-9]?[0-
> 9]|2[0-4][0-9]|25[0-5])
> 
> It would be nice to have a consistent definition that we 
> could re-use in IETF specifications...
> 
> /psa
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Apr 2010 11:30:52 +0200

> Is there any reason for the two representations to be different or to

There are two issues here we need to separate:

First, the ipv4-address (yang-types) supports zone indexes which the
ip-address (smi-datatypes) does not support since it sticks to the
value range of the SMIv2 IpAddress type. This difference is on
purpose.

Second, the pattern for the IPv4 address portion is different. They
were the same until January/February this year. Lada wrote a comment
that some patterns are unnecessarily complex:

  http://www.ietf.org/mail-archive/web/netmod/current/msg04997.html

I tried to address this by making the pattern shorter:

  http://www.ietf.org/mail-archive/web/netmod/current/msg04998.html

Now, looking at these two pattern again with fresh eyes, I see that
the ipv4-address (yang-types) pattern does allow leading zeros, which
I think it should not. So I think by addressing Lada's comment, we
introduced a bug (which is then also carried over to ipv4-prefix).

So far the explanation what happened. (And my set of test cases did
not catch the leading zeros.)

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Apr 2010 12:04:37 +0200

> not catch the leading zeros.)

And here is a pattern that is reasonably short, relatively easy to
understand (I hope) and hopefully does the right thing (remove the
last line to omit the zone index part):

        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
      + '(%[\p{N}\p{L}]+)?'

Attached is a python collection of test cases. Feel free to add test
cases in an attempt to prove the pattern wrong...

/js

---

From: Mark Ellison <[email-masked]>
Date: Thu, 22 Apr 2010 10:42:27 -0400

Hi,

As one of the authors and not an expert in regular expressions, I am glad
that Peter brought the IPv4 pattern issue to our attention.

I think it would be a good thing to use the same pattern for the IPv4
address regular expression (without the zone portion) in
draft-ietf-ipsawg-smi-datatypes-in-xsd as in draft-ietf-netmod-yang-types.

If there are any regular expression experts able to verify the accuracy of
the pattern provided below by Juergen it would be appreciated very much.

I am in favor of updating the smi-datatypes-in-xsd draft to include the
improved IPv4 pattern.

Regards,

Mark

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Apr 2010 10:23:18 -0600

On 4/22/10 8:42 AM, Mark Ellison wrote:
> Hi,
> 
> As one of the authors and not an expert in regular expressions, I am
> glad that Peter brought the IPv4 pattern issue to our attention.
> 

Agreed.

> If there are any regular expression experts able to verify the accuracy
> of the pattern provided below by Juergen it would be appreciated very much.

We could ask on the [email-masked] list. :)