Subject: dickson-v6man-new-autoconf

From: Jeroen Massar <[email-masked]>
Date: Sun, 21 Oct 2007 13:22:08 +0200

Hi,

I just noticed
http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf
and found some serious flaws and most likely misunderstandings in the
way that some things are presented in there. It was already publicly
presented at the NANOG meeting, so lets discuss ;)

<insert humble mode disclaimer etc />

=======
Slide 4: 2000::/3 are indeed only 125 bits, but this is done so that if
2000::/3 turns out to be a mistake that another of the 8 /3's can be
chosen to start again, and improve on it. As such, only using 2000::/3
at the moment is a great thing. Indeed this will most likely then create
a bit of a "Class A" situation, but most very likely it is going to be
just fun.

=======
Slide 9: Of course you can ignore it, just use DHCP. Only fe80::/10 is
fixed to use EUI-64 at the moment. Everything else, if you want can be
done with /126's if you really want. But that defies the whole idea of
stateless autoconfiguration. Nevertheless, if you really want, you can.

But why would you? As an ISP you go to your RIR and the RIR allocates
you a block of address space (generally a /32 or much larger) based on
how many customers you expect to have times /48 + some HD-based overhead.

As such, you as an ISP will get more than enough address space.

========
Slide 10/11: You don't reserve any bits for customers. They are already
getting a /48 which should be *way more than sufficient* for their
purposes. If they really will need more than 65536 /64 based networks
they will already have such a large network now, and thus can tell you
"hey we need a /47" or something, or they will at a certain point run
out and come back and you give them another /48, which does not really
have to be consecutive. Most of those very large networks though will
simply request PI space. As such they are not your worries.

If you are reserving space you clearly misunderstood the whole idea of
the /48's.

Also, there have been plans already (eg by Thomas Nartens) to make the
default assignment size /56 to end-users. Companies would still get
/48's though.

Why would this "squeeze the ISP?", you can get as much space from your
RIR as you require. Same as for IPv4. Justify and receive.

======
Slide 12: IMHO you indeed really don't get it ;)

Does it matter if you have /40's routed to your distinct PoPs, thus
geo-aggregated, and then route /48's from each PoP to the customer, or
make this a difference when you make that into /48's and /64's
respectively? The route count will remain the same.

Note also that there are still not 1000 IPv6 prefixes globally...

====

I won't even go in on the rest of the slides, as the above already make
all your assumptions for the rest broken...

Greets,
 Jeroen

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2007 22:54:39 +0930

On Sun, 21 Oct 2007 13:22:08 +0200

> <insert humble mode disclaimer etc />

Slide 2:

"We can’t fault the IETF -
they aren’t operators"

Some of us are. We've also run Novell IPX, Appletalk or DECNet networks
in the past, with fixed length node addressing, and would love to have
it back. No more too small subnets because you didn't guess right in
the first place, no more incorrect subnet masks, no more double hops
via a router on the same link because you've had to add a secondary
subnet to a link to avoid renumbering, no more remembering to larger
(or smaller) subnets, no more early mornings or late nights outside of
business or critical use hours fixing all of those things ...

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2007 08:38:03 +1300

Mark,

On 2007-10-22 02:24, Mark Smith wrote:
> Some of us are. 

I'd add that the more operators that care to participate in the
IETF, the better it will be for everybody.

I don't happen to agree with Brian Dickson's proposed change,
but I think it's important to discuss why he thinks it's
necessary from an operational viewpoint to permit such sparse
allocation of prefix bits.

    Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Oct 2007 07:22:38 +0930

Hi Brian,

On Mon, 22 Oct 2007 08:38:03 +1300

> allocation of prefix bits.

Slide 11 would seem to be the root false assumption. Brian is assuming
that ISPs would reserve a /44 for each and every customer (i.e.
including residential) to allow for future expansion beyond a /48. He's
then saying the remaining 12 bits from a registry /32 assignment is too
small, which it probably would be, for the reasons he outlines, and
then is looking to get some bits from somewhere else.

Of course, once you don't reserve a /44 for each customer, because
a /48 is plenty for nearly everybody, the 12 bits turn into 16, making
Brian's concerns far less concerning, and probably no concern at all.

Regards,
Mark.

---

From: [email-masked]
Date: Sun, 21 Oct 2007 22:51:31 -0400 (EDT)

