Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 May 2013 09:41:57 +0200

On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote:
> One meta-comment.  I don't consider the contents of RFC 6021 to have
> any bearing on the review of this document.  I'm not familiar with
> 6021, so I consider all of this to be new.

But most of the definitions are not new and I am reluctant to make
changes to published RFC text.

[...]

> > ipv6 pattern
> > Note sure what the "official" ABNF definition is but we believe that
> > the two pattern are correct. So far nobody was able to find a case
> > that was not properly accepted by the pattern. You are welcome to try
> > to find something where our two pattern break. ;-)
> 
> Sorry, "official" is my shorthand for saying: there is an RFC out
> there that defines this ABNF but I was too lazy to go and look for it
> because I know that chances are I will find the wrong one.
> 
> The first pattern is overly restrictive, I think (only double colon at
> the start?).  The second is definitely overly permissive.
> This:sentence:is::actually:valid.  (I think).

Please give me an example of an IPv6 address that the ipv6-address
pattern does not handle so we have something concrete to talk about. I
am appending some test cases to make it easier for you to find one.

If you mean by "second" the ipv6-address-no-zone typedef, please see
my response to Joel. This is a type derived from ipv6-address.

/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: Martin Thomson <[email-masked]>
Date: Thu, 2 May 2013 13:28:46 -0700

> changes to published RFC text.

I thought that was the purpose of revising an RFC.  If you were just
looking to add types, an update might be more appropriate.

> my response to Joel. This is a type derived from ipv6-address.

Ahh, both patterns apply.  My mistake; I had assumed OR (like XML
schema), not AND.  Interesting approach.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 May 2013 10:16:08 +0200

> looking to add types, an update might be more appropriate.

The new types go into existing YANG module and this requires to
republish the whole module. This is what we have been doing >20 years
for MIB modules - so there is experience with this.
 
> schema), not AND.  Interesting approach.

In XML schema, you have both:

   If multiple <pattern> element information items appear as
   [children] of a <simpleType>, the [value]s should be combined as if
   they appeared in a single ·regular expression· as separate
   ·branch·es.  Note: It is a consequence of the schema representation
   constraint Multiple patterns (§4.3.4.3) and of the rules for
   ·restriction· that ·pattern· facets specified on the same step in a
   type derivation are ORed together, while ·pattern· facets specified
   on different steps of a type derivation are ANDed together.

I believe YANG is actually following XML schema here.

/js