> 1. This is NOT ARIN's decision to make, nor that of any of > the other RIRs, because the /48 decision is not independent > of many other design decisions in IPv6. Show me the document where this is explained. I'm not disagreeing with you, I am just saying "Show me the document" because if you can't show it to me, then you are wrong. The IETF has not made any design decision until it is in an RFC. > 2. If ARIN or any of the other RIRs have concerns about an > IETF design decision, they need to express that to IETF and > ask IETF to fix it. ARIN, like the IETF, is mainly a bunch of individuals. I, as an individual with a history of involvement in ARIN (I was a founding member of the ARIN Advisory Council), have already come to this mailing list, which ostensibly is frequented by individuals who have a history of involvement in the IETF. I have already asked the IETF to fix this. Clearly you do not believe that a request from an individual is sufficient. Since the IETF seems to be defined by its documents, I wonder which RFC I can refer to in order to find out the correct formal process for ARIN to follow in order to ask the IETF to fix the problem? I will admit that I could attempt to fix this by writing an ID myself, but since I was not involved in the IP-NG work in IETF, I really don't know why the IPv6 architecture is what it is. And since I learned about IPv6 mainly by reading RFCs, I worry that I may still have misconceptions hanging around from before various things were deprecated. > The danger in my going to them personally is that it will weaken or > delay the communication that needs to occur. By insisting that I do > this before either ARIN or IETF takes any action there is a > far greater chance that the problems in both ARIN and IETF > will not get fixed. The fact is that we need a document explaining the IPv6 architecture as it stands today. A document that can guide the RIRs but also the many IPv4 network designers who are being forced to architect or design their first IPv6 network. A compact document that fairly states the IETF's intent with regard to IPv6. But most importantly of all, this document must answer objections and common misunderstanding. Failure to do this last item, is failure to communicate, which will cause many people to waste time and waste a lot of money. You can't answer objections and correct misunderstandings unless you participate in forums *OUTSIDE* the IETF where the objections and misunderstandings arise. If this delays communications a bit, that is a good thing if it also results in better quality of work. --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf