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

From: "Michel Py" <[email-masked]>
Date: Mon, 10 Feb 2003 19:48:51 -0800

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
some more explanation would be good.

> For example, I still see people occasionally make statements
> about how IPv6 address allocation will enforce some sort of
> strict heirarchy (this comes from reading 2374, which this
> one is obsoleting). Explicitly explaining why that thinking
> is no longer in vogue would seem useful.

As detailed below, a distinction must be made between the TLA/SLA
situation on one side and the SLA on another.

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

Rationale: We moved three hard boundaries from architecture to policy,
the TLA, NLA and SLA. It was clear that the multi-tiered structure of
service providers was a matter of allocation and not of architecture, so
the TLAs became LIRs, the way they allocate space to lower tiers is none
of the IETF's business and all the RIR's.

This reasoning is not valid for the SLA boundary though, because
although we removed the notion, the block of addresses assigned to an
organization will still define the site boundary in most situations. The
site boundary has deep consequences on architecture and scope.

Indeed, TLAs and SLAs are gone and this is the RIR's business that we
don't want to deal with. However, while the SLA is gone, the site
boundary remains and this still is our business by the RIR's reading:

> [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html]
> 5.4. Assignment
> LIRs must make IPv6 assignments in accordance with the
> following provisions.
> 5.4.1. Assignment address space size Assignments are to be made in
> accordance with the existing guidelines [RFC3177, RIRs-on-48],
> which are summarized here as:
> /48 in the general case, except for very large subscribers 
> /64 when it is known that one and only one subnet is needed by design
> /128 when it is absolutely known that one and only one device is
> connecting.

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.

> Indeed, given that none of section 2 is new, it all restates
> stuff on addr-arch, I don't think even this document should go
> on standards track. Having this document be info, and obsoleting
> 2473 would work just fine process wise.

> Heikki Vatiainen wrote:
> 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?

On paper, it's not a bad idea, but we would need to recall addr-arch to
do that, go over last call again. We might have to revisit the /64 hard
boundary, the "u" bit and the site-local thing again (for the, what? 6th
time?) and possibly have to deal with more appeals. It is urgent to
obsolete 2374.

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.

For the sake of having RFCs reasonably in sync with reality, can't we
ship two documents on the standards track now and obsolete both of them
in the next iteration of addr-arch that would be a single doc? The
architecture will continue to evolve, but we need to set a milestone
from time to time.

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: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Feb 2003 10:42:13 +0100

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

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Feb 2003 08:49:07 -0500

> reference to RFC3177, and there's nothing in addr-arch-v3-11.txt.

Background: 3177 is a recommendation and represents current
thinking. It is not an architectural statement. The /48 boundary is
100% policy. The RIRs have taken that input, and have largely accepted
it. This is reflected in the current IPv6 allocation policies, which
have been adopted by APNIC, ARIN and RIPE. E.g., see:
http://www.arin.net/policy/ipv6_policy.html.

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,
as there is no technical implication on implementations. (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.)

> site boundary has deep consequences on architecture and scope.

I disagree. Per above, this is not architecture, it is policy.

> reference to it could be left out of the standards track.

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.

> time?) and possibly have to deal with more appeals. It is urgent to

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.

> delay the process, and that stuff still can wait, IMHO.

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.

One can get documents done quickly, so long as there is rapid
discussion, iteration and convergence. Let me suggest we try this
first. There is a time to surpress the urge for changes in a document,
but it seems a little early to be there for this one.

> architecture will continue to evolve, but we need to set a milestone

I see no need to tie this document with the already approved
2374bis. If a merge is needed, we can do that later.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Feb 2003 08:49:14 -0500

> are really understood to be dead.

Let me ask a pragmatic question. If this document goes on standards
track, how will this document advance up the Standards Track? What
will the implementation reports contain and actually test? I don't see
immediately anything that is testable. This is one of the reasons I
don't see Standards Track is being the right classification.