> As such, you as an ISP will get more than enough address space.

Please now go and read draft-dickson-v6man-new-autoconf-00.

It goes into why having ISPs get more space from RIRs is a bad thing.
Even if space is available, there is no guarantee that ISPs getting
multiple /32's will announce them only as aggregates. (IPv4 deaggregates
are the demonstrable support for that particular argument.)

More importantly, the slides were to generate interest in reading the
larger document. Obviously, I would have preferred giving a long lecture
on the whole ball of wax (not!). But, in the absence of presenting that,
I had to hit enough of the highlights to get folks over here, and get
folks to read the draft itself.

> respectively? The route count will remain the same.

What matters (and this is the main reason for the whole set of proposals),
is the *ability* of the ISP to aggregate however they want.

It does not matter one whit, what the absolute size of the things are,
aggregates and more-specifics.

My draft includes some tables, showing how many different (non-vlsm, but
hierarchical subnet) schemes can be carved out from a set of bits, where
a particular lower bound on the size of each level of the hierarchy in
bits is specified.

I have a script for taking bits (range) and bits (min size), to calculate
the permutations of hierarchies that can be produced. In the appendix,
I list some of them, and summarize the counts for others.

If you'd like, I can post the script source (perl), and play with it,
to see how limiting it is, to not have enough bits, when you have
a network topology that predicates a certain number of aggregation points
based on that topology (dslams, routers, pops, regions, whatever).

> Note also that there are still not 1000 IPv6 prefixes globally...

And, should experience at some later point show that my proposition on
the impact of /64 holds true, what then?

How easy is it to change the RFCs, when the deployed mess is 30,000
prefixes? 100,000? 250,000?

We don't currently have too much info on the end-site uptake, IMHO.
And that is the kind of thing that would help the drill-down on some
of the assumptions on all sides....

>  Jeroen

Look forward to ongoing discussions on this topic....

But, please, tell me if/when you have read the draft-dickson... itself?

Brian

---

From: [email-masked]
Date: Sun, 21 Oct 2007 23:04:31 -0400 (EDT)

> business or critical use hours fixing all of those things ...

Indeed. In fact, that slide was a little disingenuous.

Please let me explain.

There are many within the operator community who for various reasons, does
not particularly respect, trust, or value, the work of the IETF, or its
processes, or its members.

My intention was not to play to those prejudices, but to move past them
into discussions on the particulars of specific IETF RFCs.

And, in particular, to completely avoid the finger-pointing game.

I would have apologized in advance, to you folks, but didn't want to
telegraph too much about my talk, which I decided to do at the last
minute. (If I had planned for longer, or done more advance work, it might
have gone over better at NANOG, let alone here.)

So, let me know apologize if I have offended any.

I too, have tons of experience as an operator. Most of it good, due to
success in using approaches that scaled very well. I learned from the
mistakes of others. (And some of it was Appletalk, Ethertalk, and bridged
Appletalk/IP networking.)

My intent currently, is to return that wisdom to the community at large,
to help them collectively from suffering from problems that scaling up
IPv6 deployment *may* introduce.

I don't know for sure that not doing what I suggest will result in doom.

However, I am confident in saying, that doing what I suggest will have
much lower likelyhood of bad effects, for a much longer time frame.

And, other than the (intended) side effect of a window of overlap between
changes to RIR policy and IETF and vendor changes, of incompatibility
between allocations and autoconfiguration, adopting both policy and RFC
changes don't, as far as I can see, have a down side, other than the need
to deploy newer versions of code to end nodes. Which is to say, the only
down side is, that there is any change at all.

And, to boot, the window of overlap, still has backward compatibility.
At no time will autoconfiguration fail to work when used with a /64.
So, giving a /64 to an end site will allow a flat autoconfiguration
deployment initially, and will later result in the ability to use 2^16
autoconfiguration subnets.

Thanks for your understanding,

Brian

---

From: <[email-masked]>
Date: Mon, 22 Oct 2007 09:39:20 +0100

> Of course, once you don't reserve a /44 for each customer, 
> because a /48 is plenty for nearly everybody, the 12 bits 
> turn into 16, making Brian's concerns far less concerning, 
> and probably no concern at all.

Well said. 

I do not support extending 6MAN's mandate to include 
this draft.

--Michael Dillon

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 22 Oct 2007 11:19:23 +0200

