Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Mar 2003 22:36:35 -0800

> Pekka Savola wrote:
> So, I believe everything starting from:
>  [ARCH] also requires that all unicast addresses, except those
>  that start with binary value 000, have Interface IDs that are
>  64 bits long   and to be constructed in Modified EUI-64 format.
>  The format of global unicast address in this case is: [...]
>  should be removed, if not the whole section.

I think it should be kept. There is a logical progression in section
3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is
an example, but the progression from the generic v6 format seems very
logical to me and examples are generally good.

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: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 17:12:21 +0200 (EET)

> logical to me and examples are generally good.

A reference to the IESG/IAB recommendation -- or the RIPE policy document 
-- is clear enough, IMO.

And this avoids the follow-up issue that it isn't IMO the good thing to
have _IETF_ document decisions made by _RIR_'s.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2003 11:05:41 +0100

> logical to me and examples are generally good.

It should certainly be kept. The document is misleading without
it, unless the reader has been reading this list all his/her
life.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2003 18:02:15 +0100

> have _IETF_ document decisions made by _RIR_'s.

This hasn't happened. We are trying to publish something that stops
at the point where IANA delegation starts.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 19:17:54 +0200 (EET)

> at the point where IANA delegation starts.

My perception is that the /48 "border" is inside the IANA delegation. (As 
is /64, but that's a different issue).