Subject: RE: new rev. of rfc2462bis will be coming

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 3 Sep 2004 12:47:15 +0200

OK

It is certainly true that this is one of the things that is least likely to
change. 

Let's go with your latest update (in this mail)..

Reagrds,
elwyn 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 03 September 2004 11:21
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: [email-masked]'
> Subject: Re: new rev. of rfc2462bis will be coming
> 
> 
> >>>>> On Fri, 3 Sep 2004 11:57:36 +0200 , 
> >>>>> "Elwyn Davies" <[email-masked]> said:
> 
> > Getting the wording right without creating double 
> maintenance is a problem.
> 
> > The point is that an address prefix only specifies the 
> (prefix length) left
> > most bits.  RFC3513 has examples with essentially arbitrary 
> bits to the
> > right of the prefix.  FE80::0/10 implies but does not make 
> explicit what the
> > rest of the bits should be as well as putting back the 
> double maintenance
> > thing.
> 
> Okay, I see your first point.  Regarding the double maintenance issue,
> I still think it's controversial.  In addition to the points I raised
> in my previous message, we've already have several double-maintenance
> issues on the unicast link-local prefix: several RFCs has already
> hard-coded the concrete prefix of FE80::/10 or FE80::/64.  To name a
> few:
> 
>   RFC2464, RFC2472, RFC2491, RFC2497, RFC2590, RFC3146 (IPv6 
> over xxx links)
>   RFC2529 (6over4)
>   RFC2546 (6bone routing practice)
>   RFC3315 (DHCPv6)
>   ...
> 
> and I'm quite sure several other I-Ds also hard-coding the concrete
> prefix.
> 
> Will we really want to generalize the description for the existing
> RFCs when they are to be revised?  Also, do we really want to 
> "correct"
> all those I-Ds, before publication, not to hardcode the constant to
> avoid double maintenance problem?  I don't think so.  And if not, why
> is rfc2462bis so special?
> 
> So,
> 
> > How about:
> 
> > A link-local address is formed by combining the well-known 
> link-local prefix
> > [RFC3513] with the interface identifier as follows:
> ...
> 
> the organization of the suggested text looks fine, but I'd still
> rather be concrete on the constant.  And then the revised text would
> be as follows:
> 
> =========================== from here 
> =================================
> A link-local address is formed by combining the well-known link-local
> prefix FE80::0 [RFC3513] (of appropriate length) with the interface
> identifier as follows:
> 
> 1. The left-most 'prefix length' bits of the address are the link
>    local prefix
> 2. The bits in the address to the right of the link-local prefix are
>    set to all zeroes
> 3. If the length of the interface identifier is N bits, the right-most
>    N bits of the address are replaced by the interface identifier.
> 
> If the sum of the prefix length and N is larger than 128 ...
> =========================== to here 
> ===================================
> 
> Can we live with this?
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Sep 2004 20:08:37 +0900

>>>>> On Fri, 3 Sep 2004 12:47:15 +0200 , 

> Let's go with your latest update (in this mail)..

Okay, thanks!

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Fri, 03 Sep 2004 08:39:27 -0400

The proposed text looks ok to me as well.

Regards,
Brian