Hi Bob, A few thoughts / questions / comments on your draft :
3.0 Proposal & 3.1 Global Token * 8 bit areas I'm curious as to why you chose to allocate 8 bits for the area. Allocating 6 bits for area would allow aggregation to take place on the /16 bit boundary. I think this would make it a easier for network admins to manage their site-local area prefixes when bounded at /16. I was going to suggest putting back the u and g bits, which would make connecting to the origin router for this prefix easier (just telnet to fec0 + EUI-64 + EUI-64), but then realised that your site local global token is generated from an EUI-48 :-( I think there probably is some value in keeping the full EUI-48 as the global token for trouble shooting reasons, at the sacrifice of 2 area bits. 3.2 Assignment * maybe be a bit more explicit about how manual configuration is achieved. I agree with and understand the motivation for manual assignment of these prefixes. However, the whole proposal has a strong "auto-configuration" theme - deriving site-local addresses from EUI-48s sounds a lot like something that would be done automatically by default. Would a typical implementation of this manual assignment be a toggle switch / [on / off] configuration option within a router ? If so, additional text suggesting that these prefixes will be automatically generated, but manually enabled / disabled (defaulted to disabled) might help overcome the "auto-configuration" theme of the generation of these prefixes. * the term "area" might be a bit vague, in the sense that usually people talk about "areas", they are referring to OSPF areas. I found when I initially read this term, I immediately wondered whether this field has some use or value wrt OSPF. A different name for this field might be a bit less confusing. - I don't feel that strongly on this, I think it is just that "area" is in such common usage in the OSPF context (and to my knowledge, no where is in IP routing / addressing), most people would immediately associate any usage of the term "area" in an RFC with OSPF. Regards, Mark. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
