Sri and other authors,
Could you please note that the key change in your document is what Wes has emailed today to us. However, I am puzzled by the normative text in your document for the key change. If a host decides to transmit an IPv6 multicast message as a link-layer unicast message, then as per your receiver specification, a receiver is still legal to drop such a message. All you have is a "SHOULD NOT drop" which an implementation can still not adhere to and drop the message. If the receiver drops this doctored multicast message, then your goal is not even met. I think only a "MUST NOT drop" meets your needs. It would be good to articulate what set of problems are we trying to solve and then we will see what solutions are needed including any changes to existing RFC's. I have already asked once in the mailer for what specifications exist in the IETF that document the problem cases enumerated by DSL folks or wireless LAN folks. Thanks, Hemant From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Wes Beebee (wbeebee) Sent: Monday, August 02, 2010 12:31 PM To: Fred Baker (fred); IPv6 Operations; 6man Mailing List Cc: Kurt Erik Lindqvist Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC In case people haven't had time to read the whole draft, the key standards track change to existing RFC's is: "An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message containing a multicast destination address in the IPv6 header, but with a unicast destination address in the link-layer header, withstanding all other validity considerations as specified in the relevant IPv6 standards specifications." "An IPv6 sender node MAY choose to transmit an IPv6 multicast message as a link-layer unicast message." - Wes On 7/31/10 1:54 AM, "Fred Baker" <f...@cisco.com> wrote: This is to initiate a two week working group last call of draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the combined lists. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. ________________________________ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
