Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"

From: "Michel Py" <[email-masked]>
Date: Wed, 12 Feb 2003 18:47:37 -0800

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
>> stuff still can wait, IMHO.

> Thomas Narten wrote:
> The above could be read to suggest that this document is so
> important that no changes are appropriate at this point. I
> have hard time with that, given that we've needed this
> document for something like 2+ years, and it has been a mere
> 10 days since the -00 version appeared.

There is some truth to this, although this document was not the concern
but draft-ietf-ipngwg-addr-arch-v3-11.txt going forward. It is even more
urgent that we obsolete RFC2373 than 2374. Per some traffic on a RIPE
list today, some people are still stuck with EUI-64 in their mind, this
is not good.

Since I don't recall this being discussed before, I made (possibly
wrongly) the default assumption that the author's intentions were to do
a pair of documents in the standard tracks that would be a one-for-one
replacement of 2373/2374. To the extent that I could try to second-guess
Pekka, I think that I am not the only one. Someone please debunk me if
needed, but I have in the back of my mind that if addr-arch has not been
published yet is because it's waiting for this document to ship. Hence
the "importance".

>> Michel Py wrote:
>> In short: the bottom line is that the site boundary is now defined
>> by RFC3177, which is what the RIRs call a semi-hard boundary. Given
>> the intricate relations with architecture and scope, I don't see
>> how a reference to it could be left out of the standards track.

> Thomas Narten wrote:
> Per above, this is not part of the architecture. This is policy
> (and good policy, IMO). I do not think it is appropriate to hard
> wire this into our specifications.

I am not proposing that we change this. All that I was trying to say is
that I would have wished to give more importance to 3177, but if the
consensus is that we have declared victory once and for all, so be it
whether I like it or not. I have done my job reminding the list that
although RFC3177 is policy, it still has some strong ties to
architecture. I think that what I'm not happy about is that as an
afterthought I would have preferred 3177 to be BCP.

> IMO, we should declare victory and stop worrying about this.
> There is no need to for the IETF to make further statements
> about the /48 boundary at this time. I would also argue that
> it is wrong to try to push that boundary into an architecture
> or standards track document,

I would agree that it is wrong to push that boundary back into
architecture, but I think we went one step too far from having it in the
architecture to the point that we say "we don't know, we don't care and
we don't even want to hear about it."

> as there is no technical implication on implementations.

There might be a need later. In MHAP, I have a hard /48 boundary for
optimization purposes. I needs to be debated whether or not it's a good
idea in that context, but I think that we should not totally close the
door to going back to a thinking that might be a little harder on the
boundary.

> (Indeed, rather the opposite -- we take great steps to ensure
> that no implementation will incorrectly assume such a boundary
> exists and hard code it into the implementation.)

I agree for the basic IPv6 stack, but again there could be some future
spin-offs.

> 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.

Mmmm. I still think that what Bob did trying to sneak in the
documentation prefix was a good idea, since he also pulled it at the
first sign of trouble.

> Brian Carpenter wrote:
> If the draft attempted to make a normative reference to 3177,
> it would be a blunder.
> ....
> It's a very light reference to 3177. I think it's useful to make
> the point that the RIR policy and the IAB/IESG recommendation are
> consistent. It's a footnote though.

Reluctantly settles for a footnote.

> Bob Hinden wrote:
> While I don't feel too strongly about that status of the document,
> I share the belief that is important to send a "strong" message.
> Perhaps classifying it as a BCP might be a good middle ground.

I'm with Bob and Brian on the "strong" signal, a BCP would be a good way
to reach consensus.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Fri, 14 Feb 2003 07:42:15 -0800

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. Killing the acronym is fine, what I think we need to
preserve is the concept that there is a boundary there.

> (but I still want to see an informational reference to
> 3177 to ensure the paper trail is complete).

Agree.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Feb 2003 20:24:42 -0800

> 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 [ADDR-ARCH]; its new
>    name is "subnet ID".

I like this. I was looking at some phrasing that would include the word
"boundary" or "broder" but I can't formulate anything good.

Food for the thought: might be a good idea to include a hint that the
"subnet ID" bits are likely part of the scope of the site.

Michel.