[this is going to be a long and sort of whiny one, apologies in advance]

[email-masked] wrote:
[..]
> Please now go and read draft-dickson-v6man-new-autoconf-00.

I was not interested at all in reading it as your presentation already
contains a lot of misconceptions, which you then presented at NANOG, to
a group of people who will then get even more misconceptions as they
don't have the time to read through a bulk of text either. They will
though maybe have seen the presentation and think that is the current
state of play, which it is not.

> It goes into why having ISPs get more space from RIRs is a bad thing.

Thus your presentation doesn't reflect what you are actually are trying
to target, while it caries the title of the same draft?

Sorry, but not everybody wants to read through a bulk of text,
especially with a non-technical introduction of nearly three pages, but
most people will assume that the presentation, though in less detail, at
least covers the same content as the draft on the same subject and of
the same name and hopefully then is also concise and correct.

> are the demonstrable support for that particular argument.)

There are already a couple ISP's who got prefixes between /20 and /32
who are currently de-aggregating it.

Changing where the user-bits are, is not going to change that. That is
is in the hands of the ISPs who either accept or don't accept those
prefixes.

One can easily take the the IPv6 stats files provided by the RIRs and
make prefix filters based on that, thus only accepting exactly the
allocations that have been actually allocated by the various RIRs.
If that is what you want of course.

But, that won't work either, as I have previously mentioned already,
there are several ISP's who went to the various RIRs and gotten chunks
from all of them. Some even simply asked for separate (though
aggregatable) chunks from the RIR, a /32 per country.

You are mixing up Addressing with Routing. You are trying to solve a
Routing issue by changing Addressing.

Please see the [email-masked] and [email-masked] who are attempting to solve
that issue.

Also note that the whole idea of giving a /48 (or currently being
proposed a /56*) to end-sites has a real reason: so that those users get
(64-48=) 16 bits to play with.

(* = the /56 for home-sites is a good idea IMHO and would indeed give a
bit more space to ISP's. It is a MUCH better idea than changing EUI-64
though, which can sort of be seen as wasteful, but it is not)

Of course, such an end-site can always decide to either get more /48's
if they are really that big. Or they can do DHCPv6 and deal out /126's.
That really is the end-sites problem. The EUI-64 is there as it will
cater for all, not only a few.

> larger document.

But as the slides already contain a lot of misconceptions, my interest
is not raised at all to even look at it as it will only contain more of
that.

> Obviously, I would have preferred giving a long lecture
> on the whole ball of wax (not!).

...oooOO( If you have no interest in actually correctly presenting and
thus defending your draft, then why do it? )

> But, in the absence of presenting that,

As there was no discussion about the subject yet on any of the lists
that I know about, lets discuss it now that we at least have your
attention and that of a few others.

[..]
> is the *ability* of the ISP to aggregate however they want.

They can already. They get 128-(16~32)-48 of address bits. They can
provide their network layout to the RIR they are requesting their prefix
from and voila. If you need more bits between that, justify them and get
them, it really is that simple.

[..]
> I list some of them, and summarize the counts for others.

Ever heard of the concept of "HD ratio"? Hint: there is an RFC and it is
what RIRs and ISPs use to calculate how large their IPv6 allocation is
supposed to be.

[..]
> the impact of /64 holds true, what then?

Which exact impacts of /64's? Or are you wanting to stuff /64's into
global BGP? ISPs are getting /16-/32's and for PI /40-/48 are being
allocated by the RIRs. How is this going to affect global prefixcount?
Especially if ISPs decide to simply filter per the stats file and only
accept what was allocated. De-aggregation will happen if other ISPs
allow it. If they don't then it won't happen.

