Re: [netmod] IP addresses with zone indices

[Andy Bierman <[e-mail]>]

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

> On Mon, Dec 10, 2012 at 08:34:57AM -0800, Andy Bierman 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.
> >
> > 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).
>
> 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)?
>
>
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



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