At 22:16 20-11-2012, Geoff Huston wrote:
The guidelines for IP address allocations were documented in RFC2050,
adopted in November 1996 as a Best Current Practice. This document
Some parts of RFC 2050 could be considered as Historic. As a FYI
there is only one IANA policy about IPv6 [1].
Hi,
> A possible course of action for the LISP Working Group and the IESG to
> consider would be for the existing /32 address be documented as an IANA
> Special Purpose Address allocation for use in supporting the current
> LISP experiment, and for the LISP advocates to make their case for
> parti
> From: Geoff Huston
I don't have any comment, one way or another, on what seems to be the basic
point of your note (about what role, if any, the IETF should play in
allocation).
However, there was one aspect I wanted to comment on (it's not clear, reading
your note, if this was clear in you
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Noel Chiappa
> Sent: Wednesday, November 21, 2012 8:49 AM
> To: ietf@ietf.org; l...@ietf.org
> Cc: j...@mercury.lcs.mit.edu; jcur...@arin.net; pwil...@apnic.net;
> i...@ietf.org
> Subject: Re: [lisp] Last Call: (LISP
> E
> From: "George, Wes"
> I don't think that expecting code to handle two blocks (the
> experimental one and the permanent one) is asking too much
We disagree. For me, it's extra code/complexity, and it buys you absolutely
nothing at all.
> If a single permanent allocation that ne
Last Monday, I gave a short presentation on collaboration among standards
development organizations at the Global Standards Symposium in Dubai, UAE.
The Internest Society has posted my slides and a transcript of my words. These
are available here:
http://www.internetsociety.org/doc/remarks-glo
Date:Wed, 21 Nov 2012 17:16:58 +1100
From:Geoff Huston
Message-ID: <99b9866c-41d6-4784-aa69-cd25e5910...@apnic.net>
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, m
Hi Noel,
>> I don't think that expecting code to handle two blocks (the
>> experimental one and the permanent one) is asking too much
>
> We disagree. For me, it's extra code/complexity, and it buys you absolutely
> nothing at all.
I don't agree. See below.
>> If a single permanent allocation t
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Noel Chiappa
>
> > If a single permanent allocation that never changes is truly
> necessary
>
> Allocation != reservation. Nobody is asking for the entire chunk to be
> _allocated_ (i.e. given out), just that it be _res
> From: "George, Wes"
>> Allocation != reservation.
> You're hairsplitting on semantics in a way that is mostly unhelpful to
> the discussion at hand.
I _thought_ that the point of the messages from Geoff and others (who were
questioning about how there were no details in the do
Make it an allocation for EIDs and ILNP can use it too.
Dino
On Nov 21, 2012, at 12:25 PM, "George, Wes" wrote:
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>> Noel Chiappa
>>
>>> If a single permanent allocation that never changes is truly
>> necessary
>>
>> All
> A possible course of action for the LISP Working Group and the IESG to
> consider would be for the existing /32 address be documented as an IANA
> Special Purpose Address allocation for use in supporting the current
> LISP experiment, and for the LISP advocates to make their case for
> particular
Hi, thanks for the response. I removed sections that didn't seem to need
further comment:
On Nov 19, 2012, at 1:58 AM, Mahesh Jethanandani
wrote:
[...]
>>
>> *** Minor issues *** :
>>
>> -- section 2.2, last paragraph:
>>
>> The IKE mention lacks context. Do you mean to suggest IKE with IP
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 directi
14 matches
Mail list logo
