Subject: Re: [netmod] IP addresses with zone indices

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 02 Dec 2012 09:28:18 +0100

Juergen Schoenwaelder <[email-masked]> writes:

> On Fri, Nov 30, 2012 at 11:49:43AM +0100, Ladislav Lhotka wrote:
>> 
>> > 
>> > I believe the proper type for ipv4/address/ip is ipv4-address.
>> 
>> I had the impression we all agreed that zone indices are not desirable there and therefore the "ipv4-address" type won't be used for it - at least the one from "ietf-inet-types".
>>  
>
> The ipv4-address type is more generic, so you subtype it to make it
> specific to what ipv4/address/ip needs. This can very easily be done
> inline of the leaf definition. Not a big deal, get it done, move on.
>
>> > Perhaps there could be a universal dotted-quad type somewhere at
>> > sometime. But our goal right now is to finish and deliver. Having a
>> > dotted-quad pattern copied is not worth further delaying the
>> > completion of this work.
>> 
>> If it is defined in "ietf-ip", it won't create any (new) downrefs.
>
> But then it will still be in the wrong place. And ietf-ip won't 
> need this type since ipv4/address/ip is an ipv4-address (and
> ipv6/address/ip is an IPv6 address without a zone id).

This is actually not true. The "ietf-ip" draft also uses the "ipv4-address" type for the "netmask" leaf, which has both problems as "router-id": semantically, it is not an IP address, and a zone index must not be present.

Lada

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Dec 2012 11:47:18 +0100

On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote:

> Not a big deal for human readers, if they never mind the regular
> expressions, but it means a performance penalty for automatic
> validation. Given that something like 95 % IP addresses appearing
> elsewhere in configurations or state data will not use zone indices,
> I am not sure it is worth the extra cycles. Perhaps a better model
> for those places that permit zone indices would be

I do not know where your 95% are coming from. I also do not see what
the performance penalty really is in the sense that I have not seen
hard numbers. YANG was designed to allow such (inline) subtypings and
unless there is _evidence_ it is broken, I think we should be fine
using it.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Dec 2012 12:05:42 +0100

> I do not know where your 95% are coming from. I also do not see what

Zone indices are used in routes with destination prefixes based on link-local addresses. In my experience, these are pretty rare. Are there any other uses?

Maybe 95 % is still too low.

Anyway, by including support for these corner cases in the essential "ipv4-address" type, every use of this type is forced to check for the presence of a zone index. Implementors who forget about this (I and Martin also did, right?) will open security holes for attackers.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Dec 2012 16:15:50 +0100

> Anyway, by including support for these corner cases in the essential "ipv4-address" type, every use of this type is forced to check for the presence of a zone index. Implementors who forget about t…

Our goal is to finish up the interfaces/ip/routing documents and there
seems to be a simple solution to get this done with what we have. If
you want to make proposals for 6021bis, please feel free to do so but
mark such proposals clearly as that.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Dec 2012 17:24:59 +0100

> mark such proposals clearly as that.

No, I don't want to do this, at least not now. But we have two problems with the ip and routing documents, and I think we should agree on a coordinated approach and avoid repeating type definitions:

1. For some IPv4 and IPv6 addresses we don't want to allow the zone-id part.

2. Some leafs ("netmask" in ip and "router-id" in routing) use the "inet:ipv4-address" type but are no IP addresses, and cannot contain the zone-id either.

#1 can be solved by restricting the "inet:ipv[46]-address" with another pattern, though I am not happy with it.

(Note, however, that there is now way to restrict the union type "inet:ip-address" in order to get rid of the zone-id.)

To solve #2, I propose to add the following typedef to the "ietf-ip" module, which can be used for "ip:netmask", "rt:router-id", and later for OSPF Area ID etc.

