Tatuya,

If it's too late, it's fine.  On a different note, did you catch the
fact from Vlad who wanted  "should" changed to "SHOULD" in a paragraph
on page 18 of 2462bis? Further, we are also adding that a "should not"
in the same paragraph be changed to "SHOULD NOT". Do you or anyone else
think such a change can be made before the 12 hours expire? This is the
relevant paragraph:

      Note that a future revision of the address architecture [RFC3513]
      and a future link-type specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.

Thanks.

- Hemant & Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 09, 2007 1:09 PM
To: Hemant Singh (shemant)
Cc: Vlad Yasevich; ipv6@ietf.org
Subject: Re: Sending traffic to default router when RA has no PIO

At Mon, 9 Jul 2007 11:22:16 -0400,
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:

> Tatuya, please note another proposed change by Vlad to 2462bis and 
> also Vlad agrees that a change regarding skipping DAD should be made 
> to 2462bis as per this statement from Vlad: "I would agree to adding 
> the rationale for why skipping DAD is not recommended."

As (probably) indicated by Vlad, I don't think we have formed a clear
"consensus" in the "wg as a whole" that warrants a further change to
2462bis at this late stage.  At least I'm not convinced about making the
change to 2462bis at this timing, although I'd support the stricter
requirement of DAD in a separate document (maybe an implementation
guidance as Suresh suggested?) if we agree on it after discussions in
the wg.

I strongly believe 2462bis is pretty good in its current form, and even
though further discussions and resulting possible changes to the
document based on a wg consensus may make it 120% perfect, I don't think
the benefit isn't worth the publication delay.

My current plan is to submit the current version to the RFC editor in 12
hours or so, unless I see a clear wg consensus on the change by then.
(For that matter, I'd disagree on introducing this change to this
document at this stage)

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba
Corp.
                                        [EMAIL PROTECTED]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to