> It's the only space currently being allocated.

I'm not sure what this means. If we want to say only 2000::/3 is
currently allocated, that might be fine. But the current document
doesn't say that (indeed, it says nothing about what has and has not
been allocated). Instead, it talks about formats. And why aren't the
words in addr-arch good enough about the 2000::/3 allocation?

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Feb 2003 16:02:49 +0100

> don't see Standards Track is being the right classification.

Good point (but doesn't it also apply to the address architecture
to a large extent?). BCP is our usual way out of that. I stick
to me feeling that we need a stronger signal than Informational,
but I wouldn't go to the wall over it.

> words in addr-arch good enough about the 2000::/3 allocation?

They are OK. If we were just writing mathematical theorems, they
would be sufficient; as I said you are logically correct. I just
think we need to make the point in a short stand-alone document,
even if there is some redundancy.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Feb 2003 16:20:11 +0100

> http://www.arin.net/policy/ipv6_policy.html.

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.

> code it into the implementation.)

Agreed, and the draft doesn't do that.

> I disagree. Per above, this is not architecture, it is policy.

I agree with Thomas, but the draft doesn't go there anyway.

> good policy, IMO). I do not think it is appropriate to hard wire this

Correct. If the draft attempted to make a normative referennce
to 3177, it would be a blunder. But it doesn't.

> 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. But it's a judgement
call, so I'd like some other people to comment.

> 2374bis. If a merge is needed, we can do that later.

I assume you mean 2373bis. I don't see why a merge would be needed. 
We do need to delete the reference to 2374 in 2373bis, but
that's editorial.

    Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Feb 2003 14:04:25 -0500

> call, so I'd like some other people to comment.

Agreed.

Trying to make this document a Proposed Standard is what makes me
uncomfortable. There is nothing in it that is defining anything new in
a standard's sense (at least, AFAIK).  If it were informational, this
issue would just go away.

I guess some are arguing informational is not a strong enough signal,
but I don't personally agree with that. Reclassifying a document as
historic, and obsoleting it seems pretty clear to me.

[side note: the MUST/MAY definitions can now be removed as they are no
longer used.]

> to a large extent?). BCP is our usual way out of that.

Similar reasoning applies to addr arch. I think that making it a BCP
might in retrospect also have been an alternative approach.  But, that
document also has a lot more in it, so it's easier to find stuff in
that is clearly implementation related. But there is also pieces where
the connection is not immediately obvious...

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Feb 2003 14:14:51 -0500

I agree that Informational is the correct level.  I also
don't see anything in the doc that is "new" and needs to
be a Standard.

Regards,
Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Feb 2003 18:05:38 +0100 (CET)

> are really understood to be dead.

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?

> It's the only space currently being allocated.

Because this might confuse people that they should only code for 2000::/3
in their implementation?

We tried to make this clear in addr-arch-v3 (hopefully clear enough) but
this document is not clear enough on that issue.

Since RFCs live forever the "currently being allocated" argument might
not be a good argument.

Finally, assuming that this document isn't going standardize anything
(now that the documentation prefix is removed) I think it makes
sense having be an informational document that is part of a protocol
action which moves RFC 2374 to historic.
Only if this document standardizes some replacement to 2374 would it make
sense for it to be proposed standard.

Examples of "move to historic" documents are RFC 3197 and RFC 3167.
They tend to explain why and what is being made historic with varying levels
of detail.

  Erik

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Feb 2003 10:12:43 -0800

Erik,

> > are really understood to be dead.

I too agree with this view.  I tried to write this draft to be as 
uncontroversial as possible so it could proceed quickly and accomplish the 
goal of replacing RFC2374.

>to the registries document?

Care to suggest some text?

>Because this might confuse people that they should only code for 2000::/3

I don't see how one could come to this conclusion.