typedef dotted-quad {
  type string {
    pattern
      '(([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])';
  }
  description
    "An unsigned 32-bit number expressed in the dotted-quad
     notation, i.e., four octets written as decimal numbers
     and separated with the '.' (full stop) character.

     In the canonical format, leading zeros in all octets are
     suppressed except for a zero octet which is written as '0'
     (single digit zero).
    ";
} 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Dec 2012 21:19:03 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 
> On Dec 3, 2012, at 4:15 PM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> 
> >> On Dec 3, 2012, at 11:47 AM, Juergen Schoenwaelder
> >> <[email-masked]> wrote:
> >> 
> >> Zone indices are used in routes with destination prefixes based on
> >> link-local addresses. In my experience, these are pretty rare. Are there
> >> any other uses?
> >> 
> >> Anyway, by including support for these corner cases in the essential
> >> "ipv4-address" type, every use of this type is forced to check for the
> >> presence of a zone index. Implementors who forget about this (I and Martin
> >> also did, right?) will open security holes for attackers.
> >> 
> > 
> No, I don't want to do this, at least not now. But we have two problems with
> the ip and routing documents, and I think we should agree on a coordinated
> approach and avoid repeating type definitions:
> 

This is currently a problem only for ip, and my intention is to solve
it there.

> 2. Some leafs ("netmask" in ip and "router-id" in routing) use the
> "inet:ipv4-address" type but are no IP addresses, and cannot contain the
> zone-id either.
> 
> #1 can be solved by restricting the "inet:ipv[46]-address" with another
> #pattern, though I am not happy with it.

This is what I had in mind.

