With respect Robert, I disagree with your line of argument and I disagree with your assertion that a reference to an existing RFC is "bogus under these circumstances" This eid draft does not claim to obsolete or update either the description of roles and responsibilities in RFC2860 or the directions to the IANA in RFC4773, yet the document's directions to the IANA appear to me to be inconsistent with those existing procedures and policies. To claim, if I understand your line of argument correctly, that every RFC essentially is an implicit update of all existing RFCs, and every RFC does not need to explicitly obsolete or update any other RFC, as it does does so by default upon publication of the RFC is not a line of argument that I find that I could agree with. For me, it's like proclaiming that: "everything I do is right, and if whatever I do contravenes existing processes and procedures then my actions implicitly update those processes and procedures such that everything I do is right" I find that I cannot agree with such a circular self-referential line of reasoning. Instead, I believe that the processes and processes that the IETF follow are deliberative decisions, and that we update and amend those processes and procedures explicitly, and documents that perform such updates say so explicitly, and are accepted and published on the basis of explicit consideration of the processes and procedures and acceptance of the amendment. But I appreciate that I am by training a mathematician and not a lawyer, and you may indeed be making some critical observations about the nature of the IETF's processes and procedures whose finer points may well have escaped me. However, it seems to me that it would be more productive for the IETF to consider that this issue is a distinct issue, and not confound the consideration of the IETF Last Call of this particular eid draft with the broader issue of the manner by which the IETF crafts and maintains its own procedures, processes and policies. regards, Geoff speaking for myself and noone else On 22/11/2012, at 6:09 AM, Robert Elz <kre@xxxxxxxxxxxxx> wrote: > Date: Wed, 21 Nov 2012 17:16:58 +1100 > From: Geoff Huston <gih@xxxxxxxxx> > Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B@xxxxxxxxx> > > I have no idea whether the allocation requested is reasonable or not, > I haven't read the draft (and unless it becomes more widely used than > currently, might never do so), but I do know that this argument ... > > | The guidelines for IP address allocations were documented in RFC2050, > | adopted in November 1996 as a Best Current Practice. ... > > is totally bogus in these circumstances. > > The rules in RFCs and BCPs bind ordinary users making ordinary requests > for address space - were I to approach IANA with a request for address > space to be allocated, a quick denial quoting the relevant RFC would indeed > be the correct response. > > But when the IETF publishes an updated RFC, that always overrides any > earlier RFC, and establishes new policy - either for the general case, or > perhaps (as seems to be happening here) just a one off override of the > normal rules. > > Doing that is always acceptable, whatever the issue - it is never adequate > to simply refuse to consider such requests upon the basis that they don't > follow the rules and should be done some other way. > > Now, when the IETF (via the last call consensus mechanism) consider whether > the proposed RFC should be published, it is perfectly reasonable to point > out the existing policy, and ask for reasons why use of that mechanism would > not be adequate - if the proponents cannnot explain why doing it the way > they are suggesting is required, or at least is better than the normal way, > then the request (to publish the RFC, not just to perform whatever allocation > it requested - that just falls out of the failure to publish the RFC) should > be refused. > > On the other hand, if the proponents can convince the IETF that the > procedure they're suggesting is the best way to proceed, then that's > what should happen - and that it isn't being done the way that the > normal allocation rules would suggest it should be done is 100% irrelevant. > > If you have an argument against the proposal, please make it upon the > merits of the request, and not based upon some supposed viloation of > address allocation quidelines. > > What the result will be I have no idea - I don't know if this allocation > should happen or not. I might suggest however, that if Noel is correct > about the way this allocation would be used (and Noel usually is correct) > then it may be that an assignment out of the 0::/3 address space (which is > out of the ordinary allocation space for which the guidelines apply) > sounds like it might be the right thing to do - perhaps something like > 10f0::/12 (or something near there not currently allocated). > > kre