The draft was written to only cover the 2000::/3 prefix because the 
document it is obsoleting also only covers that prefix.  For example from 
section 2.0 of RFC2374:

    This document defines an address format for the 001 (binary) Format
    Prefix for Aggregatable Global Unicast addresses. The same address
    format could be used for other Format Prefixes, as long as these
    Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
    Format Prefix is defined here.

Making it apply to other prefixes seemed out of scope to me.

>this document is not clear enough on that issue.

What did you have in mind that might further clarify this issue?

>They tend to explain why and what is being made historic with varying levels

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.

Bob

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Feb 2003 10:39:48 +0100 (CET)

> 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 allocation policy 
	defined by the Regional Internet Registries [REF].

	Part of the motivations for obsoleting the TLA/NLA structure
	were technical, for instance there was concerns that it was not
	the technically best approach at this point in time on IPv6 deployment.
	Another part of the motivation was that the issues of how the
	IPv6 address space is managed is much more related to policy and
	to the the stewardship of the IP address space and routing table
	size that the RIRs have been managing for IPv4.	It is likely that 
	the RIRs policy will evolve as IPv6 deployment proceeds.

	The IETF has provided technical input to the RIRs
	(for example [RFC 3177]) that has been taken into account
	when defining the policy.

> document it is obsoleting also only covers that prefix.  For example from 

I agree that RFC 2374 only covers that prefix.
But that doesn't mean that the docment which makes 2374 historic 
needs to have the same limitation.

> 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 beyond what is in addr-arch. Perhaps I'm missing something.

> classifying it as a BCP might be a good middle ground.

But the strong message would be that there would be an IETF last call
saying that RFC 2374 is moving to historic and this doc informational.
Then this will be permanently recorded in rfc-index with 2374 being marked
as historic.

This seems to be strong enough for other protocols/documents we've made 
historic such as RIPv1 (with RFC 1923 being the info doc that explains
why).

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Feb 2003 17:18:10 +0100

Erik Nordmark wrote:
...
> anything beyond what is in addr-arch. Perhaps I'm missing something.

It doesn't add anything but it clarifies things that many people
who are not on this list have misunderstood (or they have read in
text books with obsolete content). I really think it is useful
text.

It should mention 2000::/3 in my opinion, because we are *redefining*
the way we use 2000::/3. But it should indeed point out that
architecturally, 2000::/3 is not special.

Since it is somewhat redundant with addr-arch, I now agree that
Informational is OK.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Feb 2003 16:42:11 -0800

Erik,

>         when defining the policy.

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?

Any one else have comments on this change?

>the mention of the specific prefix from the text.

OK, that is clearer.  It wouldn't be too hard to make this change, but 
there doesn't seem to be complete agreement on the list for this change.

>anything beyond what is in addr-arch. Perhaps I'm missing something.

I think it provides a summary of what the resulting address format for this 
prefix (and other prefixes if the above change is made).  Since we now seem 
to heading toward a non-standards track document, what is the harm?

>historic such as RIPv1 (with RFC 1923 being the info doc that explains

The RIPv1/v2 case seems fairly different to me, because the RIPv2 existed 
for a long time before RIPv1 was made historic.

I now agree that it can be non-standards track.  What was your objection to 
making it a BCP?  In some ways this is the best current practice.

Bob

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 14:17:26 +0100 (CET)

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

> to heading toward a non-standards track document, what is the harm?

Hmm - based on Brian's comment it might make sense to say
that the document explicitly redefines the structure in 2000::/3
to be the god'ol basic addr-arch structure of "bits+subnet+iid".
Thus having section 2.0 to explicitly point out that this is the replacement
for the format in 2374 makes sense to me.
But the "replacement" part needs to be made very clear.

> making it a BCP?  In some ways this is the best current practice.

I don't see any "practise" in the document. Perhaps I'm missing something.
If there is practise, for instance suggesting that the same address format
can be useful for both providers and exchanges, then BCP might make more
sense.  But it isn't clear to me whether the WG sees the benefits of restating
that aspect of 2374 in this document.

  Erik