> (Note, however, that there is now way to restrict the union type
> "inet:ip-address" in order to get rid of the zone-id.)
> 
> To solve #2, I propose to add the following typedef to the "ietf-ip" module,
> which can be used for "ip:netmask", "rt:router-id", and later for OSPF Area ID
> etc.
> 
> typedef dotted-quad {
>   type string {
>     pattern

This is not particularly elegant :(  But this is what we have to do
today.  It would be nice to write:

   type uint32 {
      display-format "1d.";
   }
 
... in some kind of extended DISPLAY-HINT syntax...

Anyway, I don't understand why such a type would belong to either
ietf-ip or ietf-inet-types.

For now, I think the quickest way forward is to solve this separately
in each module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 05 Dec 2012 10:33:02 +0100

> This is currently a problem only for ip, and my intention is to solve

Hmm, I am hesitating about things like next-hop in the routing module, but I will probably leave it as it is, i.e. with the optional zone-id.

> This is not particularly elegant :(  But this is what we have to do

Actually, the second paragraph is unnecessary because the pattern doesn't allow leading zeros.

> today.  It would be nice to write:

I am not sure about this one, because we want the dotted quad format to appear on the wire, but I was thinking about display hints covering several leafs, for instance

container ip-address {
  display-format "concat(ip, '%', 'zone-id')";
  leaf ip {
    type dotted-quad;
  }
  leaf zone-id {
    type string;
    ...
  }
}

> ietf-ip or ietf-inet-types.

Because then we can avoid having the same pattern in multiple places. What's wrong on such a type? I think it is quite comparable to types like "uint32" which also have no special semantics.

> For now, I think the quickest way forward is to solve this separately

If you define the above type in ietf-ip, then I can reuse it - ietf-routing already imports ietf-ip. Would this be any slower?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Dec 2012 15:57:54 +0100 (CET)

Hi,

> doesn't allow leading zeros.

Ok.

> I am not sure about this one, because we want the dotted quad format
> to appear on the wire

Yes, the idea was that it would affect the lexical value.
lexical-format might be better.

> Because then we can avoid having the same pattern in multiple
> places. What's wrong on such a type? I think it is quite
> comparable to types like "uint32" which also have no special
> semantics.

My point was that it is not clear why it would be defined in ietf-ip
or ietf-inet.  There is no ip or inet specific semantics associated
with this type.  ietf-yang would be a better place for it...  But see
below.

> If you define the above type in ietf-ip, then I can reuse it -
> ietf-routing already imports ietf-ip. Would this be any slower?

Ok, I'd like to make progress, so I am prepared to define this type in
ietf-ip, and use it for the netmask.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Dec 2012 16:22:56 +0100

> with this type.  ietf-yang would be a better place for it...  But see

I agree, such a type probably belongs to ietf-inet-types, but we can't afford a new downref to 6021bis now. The scenario could IMO look like this:

1. Define this type temporarily in ietf-ip and use where necessary;
2. Add it also to ietf-inet-types;
3. After 6021bis is published, change "ip:dotted-quad" to "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc;
4. Obsolete "ip:dotted-quad".

Could this work?

> ietf-ip, and use it for the netmask.

Good, I'm going to use it for "router-id".

Thanks, Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Dec 2012 08:34:57 -0800

On Mon, Dec 10, 2012 at 7:22 AM, Ladislav Lhotka <[email-masked]> wrote:

> I agree, such a type probably belongs to ietf-inet-types, but we can't
> afford a new downref to 6021bis now. The scenario could IMO look like this:
>
> 3. After 6021bis is published, change "ip:dotted-quad" to
> "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc;

A: deploying standards is very expensive.  Temporary fixes last 10 - 20
years around here.
There is no such thing.  Get it right the first time or pay the price for
many years to come.

B: There happens to be a 6021bis draft:
http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt
It adds 'hex-string' and 'uuid' to ietf-yang-types.yang.
(A 'Changes Since RFC 6021' section would make that more clear.)

There are many useful typedefs in the common-types.yang module in
the proposed ACL draft.
http://www.ietf.org/id/draft-huang-netmod-acl-01.txt

I don't know how practical it is to re-open 6021 every time the WG thinks of
a new typedef to add.  But it seems easier than chartering and publishing
new work,
and it is better for YANG developers to keep the standard types in a lot
of random modules.

I don't agree with any of the 4 options above. I prefer:

5) work on 6021bis for a short time (1 - 2 months) and
publish reusable data types only in 1 place (6021bis).

Andy

Could this work?
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Dec 2012 17:49:26 +0100

On Dec 10, 2012, at 5:34 PM, Andy Bierman <[email-masked]> wrote:

> A: deploying standards is very expensive.  Temporary fixes last 10 - 20 years around here.
> There is no such thing.  Get it right the first time or pay the price for many years to come.

Well, "dotted-quad" could stay in ietf-ip for 10 years, no problem, though the new status should be "deprecated" and not "obsolete".

> a new typedef to add.  But it seems easier than chartering and publishing new work,

I didn't mean it as options but rather as a sequence of actions.

> publish reusable data types only in 1 place (6021bis).

And I don't agree with this one. Your time estimate is ultra-optimistic.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Dec 2012 18:02:13 +0100

> publish reusable data types only in 1 place (6021bis).

The question is whether 1-2 months is realistic. It will likely be 6
months in the WG. The devil is in the details and some of the details
tend to only pop up at WG last calls. So are we fine with having the
IP and routing data models sitting in the RFC queue for whatever time
it takes to revise, approve, publish 6021 (in my calculation this is
more likely 6 months plus IESG processing plus RFC queue time, so 8-10
months)?

/js

PS: My record so far has been RFC 4789 which took about 6 months from
    initial I-D to RFC published. This was AD sponsored (no WG to
    reach concensus) and a topic most people find kind of esoteric.
    Hence I am questioning the 1-2 months unless we already limit the
    scope of additions to consider for 6021bis.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Dec 2012 09:14:30 -0800

> more likely 6 months plus IESG processing plus RFC queue time, so 8-10
OK -- it is not realistic if common-types.yang is considered,
although IMO that module has some very useful datatypes
based on other standards (so it's either right or it's wrong,
but it isn't purple vs. dark blue).

Adding 3 or 4 types (and 2 are done already) better not take 6 months.
That would indicate a major process failure by the WG and its chairs.
It's the translation of a complex operational model into a data model
that takes all the time.  It 's the delay itself -- it promotes endless
late comments and rewrites.  We need to learn how to do a Code Sprint
for I-Ds.

/js
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Dec 2012 18:54:26 +0100

On Dec 10, 2012, at 6:14 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> On Mon, Dec 10, 2012 at 9:02 AM, Juergen Schoenwaelder <[email-masked]> wrote:

The need for new types arises (naturally) during module development, often quite late in the process, so I think the only option in most cases is to define the type right in the module which needs it.

If such a type is found applicable in other modules, it might be useful to move it later to a type library. We need to figure out a reliable procedure for performing this migration, within the existing constraints of the IETF workflow. This procedure must not put ongoing development of modules on hold. 

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Dec 2012 20:19:07 +0100

> That would indicate a major process failure by the WG and its chairs.

I heard you talking about more than 2 types. I probably mis-understood
your email. As I stated in my email, the question is how you scope
6021bis work. If we open up 6021 for general additions, I continue to
believe that my estimation is more realistic than yours (but I might
be equally well just a failing WG co-chair).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Dec 2012 20:29:24 +0100 (CET)

> be equally well just a failing WG co-chair).

I am not convinced that dotted-quad is such a common type that we
should include it in 6021bis.

(I also do not think that the ip/tcp-packet-specific types from the acl
draft should be included in 6021bis.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Dec 2012 11:40:26 -0800

> be equally well just a failing WG co-chair).
No -- I  think documents are waiting their turn in the NETMOD queue,
and highest priority is finishing the current documents.
I don't think moving typedefs from 1 module to 6021bis will work.

We will never find it more efficient to re-open 6021bis than
just publish new typedefs in the current work.  But we can
establish some conventions instead.

IMO it would help to publish the reusable typedefs in a separate module
(e.g., publishing foo.yang, then split reusable typedefs into
foo-types.yang).
This will make conformance more clear, and make it easier for
YANG authors to find the datatypes that are intended for reuse.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 10:16:47 +0100

> should include it in 6021bis.

It is currently supposed to be used in at least three different modules. I don't know what's the alternative - let each module define its own version?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 10:40:43 +0100

> It is currently supposed to be used in at least three different modules. I don't know what's the alternative - let each module define its own version?

Speaking as 6021bis editor: A type that is used by multiple data
models without being highly technology specific or modeling something
controlled by IANA is a decent candidate for inclusion in 6021bis. I
do not see a problem to add a dotted quad type to ietf-yang-types,
probably with some additional text that for IPv4 addresses, the
specific type provided by the ietf-inet-types module must be used.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2012 10:48:09 +0100 (CET)

> specific type provided by the ietf-inet-types module must be used.

So, one thing we said about 6021 was something along the lines "it is
easy to add new types".

We just have three new types 'hex-string', 'uuid' and 'dotted-quad'.

Why don't we try to do this quickly and a WGLC on 6021bis "now", and
send all five document to the IESG at the same time.

If this process works, it means we don't have to argue to death about
even more new types to add - we can add them just as quickly at a
later time instead!

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 11:30:41 +0100

> even more new types to add - we can add them just as quickly at a

There were previously some suggestions. Here is my (likely incomplete)
list of things:

* DONE hex-string

* DONE uuid

* TODO dotted-quad

* TODO ipv4-address-with-prefix, ipv6-address-with-prefix,
  ip-address-with-prefix

  So far, it seems noneof our current modules needs this sincewe
  keep the prefix length separated fromthe ip address.So I amnot
  sure what to do aboutit, probably keep it pending.

* TODO yang-identifier

  I noticed in ietf-netconf-acm.yang that leafs such as "module-name"
  "rpc-name", and "notification-name" are used to represent YANG
  identifiers, but the data type is plain "string".  IMO, this is not
  correct.  The string should be constrained to only valid YANG
  identifiers, which chould be a standard typedef.

  I think the ietf-yang-types module needs to be updated with a typedef
  for yang-identifier.  E.g.:

     typedef yang-identifier {
       type string {
         length "1..max";
         pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*';
       }
       description
         "YANG identifier string";
         // An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
         // identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".")
        reference "RFC 6020, page 163";
      }

  Does anybody know how to write a regex pattern for the must not start
  with "xml" requirement that is not in the ABNF?

* TODO yang types for ip multicast addresses

  See post by Markus Rothmann, not sure what to do about it.

* TODO any yang types to lift from the ACL module?

One option to try to run such a process fast is to run it by hard
deadlines. That is, we make a call for additions and people need to
propose additions with close to complete writeups of the typedefs
proposed. For each proposal a separate email thread is created. 2-3
weeks should be enough for proposals to come in. We then work through
the list, seeing which clarifications are needed and on which typedefs
we reach concensus. Discussions are cut after another 2-3 weeks,
typedefs not reaching concensus by then will not be considered for
this update. By end of January, we have an I-D to be WG last called.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2012 11:44:25 +0100 (CET)

>   sure what to do aboutit, probably keep it pending.

I know that people define their own type for this one all the time,
but IMO, these are really two different leafs and they should be
modelled as such.

If we do this, why not also do <ip>:<port>, ... it is a slippery
slope.

>         reference "RFC 6020, page 163";

Ok.  This should be non-controversial.

>   See post by Markus Rothmann, not sure what to do about it.

Keep them pending.

> * TODO any yang types to lift from the ACL module?

IMO no.  Maybe vlan id, but we had that one early on and remvoed it.

> deadlines.

I like this idea.

> That is, we make a call for additions and people need to

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 14:14:27 +0100

> specific type provided by the ietf-inet-types module must be used.

I agree, but maybe the right place for the dotted-quad type is ietf-inet-types because I don't remember seeing it outside the Internet/IP context. Even IS-IS uses its own NSAP address for both router-id and area-id.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 15:26:56 +0100

> I agree, but maybe the right place for the dotted-quad type is ietf-inet-types because I don't remember seeing it outside the Internet/IP context. Even IS-IS uses its own NSAP address for both rout…

But there is no reason to limit dotted-quad to IP only. In fact, a
dotted-quad is a special case of a dot-decimal notation, which we for
example use of OIDs. I would rather not 'restrict' its usage to IP
since the definition of the type truely is generic.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 15:28:31 +0100

>   sure what to do aboutit, probably keep it pending.

IMO the only potential use for this is the configuration of an IP address on an interface, so unless ietf-ip uses it, I don't see any reason for defining it.
   
>          pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*';

The commas must not be there, and '.' (dot) needn't be escaped in a character class, i.e. it could be '[a-zA-Z_][a-zA-Z0-9\-_.]*'.

>   with "xml" requirement that is not in the ABNF?

'[^xX].*|.[^mM].*|..[^lL].*'

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 15:31:07 +0100

> since the definition of the type truely is generic.

OK. Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 06:51:46 -0800

> this update. By end of January, we have an I-D to be WG last called.
I said a 1 - 2 month process.
You guys said "1 to 2 months in the IETF is 6 months".
I said "You're right".  Now you are saying 4 - 6 weeks.

Without some sort of process to update 6021, then the only updates we can
add are typedefs nobody actually needs at the moment.

There are 3 process options:

1) put reusable metadata anywhere.  YANG tools can find it,
    even if humans can't.

2) separate out reusable metadata into a different YANG module like
common-types.yang
    in the ACL draft.

3) publish reusable metadata in RFC 6021-bis.

