I-D Action:draft-azinger-scalable-addressing-00.txt

[Nick Hilliard]

Tony,

Several comments.

1: declaring that PI is bad without providing a viable alternative is 
really not a credible proposition.  We know PI is bad.  Every piece of 
documentation related to PI assignment states this in black and white.  PI 
is used, not because we like it, but because there is no alternative if you 
need to multi-home your network.  What we need from the IETF is a 
functional multi-homing protocol, not finger wagging about a policy 
practice to make up for the lack of such a protocol.

2: Ignoring the personality issues which are clouding this discussion, I 
believe Randy and others are correct in pointing out that address 
allocation is not the business of the IETF.  The critical part of this I-D 
is the section entitled "Recommendations" which is a very clear statement 
on the topic of addressing policy.

Here's a positive suggestion: if you word it differently, the draft may 
work better.  E.g. if you tabulate the baseline ipv6 PA allocation and PI 
assignment sizes from each of the RIRs, then note that they are - or are 
not - compatible with the routing / architectural issues noted in the 
document, and that should any move occur to change these standard block 
sizes, that the architectural concerns of this document or its successor 
should be noted.  Would this not say what needs to be said, except that 
you're no longer issuing a policy directive?

3: Where did you pull the /32 and /48 figures from?   And don't answer 
"from current addressing policy, of course" :-)

If you're going to make a specific technical recommendation from the point 
of view of architectural and technical concerns, would it not be advisable 
to give specific reasons for the exact numbers chosen, without so obviously 
looking into the can to see what address registries are already doing?

4: Section 2 does not belong in this document.

5: Section 4 is not useful, as worded.  As operators, we understand that 
aggregation is a good thing.  Could this not be reworded in one short 
paragraph, or else simple references to RFC 4632?

6: Section 6.2 is a straw man.  Given that other people appear to be taking 
the position that there are ivory tower characteristics appearing in this 
document, creating a straw man position like this is unlikely to be useful 
to the worthy cause of aggregation.

7: Not sure why sections 7 or 8 are necessary?

8: The recommendations rfc 4632 are _radically_ different to the 
recommendations of this I-D.  It is simply not correct to note in section 
14: "Much of that work has been incorporated directly into this document as 
it is conceptually identical and simply translated to IPv6 herein."

Nick