Also a router doesn't see a difference between routing a /128 or a /64.
Both are one entry. In the best case the /64 can even be stuck into a
smaller entry if wanted (eg buckets for /64's) and thus contain less
space. Then again I am not building routers for a living so I can be
totally wrong there, but I really don't see a difference.

> prefixes? 100,000? 250,000?

If you want to save 'bits', then start assigning /56's to your
customers, then you get 8 bits "back". Doing /56's makes much more sense
and doesn't require any changes at all in any of the architectures that
have been established 10 years ago.

> We don't currently have too much info on the end-site uptake, IMHO.

Start promoting IPv6 and start deploying it then.

Steering offtopic for this a bit, I heard a rumor that went along the
lines of "Yeah, in the ARIN region most new prefixes directly get turned
up and thus our deployment is faster"

Not so odd, as before the PI space was possible there where nearly no
allocations in ARIN land, but still, how does that translate to actual
deployment (at least looking from BGP if they are active). Lets check
GRH (http://www.sixxs.net/tools/grh/ for folks who don't know it yet ;)

RIPE : 760 / 391 / 51.45%
ARIN : 470 / 154 / 32.77% <--- 20% less in comparison to RIPE/APNIC
APNIC: 346 / 186 / 53.76%

So what was so good about that again. Please US folks, stop doing PR
about that you are going to and start deploying!

Do note that ARIN now has more prefixes than APNIC. Still both APNIC and
ARIN have only 50% of the prefixes online that RIPE already has. That is
quite some way to go folks!

See the various other stats on the GRH site and potaroo etc for other
perspective on allocation etc.

[..]
> But, please, tell me if/when you have read the draft-dickson... itself?

I, for a moment, ignored the content of your presentation, which
according to you doesn't represent actually what you want to state in
the draft but is more a sort of tabloid thing to call for attention.

I have now fully read your draft, word for word, just to be able state
that I did. Still I can't find anything in there which would even
remotely justify even thinking of changing the EUI-64 concept, mostly as
the same misconceptions in the presentation are being made in the draft.

It read like a great advertisement, though high on bla-bla, and it will
probably work great if you need to raise venture capital or want to
write a 20 page paper for a conference, unfortunately it has nothing to
do with technical requirements or argumentation. Nice use of buzzwords
though and repeating of things that are available in other places,
though then with a twist which indeed are basically misconceptions.

eg 2.1 "Existence", a /48 is *HUGE*, probably too large for most
end-sites, these will also never have to renumber (unless swapping ISPs)
Looking at the PI space that ARIN is allocating, and most of it being
/48's, this clearly is the case that nobody think they will be bigger.
The ones that need more space are getting a larger block directly or can
later on get an additional /48. Aggregation there is not a big issue,
and you really will not be jumping from one /48 to a 1000 or so of them.
If you are, then one really did some mismanagement and misplanning ;)

Please show me a network design at a single site which will use more
than a /48 and completely fill it up. (which would produce 65k routes in
your internal routing tables if you would not properly aggregate, which
you can easily do, but that is left as an exercise to the reader).

The whole point: if you need more address space go to your RIR and
justify it and get it. Note also that the whole idea of IPv6 allocations
is that an ISP will *never* come back again. Take a guess why some ISPs
got a /20 and there are rumors of this $organization getting a /13...

You might have to pay a few more $localcurrency, but if your network is
that big, do those really matter then?

Btw: "3.1.  Current Allocation Techniques" states "End User Assignment
Size:  Typically /56" which really is bogus at the moment. It might be a
good way to change to it. But really the blocks are sized /48 at the
moment. This is also the size that ISP's justify their /32 or larger on.
If they would change this themselves to a /56 some would not be able to
justify a /32 anymore...

in that same part:
"     Note that these large initial allocations actually *support* the
      proposition that more bits are needed - otherwise, why would such
      large allocations be being made?"

Because those are multi-million customer ISP's and they have justified
that they need multiple-millions of /48's for their customers.

The problem for your complete draft is answered, by yourself, already
with that part.

"Reservation for Growth to the ISP:  Typically 4 bits" do you note that
4 bits is a power of 4 times the huge amount of space that they already
have? Do you think that is not enough? Especially considering that they
have justified their allocation request with room to spare for the
future. As such if they run out of the first /32, and the second, and
the third, they clearly did something wrong there.

The rest of the draft covers how to change it and the appendixes. For
the stuff in the appendixes see the HD ratio RFC which covers similar
tables, but then with real math behind it and argumentation.

I would suggest taking a real live ISP network and making a network
diagram for that and how you would chunk up that /32 or larger that you
get from the RIR. Then see if you still have possible 'growth' issues.
Clearly if you need more address space, again, you go to your RIR and
ask for more, hopefully in one big chunk. If you did your work correctly
while planning you already made that design though and would have passed
it on to your RIR who then would automatically (unless it was
ridiculous) have given you that prefix-size you need simply on the basis
 that you have justified it.

Now that I read the draft, and pointed out a few of my concerns, did I
totally miss the picture or what? As I really still don't see the need
for changing any of the current way things work.

The real solution to your 'problem' is the change of /48 -> /56 for
endsites. But you can easily take this up with the RIRs, it has nothing
to do with the architecture of things.

Greets,
 Jeroen

---

From: Brian Dickson <[email-masked]>
Date: Mon, 22 Oct 2007 15:52:11 -0400

> [this is going to be a long and sort of whiny one, apologies in advance]
No problem - succinct and on-topic long and whiny is fine.

It's off-topic, dogmatic, or ad-hominem stuff that is not okay.

Fortunately for us all, yours is not the latter. :-)
> who are currently de-aggregating it.
As a community, we should express our collective concern, whenever 
*anybody* deaggregates.
Not doing so at the first instance, implicitly establishes a precedent 
and our collective willingness
to accept deaggregates - something which will, sooner or later, hurt 
nearly everyone in the DFZ.