The time issue will always be a factor for each new YANG module.
Waiting until the end of the process to figure out there are reusable
typedefs
will produce the greatest delays and make (3) too impractical.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 15:57:13 +0100

> I said "You're right".  Now you are saying 4 - 6 weeks.

See, there is progress. ;-)
 
> 3) publish reusable metadata in RFC 6021-bis.

The term 'metadata' is more than confusing.

> typedefs will produce the greatest delays and make (3) too impractical.

I open to try experiments. Perhaps it is even possible to turn things
around fast if we follow a strict process that kill endless WG
discussions by removing any proposed typedefs from the update that
cause endless discussion, essentially postponing them to the next
update cycle.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 07:20:09 -0800

> The term 'metadata' is more than confusing.
It might include identities to go with an identityref typedef.
A different RFC would be for groupings I suppose, but it
is possible that we create reusable groupings that we want
to be used in domain-specific modules.

> cause endless discussion, essentially postponing them to the next
Perhaps, but republishing 6021 is a big deal, and probably needs more than
2 -3 weeks to conduct detailed reviews.  I think option (1) or (2) is
sufficient for the
1 or 2 new types needed by the current modules.

Updating 6021 doesn't seem realistic -- ever.  I don't think the 2 typedefs
added
are urgently needed, and bumping the number to 3 or 4 isn't very compelling.
It would be worth updating if it was significantly enhanced, and then not
touched again
for 3+ years.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 16:20:26 +0100

