> The idea is that developers must not hardcode any assumptions. The
> reason they must not is because IANA will later delegate the currently
> unassigned parts of the space to a purpose we don't know, including
> possibly an extension to Global Unicast.
The proposed text reads as if the IANA dele
Erik,
>>Michel Py wrote:
>> Proposed text:
>> RFC2374 was the definition of addresses for Format Prefix 001
(2000::/3)
>> which is formally made historic by this document. Although as
specified
>> in [ARCH] IANA should limit the IPv6 Global Unicast address space to
>> 2000::/3 for now, IANA might
This is good. It leaves some more tricky options open for
later if we turn out to need tham.
Brian
Alain Durand wrote:
>
> On Friday, February 21, 2003, at 12:47 AM, Michel Py wrote:
>
> > Alain,
> > Your point is valid though, what about this:
> >
> > Proposed text:
> > RFC2374 was the def
> Proposed text:
> RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3)
> which is formally made historic by this document. Although as specified
> in [ARCH] IANA should limit the IPv6 Global Unicast address space to
> 2000::/3 for now, IANA might later delegate currently unassi
Alain,
> Alain Durand wrote:
> Oddly enough, from the same premises we arrived to opposite
> conclusions! If you leave the space out of 2000::/3 as
> 'unassigned' and I'm an implementor, I may put special
> code when sending a Unicast packet to make sure that SRC &
> DST addresses are within the v
On Friday, February 21, 2003, at 12:47 AM, Michel Py wrote:
Alain,
Your point is valid though, what about this:
Proposed text:
RFC2374 was the definition of addresses for Format Prefix 001
(2000::/3)
which is formally made historic by this document. Although as specified
in [ARCH] IANA should
Oddly enough, from the same premises we arrived to opposite conclusions!
If you leave the space out of 2000::/3 as 'unassigned' and I'm an
implementor, I may put special code when sending a unicast
packet to make sure that SRC & DST addresses are within the valid
range...
- Alain.
On Thursday,
Alain,
> Alain Durand
> RFC2374 was the definition of addresses for Format Prefix
> 001 (2000::/3) which is formally made historic by this document.
> Although, as specified in [ARCH], IANA should limit the IPv6
> Global Unicast address space to 2000::/3 for now, the rest of
> the unassigned IPv6
Michel Py wrote:
RFC2374 was the definition of addresses for Format Prefix 001
(2000::/3) which is formally made historic by this document. Although
as specified in [ARCH] IANA should limit the IPv6 Global Unicast
| address space to 2000::/3 for now, IANA might later delegate
| currently una
> Please consider this:
>
> RFC2374 was the definition of addresses for Format Prefix 001
> (2000::/3) which is formally made historic by this document. Although
> as specified in [ARCH] IANA should limit the IPv6 Global Unicast
> | address space to 2000::/3 for now, IANA might later delegat
> Erik Nordmark wrote:
> I think the "SLA" field in 2374 has been replaced by the "subnet ID"
> field in addr-arch-v3. It probably makes sense to make this clear by
> adding a note e.g.
>The SLA (subnet local aggregator) field in RFC 2374 remains in
>function but with a different name in [A
Erik,
> Erik Nordmark wrote:
> Isn't there some other document which contains the IETF's
> recommendation to IANA to hand out IPv6 prefixes to the RIRs?
> It would be better if we can refer to a document (which might
> evolve on its own) than explicitly state the range of
> prefixes in this docum
Erik Nordmark wrote:
>
> > Proposed title: "IPv6 Global Unicast Address Format"
>
> ok
>
> > Proposed text:
> >
> > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3)
> > which is formally made historic by this document. Although as specified
> > in [ARCH] IANA should limit
> Proposed title: "IPv6 Global Unicast Address Format"
ok
> Proposed text:
>
> RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3)
> which is formally made historic by this document. Although as specified
> in [ARCH] IANA should limit the IPv6 unicast address space to 2000::
> That being said, I have contradictory / ambiguous feelings about the
> omission of "SLA". Here's the contradiction:
>
> - On one side, since you explicitly kill TLA and NLA but not SLA, it is
> permitted to think that SLA is not completely dead, which suits me fine
> since my position is that a
> This is OK for me. I will plan add it to the next version of the
> draft. Would you like to be listed as an author?
I don't have a problem with that, but I suspect my wording can benefit from
some editorial tweaks.
> > > What did you have in mind that might further clarify this issue?
> >
Brian,
> Brian E Carpenter wrote:
> On balance, I prefer ducking the issue in the draft
> we are discussing. If I get a /48 I have 16 bits for
> subnet addressing and I'm happy, so why worry about
> the acronym SLA?
I have not been clear on this but I could not care less about the
acronym itself.
On balance, I prefer ducking the issue in the draft we are
discussing. If I get a /48 I have 16 bits for subnet addressing
and I'm happy, so why worry about the acronym SLA? The RIRs
have accepted the point (but I still want to see an informational
reference to 3177 to ensure the paper trail is com
OK for me
Brian
Michel Py wrote:
>
> Bob,
>
> > Bob Hinden wrote:
> > [Erik's text]
> > Any one else have comments on this change?
>
> Works for me.
>
> [the 2000::/3 prefix issue]
>
> Re-thinking it, my feelings are now that it would be good to remove it
> from the title, and that indeed
Erik / ipv6 folk,
> Erik Nordmark wrote:
> RFC 2374 contained an IPv6 allocation structure that
> included TLA (Top Level Aggregator) and NLA (Next
> Level Aggregator) which is formally made historic by
> this document.
> The TLA/NLA scheme has been replaced by an coordinated
> allocation policy d
Bob,
> Bob Hinden wrote:
> [Erik's text]
> Any one else have comments on this change?
Works for me.
[the 2000::/3 prefix issue]
Re-thinking it, my feelings are now that it would be good to remove it
from the title, and that indeed it is no different than the TLA/NLA
issue; in the same spirit t
Erik,
> Care to suggest some text?
RFC 2374 contained an IPv6 allocation structure that included
TLA (Top Level Aggregator) and NLA (Next Level Aggregator) which
is formally made historic by this document.
The TLA/NLA scheme has been replaced by an coordinated al
Erik Nordmark wrote:
...
> > What did you have in mind that might further clarify this issue?
>
> Remove "for the 2000::/3 Prefix" from the title and remove
> the mention of the specific prefix from the text.
>
> Apart from the restriction to 2000::/3 I don't see how section 2.0 adds
> anything b
> >If you want to be explicit about TLA/NLA being dead why not have
> >a section 2.0 titled "TLA and NLA are dead"
> >with a shortish explanation of why and with an informational reference
> >to the registries document?
>
> Care to suggest some text?
RFC 2374 contained an IPv6 allocation
Thomas / Brian / Bob,
>> Michel Py wrote:
>> Thomas, I can't argue with any of your other points, but you
>> might want to include the need to wrap this up soon in the
>> equation. I have not contributed what is in this message
>> before because I did not want to delay the process, and that
>> stu
Erik,
At 09:05 AM 2/12/2003, Erik Nordmark wrote:
> I agree with Michel. Although Thomas is logically correct,
> I think that including section 2.0 and putting this on
> standards track is a necessary signal to ensure that TLAs
> are really understood to be dead.
I too agree with this view. I
> I agree with Michel. Although Thomas is logically correct,
> I think that including section 2.0 and putting this on
> standards track is a necessary signal to ensure that TLAs
> are really understood to be dead.
If you want to be explicit about TLA/NLA being dead why not have
a section 2.0 title
> > Yes. Obsoleting 2374 is (from what I can tell) the point of this
> > document. IMO, putting more into the document than needed to achieve
> > just this is a distraction.
> I really don't find that the text you are objecting to is a distraction.
> I think it makes the draft more comprehensible
Thomas Narten wrote:
>
> "Michel Py" <[EMAIL PROTECTED]> writes:
>
> > > If Section 2.0 is removed, there is nothing in the document that
> > > needs to be on standards track.
>
> > I strongly disagree on this point and I think there is: some text and a
> > reference to RFC3177, and there's noth
Thomas Narten wrote:
>
> > I agree with Michel. Although Thomas is logically correct,
> > I think that including section 2.0 and putting this on
> > standards track is a necessary signal to ensure that TLAs
> > are really understood to be dead.
>
> Let me ask a pragmatic question. If this documen
"Michel Py" <[EMAIL PROTECTED]> writes:
> > If Section 2.0 is removed, there is nothing in the document that
> > needs to be on standards track.
> I strongly disagree on this point and I think there is: some text and a
> reference to RFC3177, and there's nothing in addr-arch-v3-11.txt.
Backgroun
> I agree with Michel. Although Thomas is logically correct,
> I think that including section 2.0 and putting this on
> standards track is a necessary signal to ensure that TLAs
> are really understood to be dead.
Let me ask a pragmatic question. If this document goes on standards
track, how will
Heikki Vatiainen <[EMAIL PROTECTED]> writes:
> If RFC 2374 will become historic, should
> draft-ietf-ipngwg-addr-arch-v3-11.txt be revised a bit so that it no
> longer refers to RFC 2374? Or is it already too late?
I don't see the reference to 2374 as being a significant
problem. Specifically, pa
I agree with Michel. Although Thomas is logically correct,
I think that including section 2.0 and putting this on
standards track is a necessary signal to ensure that TLAs
are really understood to be dead.
I also think the explicit reference to 2000::/3 is useful.
It's the only space currently bei
Thomas / Bob / Heikki,
> Thomas Narten wrote:
> [the introduction]
> As the above doesn't really have a lot of detail, some more
> explanation would be good.
Mumble. I have not said anything before not to delay the process, but
since it appears we're not going to have a no-brainer anyway, indeed
Margaret Wasserman <[EMAIL PROTECTED]> writes:
> This document will replace RFC2374 "An IPv6 Aggregatable Global Unicast
> Address Format", which is already a Proposed Standard RFC. RFC2374 will
> become historic.
If RFC 2374 will become historic, should
draft-ietf-ipngwg-addr-arch-v3-11.txt be r
> This is an IPv6 working group last call for comments on submitting the
> following document for consideration as a Proposed Standard RFC:
My assumption is that the purpose of this document is spelled out in
the introduction:
While this approach was originally thought to be a good way to
a
37 matches
Mail list logo
