Roger,
Please se inline.
2012-12-2122:12, Roger Jørgensen :
> On Fri, Dec 21, 2012 at 2:57 PM, Rémi Després
> wrote:
>> 2012-12-2110:49, Ole Troan :
>> ...
(*)
4rd implementors are free to add code to reject any intra-site IID that
(by mistake) would be universal-scope, and in
Hi, Suresh,
Comments inline.
2012-12-21 à 23:09, Suresh Krishnan :
> Hi Remi/Ole/Bob,
> Speaking as the author of RFC5453, I am afraid that this will not
> work. The allocation policy for this registry is *Standards Action* and
> hence requires a Standards track RFC.
Bad news, but an indisputa
Hi Remi/Ole/Bob,
Speaking as the author of RFC5453, I am afraid that this will not
work. The allocation policy for this registry is *Standards Action* and
hence requires a Standards track RFC. This was done to keep the bar high
to minimize disruption to existing implementations as they do not che
On Fri, Dec 21, 2012 at 2:57 PM, Rémi Després wrote:
> 2012-12-2110:49, Ole Troan :
> ...
>>> (*)
>>> 4rd implementors are free to add code to reject any intra-site IID that (by
>>> mistake) would be universal-scope, and in the 4rd-assigned IID range.
>>
>> but the current specification does not
2012-12-2110:49, Ole Troan :
...
>> (*)
>> 4rd implementors are free to add code to reject any intra-site IID that (by
>> mistake) would be universal-scope, and in the 4rd-assigned IID range.
>
> but the current specification does not handle conflicts?
There is no relation between this subjec
Hi, Simon,
Thanks a lot for this pointer.
I will check, hopefully with Brian, which 4rd range can best fit in this
up-to-date table.
RD
Le 2012-12-21 à 11:56, Simon Perreault a écrit :
> Le 2012-12-20 11:07, Rémi Després a écrit :
>> - Small problem: at http://www.iana.org/protocols, a regist
Le 2012-12-20 11:07, Rémi Després a écrit :
- Small problem: at http://www.iana.org/protocols, a registry for
"Reserved Internet Protocol version 6 (IPv6) Interface Identifiers"
is listed but, when clicking to open it, the page that comes is that
of "Instant Message Disposition Notification (IMDN
Remi,
Also, is there any reason not to choose (for example)
FDFE:::-FDFE:::
which is near the existing anycast range ?
>>>
>>> No objection that I can see.
>>> Support for including this in the 6man answer.
>>
>> I think this is better than making any assum
2012-12-20 13:46, Ole Troan :
>>> Also, is there any reason not to choose (for example)
>>> FDFE:::-FDFE:::
>>> which is near the existing anycast range ?
>>
>> No objection that I can see.
>> Support for including this in the 6man answer.
>
> I think this is better than
>> Also, is there any reason not to choose (for example)
>> FDFE:::-FDFE:::
>> which is near the existing anycast range ?
>
> No objection that I can see.
> Support for including this in the 6man answer.
I think this is better than making any assumption abut the u/g flags.
Le 2012-12-20 à 11:44, Brian E Carpenter a écrit :
> Rémi,
>
> I think this might work, and is nicely orthogonal to my question
> whether the u/g bits have any intrinsic value.
>
> One question though. You suggest
> 0300:::-03FF:::
> but I understand that 4rd needs 6 by
Rémi,
I think this might work, and is nicely orthogonal to my question
whether the u/g bits have any intrinsic value.
One question though. You suggest
0300:::-03FF:::
but I understand that 4rd needs 6 bytes, not 7.
Is there any reason you did not propose
0300:::
Hello, chairs,
- First a great thank you Jouni for for the reference to RFC 5453, which is
perfectly relevant but had been ignored in this discussion.
The good news is that, since an IANA registry for IID ranges has already been
created, no new registry is needed for any new IID type, and in pa
13 matches
Mail list logo