>  with "xml" requirement that is not in the ABNF?

Second try:

'.|..|[^xX].*|.[^mM].*|..[^lL].*'

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2012 16:29:53 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> Updating 6021 doesn't seem realistic -- ever.

Wow.

If we can publish these typedefs in other modules (like ietf-ip), why
would moving them to 6021bis be such a big deal?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 07:47:45 -0800

> would moving them to 6021bis be such a big deal?
IMO, moving a typedef is a really bad idea.
I prefer these types be in ietf-ip-types.yang, but even if they are in
ietf-ip.yang,
that is better than deprecating, then obsoleting them, and cut-and-pasting
new ones. Then every module using the deprecated typedef has to be
republished
to use the new one instead.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 17:05:51 +0100

On Dec 11, 2012, at 4:47 PM, Andy Bierman <[email-masked]> wrote:

> I prefer these types be in ietf-ip-types.yang, but even if they are in ietf-ip.yang,
> new ones. Then every module using the deprecated typedef has to be republished

Moving a type to "deprecated" status doesn't force modules that use the type to immediately upgrade. So the type can be changed at the next suitable occasion when the module is being republished anyway.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 08:08:04 -0800

>> > Updating 6021 doesn't seem realistic -- ever.
Because we are not quite smart enough to plan ahead or patient enough to
wait for the IETF process.  We should realize that since we are creating
the framework, that the reusable type issue will come up now.