If you know of ISPs doing this, would you please identify them? I think 
we all want to know...
> is in the hands of the ISPs who either accept or don't accept those
It's a cause-and-effect thing, that I don't think you grasp.

Basic logic stuff goes:
If the conditional conjunctive, "A -> B" is true, then "!B -> !A" is 
also true.

If the things we are talking about are:
A = "ISP X gets additional PA IPv6 space from an RIR"
B = "ISP X announces the two prefixes, which would be aggregatable, as 
separate prefixes rather than as a single aggregate"

If we want to achieve "!B", i.e. to not have any ISP X announce two 
blocks without aggregating them, then
the simplest way to achieve this is to figure out ways to prevent any 
ISP X from *needing* additional PA space.
(Ever.)

Changing where the user bits, changes the allocation units, which in 
turn changes the number of allocations of "typical"
size that a given PA block can supply.

So, changing where the user bits, *does* directly impact whether, or 
when, any ISP will need to get a second PA block.
Which directly affects (by making moot) the question of whether ISPs 
will or will not aggregate adjacent PA blocks given to them.

> Routing issue by changing Addressing.
No. I am making distinctions between Addressing, Aggregation, 
Allocation, and Routing.

Routing is announcing reachability of IP(v4 or v6) prefixes.
Prefixes are the building blocks of routing.
Prefixes may or may not be aggregates of more-specific prefixes.
It is only possible to aggregate, where allocation of address space 
permits it, whether by design or by accident.

Aggregation can be done externally (e.g. in BGP), or internally (e.g. 
OSPF areas), or both.

Aggregation follows topology, or topology follows aggregation. Pick 
which one you do, if you aggregate at all, is the general rule.

Here's the thing:
I am trying to solve an inherently *unsolvable* problem, by *changing 
the rules* - which is the only way the problem *can* be solved.

If you don't have enough bits for aggregation, you can't aggregate.

If you can't aggregate, you have serious scaling problems in routing.

And scaling problems *cannot* be worked around.
> Please see the [email-masked] and [email-masked] who are attempting to solve
Yes, I'm following rrg threads on LISP et al. I understand that there is 
a problem, and that they are trying to solve it.
However, it's largely a "I have a hammer, and everything looks like a 
nail" problem. They may come up with solutions
for the problem they see, but that doesn't mean it's the *real* problem 
that exists, or that their solution will work
outside the lab environment.

> thus defending your draft, then why do it? )
It's a question of knowing your audience. I don't believe anyone at 
NANOG would have the
patience to put up with a 30 minutes or longer talk on somewhat esoteric 
aspects of protocol
stuff. They want the bottom line.

(I know *I* would walk out of my own presentation at NANOG, if it were 
30 minutes long :-))

BTW - I plan on presenting and defending the draft in Vancouver, at 
IETF, which is its natural home.
> allocated by the RIRs. How is this going to affect global prefixcount?
The impact I'm talking about, what the whole draft talks about, is ISPs 
getting multiple PA blocks
from RIRs, and increase above 1.0000 the average number of PA blocks per 
ASN.

The way /64 affects this is, if the smallest end-user assignment 
permitted under RIR rules, is a /64,
then all allocations to end-users will be /64 or shorter prefixes.

The RIRs use autoconfiguration as a justification for setting the limit 
of allocations to /64 or shorter.

