Hi, Yao.
We already did.:-)
Phase1 LOGO requires only MUST,
Phase2 LOGO requires MUST and SHOULD.
Thanks,
On Wed, 30 Jan 2008 15:56:22 -0700
Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> Hi Yukiyo,
>
> In my opinion, a better way to resolve the arguments about "should"
> "may" may be to create different "level"s of conformance and give users
> option whether he wants to pass "should" or "may" cases. If a vendor
> passes "must", he gets "basic" logo, "should" - silver, "may" - gold.
> Wouldn't it be better to solve this problem that way?
>
> Thanks,
> Yinghui Yao
> Alcatel-Lucent
>
> Yukiyo Akisada wrote:
> > Hi, Karsten.
> >
> > Thanks for your comments.
> >
> > I know that it is SHOULD,
> > but our test tool supports the test specification
> > published by IPv6 Ready Logo Program <http://www.ipv6ready.org/>,
> > and basically the test specification supports all of MUST and SHOULD.
> >
> > You may know,
> > now IPv6 Ready Logo Committee is also discussing
> > about the next major revision up of test specification.
> >
> > URL: <http://www.ipv6ready.org/announcement/public_review20071204_p2core.html>
> >
> > RFC 4862 Section 5.4.5 is one of discussing point.
> >
> > The public review has been over,
> > but if you have strong concern about it,
> > I recommend to comment to <ipv6ready-info@ipv6ready.org>.
> >
> > Personally,
> > I think that mandating this function is the best way.
> > But vendor's input will really important for them.
> >
> > Regards,
> >
> >
> > On Wed, 9 Jan 2008 16:48:10 +0100
> > Karsten Keil <kkeil@suse.de> wrote:
> >
> >
> >> On Wed, Jan 09, 2008 at 08:56:49AM +0900, Yukiyo Akisada wrote:
> >>
> >>> Hi, Karsten.
> >>>
> >>> Please check RFC 4862 (IPv6 Stateless Address Autoconfiguration).
> >>>
> >>> Section 5.4.5 says,
> >>>
> >>> 909 If the address is a link-local address formed from an interface
> >>> 910 identifier based on the hardware address, which is supposed to be
> >>> 911 uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
> >>> 912 operation on the interface SHOULD be disabled. By disabling IP
> >>> 913 operation, the node will then:
> >>> 914
> >>> 915 - not send any IP packets from the interface,
> >>> 916
> >>> 917 - silently drop any IP packets received on the interface, and
> >>> 918
> >>> 919 - not forward any IP packets to the interface (when acting as a
> >>> 920 router or processing a packet with a Routing header).
> >>>
> >>>
> >> Yes, but it states SHOULD be disabled, not MUST be disabled.
> >> I think it should only check, that the address is not assigned, to be conform to
> >> RFC 4862.
> >>
> >> I agree that disabling the interface makes sense and is the better approach
> >> to handle the situation, but not disabling the interface is still a valid
> >> option I think.
> >>
> >> --
> >> Karsten Keil
> >> SuSE Labs
> >> ISDN and VOIP development
> >> SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
> >>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> > Yukiyo Akisada <akisada@tahi.org>
> >
> >
>
>
>
------------------------------------------------------------------------
Yukiyo Akisada <akisada@tahi.org>