But Juergen thinks 4 - 6 weeks, and I think 4 - 8 weeks, especially over
the holidays.  It's not like 2 weeks is a lot of IETF time.
I agree with Juergen's experiment except for the agree-now-or-toss-it
review process.  I prefer just an extended WGLC review process lasting 3 or
4 weeks.

We are not promoting long term YANG reuse unless we take steps in the short
term
to make that feasible.  But if the short-term steps are quick-and-dirty, we
end up making things worse in the long-term.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 08:14:11 -0800

On Tue, Dec 11, 2012 at 8:05 AM, Ladislav Lhotka <[email-masked]> wrote:

> Moving a type to "deprecated" status doesn't force modules that use the
> type to immediately upgrade. So the type can be changed at the next
> suitable occasion when the module is being republished anyway.
>
>
It has to be republished, which is a lot of overhead,
so it won't get done.

The definition exists in 2 places for years, causing lots of
confusion.  What is the point of moving a typedef anyway?
To reduce confusion and complexity? IMO it does the opposite.

Lada
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 17:15:40 +0100

> Updating 6021 doesn't seem realistic -- ever.

Boy, now you are going extreme. I will agree only if the world stops
spinning on December 21st.

What really kills progress in this WG is endless debate about
non-important little issues that should be much quicker to settle.  We
seem to not have big pressure to deliver important things. Yep, I am
frustrated - why can't we say put the definition there, lets move on?
Perhaps I should just stay silence and watch you guys arguing every
little detail to death until there is clear concensus. I should stop
thinking constructively.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 08:25:27 -0800

> little detail to death until there is clear concensus. I should stop
Updating the YANG Types RFC is a big deal.
IMO it should be done carefully.  Publishing
an ietf-ip-types.yang module is a really painless solution.
I am concerned about a long-term module library maintenance nightmare.

Unless there are lots of useful typedefs added to RFC 6021-bis, I don't
think
it is worth re-publishing.  Just make more module names.  They are free.
A significant improvement to 6021bis would require some time to complete.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 17:36:53 +0100

> It has to be republished, which is a lot of overhead,

Why?

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in order to foster interoperability with
      older/existing implementations.

> To reduce confusion and complexity? IMO it does the opposite.

It would be a big problem to have generally useful definitions scattered in a dozen or so modules. Importing a module is not without cost, given all the issues with revisions.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2012 18:19:31 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> non-important little issues that should be much quicker to settle.

+1

> We

+1

> little detail to death until there is clear concensus. I should stop

Please.  Can we try this process?  It seems we have at least three
people who would like to try, and one that does not.  What do other
people think?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Dec 2012 18:41:27 +0100

>> non-important little issues that should be much quicker to settle.

It is easy to agree with this claim, the problem is that people differ in their assessment regarding which issues are small and which are big.

> people who would like to try, and one that does not.  What do other

I don't know who is the one that does not, so just to make sure - it's not me.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2012 10:38:14 -0800

So what is the problem that you are trying to solve?
There are 1 or 2 IP related types and importing them
from ietf-ip.yang is unacceptable?

I don't think a tiny update of 6021-bis helps, and a full update
takes some time to write and review, and maybe even a charter update.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2012 20:43:38 +0100 (CET)

> So what is the problem that you are trying to solve?

Put the types where they belong.

> from ietf-ip.yang is unacceptable?

dotted-quad is not ip specific.

> takes some time to write and review, and maybe even a charter update.

6021 has almost no text; the rfc is the yang modules.  If the 6021bis
editor thinks this is too much work to handle, I am sure he will speak
up.

The typedefs are the same so the reviwers have the same amount of work
to do anyway.

/martin

---

From: Jonathan Hansford <[email-masked]>
Date: Wed, 12 Dec 2012 10:09:42 +0000

