Pekka,
> Thanks.Oh, btw, in the references too.
At least I was consistent :-)
> It seemed to me like a convenient place to do it as this was defining the > 2000::/3 prefix. It could be done elsewhere, but hopefully this draft can > get through the process quickly. Well, if one believes this can be done quickly here, no problem.
I was hoping this would be the case.
I viewed it as opening up the rest of the 2000::/16 prefix for /32 allocations. Currently all of 2000::/16 is reserved inBut I'm not sure it can. I, for one, am very adamantly against reserving 2000:0001::/32. That wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first parts of it are needed). An extremely bad idea, IMO. I'd recommend taking something from 2001, like 2001:0001::/32 or 2001:FFFF::/32.
http://www.iana.org/assignments/ipv6-tla-assignments
I guess it depends on how one looks at it.
Lets try to avoid a lengthily discussion on this. I think the w.g. has more pressing issues. If others have strong feeling on this, I am happy to change it. Or remove it.And this kind of "which one is the right block to reserve" discussions could delay the other parts of the draft, which was my main motivation for keeping it outside of this one.
For practical purposes they are all normative. It if helps, I can say that in the next version of the draft.> >5.0 References > > > >==> split the references. > > Why? Most are normative or very static. Because otherwise the draft will get bounced back when the AD checks for ID-nits, and because it's required before it can get to the RFC editor..
Bob
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