The impact of >> 1.0000/ASN is, that as IPv6 is globally deployed in the 
DFZ as a dual-stack
along side IPv4, the combined prefix counts of IPv4 (already bloated) 
and IPv6 (now slightly
bloated and continuing to bloat as more ASNs get additional PA blocks) 
begin to hit hardware
limits on routers in ASNs in the DFZ.

The possible consequences of this include:
- ISP "withering" - many smaller ISPs or ISPs with thin margins, cease 
operations
- IPv6 abandonment - IPv6 fails to achieve critical mass, and is 
effectively ignored as a "saviour" for the IPv4 Internet
- Internet balkanization - partitioning of portions of IPv4 or IPv6 
based on filtering

> you can easily do, but that is left as an exercise to the reader).
That's too easy.

A large company with a large number of engineering desktops, linux boxes 
which are centrally administered.

A reasonably paranoid network scheme, places one desktop per VLAN, and 
1:1 relationship between VLANs and subnets.

Regardless of the infrastructure topology, 65K desktops with 
autoconfiguration (which is what such an enterprise would do),
means 65K /64's in total, on 65K VLANs. The 4K VLAN per node limit, 
means that at least 16 switches would be needed.

I knew of such a company - at a Usenix conference, one attendee was 
discussing scalably maintaining that quantity of desktops.
The secret was, don't give them root, and use "ghost" to build 
replacement drives. The drive is the computer.
Autoconfiguration fits that model extremely well - no host-specific info 
is needed at all, to get IP addresses and routing working.
> got a /20 and there are rumors of this $organization getting a /13...
Your comment here is a glimmer of hope - you almost grasp what I'm 
talking about.

Yes, yes, yes - the idea for preventing IPv6 routing table bloat, at 
least bloat caused by PA assignments,
is making *sure* that *every* ISP can operate for effectively an 
indefinite period (decades), without
needing additional PA blocks.

In a period of decade(s), do we know which ISPs will be huge? We know 
which ISPs are big now,
but as every financial analysis says, "Past performance is no guarantee 
of future performance".

We don't know who will be really really big, from among the current 
not-so-big ISPs.

There are 10,000's of ISPs. If even 10% of them grow significantly in 10 
years, above the expected
worst-case based on RIR assignments, that means 1000's of extra PA 
blocks. And in the next
5-10 years, PA-caused routing table bloat in the DFZ, can be globally 
hazardous.

The idea is to promote conservationism globally - make it so that even 
astronomical growth, from
the smallest ISPs, will have *no* impact on the DFZ. Make it a level 
playing field, for *all*
the ISPs, by minimizing growth of the DFZ.

> get from the RIR. Then see if you still have possible 'growth' issues.
You're missing the point.

It isn't what *I* do that hurts me, it is what *he/she* does that hurts me.

If a relatively small proportion of the ISPs give away /48's like candy, 
and the RIRs let them,
they run out of space in their /32 and need another block.

Every ISP that does that, eats up space in every *other* ISP's router slots.

And, every ISP that does that, creates a *stupid* mentality among 
end-sites, that the value
to them is the size of the prefix they get. "He gave me a /48, why are 
you suggesting a /112?",
ignoring that the end-user only plans to have 200 hosts and will 
statically configure them.

This "conspicuous consumption" mentality evolves into an arms race, much 
like that of the
cold war, with its own "mutual assured destruction" the only inevitable 
outcome.

It is that kind of mentality, that I hope to prevent from even being 
possible, by reducing
the largest block given out from a no-documentation-required /48, to 
something in the
way of a "please tell us what you plan on using", and extending that by 
lots of bits per end-site.

Rather than giving a big blank check, give a small check with a few 
extra zeros.
End-user wants a /120, give them a /112 (or a /104 or a /96.)
End-user wants a /80, give them a /72 (or a /64.)
> for changing any of the current way things work.
I think the comment from the Area Director was, we (6man) should be 
reasonably open to changes,
unless there is good reason to oppose.

My view is, "not seeing the need", isn't the same as seeing a problem 
with the draft.

Examples of a problem:
- would break something
- not backward compatible
- cannot be easily implemented
- incompatible with certain devices (hardware etc.)

I don't believe there are any problems of those nature, but if I am 
mistaken, I *really* want to know about it.

And, if there aren't problems like those, I would suggest deferring to 
the AD's advice, and permit it to be adopted as a WG matter.

Brian