Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]