If the process represents a 4 to 6-week turnaround (if I remember
correctly), then give it a try. In the scheme of things, a 6-week wait
is nothing and if it proves the process works then we can have
confidence in turning the handle each time the need arises. If it
doesn't work (and we cannot fix it) then we'll know better in future and
can confidently adopt an alternative approach. 

Jonathan 

On
11.12.2012 17:41, Ladislav Lhotka wrote: 

> On Dec 11, 2012, at 6:19
PM, Martin Bjorklund <[email-masked]> wrote:
>> Juergen Schoenwaelder
<[email-masked] [1]> wrote: 
>>> What really
kills progress in this WG is endless debate about non-important little
issues that should be much quicker to settle.
> It is easy to
agree with this claim, the problem is that people differ in their
assessment regarding which issues are small and which are big.
+1 
>> 
>>> Perhaps I should just stay silence and watch you guys
arguing every little detail to death until there is clear concensus. I
should stop thinking constructively.
>> Please. Can we try this process?
It seems we have at least three people who would like to try, and one
that does not. What do other people think?
> I don't know who is the
one that does not, so just to make sure - it's not me.
> Lada
/martin _______________________________________________ netmod mailing
list [email-masked] [3]

Links:
------
[1]
mailto:[email-masked]
[2]
mailto:[email-masked]
[3] mailto:[email-masked]

---

From: t.petch <[email-masked]>
Date: Wed, 12 Dec 2012 11:13:39 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 11, 2012 4:15 PM
> spinning on December 21st.

The Mayan calendar reaches the end of its current cycle on 12th
December, which it is already where I am at present.  I am working on
the assumption that a fresh cycle will start so an update to 6021 will
happen.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Wed, 12 Dec 2012 11:08:11 +0000

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 10, 2012 4:34 PM
> There is no such thing.  Get it right the first time or pay the price
for

Yes, or perhaps YES YES YES (with whatever the emoticon is for extreme
anguish).

Perhaps because I have been doing this sort of thing for decades, I have
decades of experience of paying the price, which I would rather not have
had; so yes, get it right first time.

Tom Petch

> > Good, I'm going to use it for "router-id".

------------------------------------------------------------------------
--------

---

From: t.petch <[email-masked]>
Date: Wed, 12 Dec 2012 10:53:20 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 11, 2012 2:26 PM

> > I agree, but maybe the right place for the dotted-quad type is
ietf-inet-types because I don't remember seeing it outside the
Internet/IP context. Even IS-IS uses its own NSAP address for both
router-id and area-id.
> since the definition of the type truely is generic.

Juergen

Two of the examples I quoted earlier are not strictly IP.  They identify
MPLS switches and there is a requirement that these can operate in boxes
with no IP support.  Of course, there will likely be IP support
somewhere, for management protocols, but boxes in the middle of an LSP
can be identified by dot-decimal notation but have no IP capability in
them, being controlled by non-IP control protocols.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Dec 2012 03:48:14 -0800

On Wed, Dec 12, 2012 at 2:09 AM, Jonathan Hansford
<[email-masked]>wrote:

> **
> correctly), then give it a try. In the scheme of things, a 6-week wait is
> nothing and if it proves the process works then we can have confidence in
> turning the handle each time the need arises. If it doesn't work (and we
> cannot fix it) then we'll know better in future and can confidently adopt
> an alternative approach.
>

The ACL draft has a module called common-types.yang.
http://www.ietf.org/id/draft-huang-netmod-acl-01.txt

It has the following typedefs:

   - cos
   - tos
   - precedence
   - tcp-flag-type
   - ether-type
   - ip-protocol
   - igmp-code
   - icmp-code
   - vlan-identifier
   - time-to-live

I don't know how many proposals there will be in 2 weeks, there here are 10
published typedefs
to consider adding to 6021-bis.  Will there be 15 typedefs to review or 50?
 If there are no more
than 15 typedef proposals then I agree this can be finished quickly.

Jonathan

Andy

> On 11.12.2012 17:41, Ladislav Lhotka wrote:
>
>  We seem to not have big pressure to deliver important things. Yep, I am
> Perhaps I should just stay silence and watch you guys arguing every little
> detail to death until there is clear concensus. I should stop thinking
> constructively.
>
> Please. Can we try this process? It seems we have at least three people
> who would like to try, and one that does not. What do other people think?
>
> list [email-masked] https://www.ietf.org/mailman/listinfo/netmod
>
> --
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>