Hi Suresh, Good to hear that you will be clarifying the draft. I take it that showing the full intended RS/RA message exchange will be part of that clarification.
Thanks, Woj. On 20 August 2010 01:06, Suresh Krishnan <[email protected]>wrote: > Hi Brian, > Thanks for the comments. I will submit a revised version tomorrow. > > > On 10-08-19 12:26 PM, Brian Haberman wrote: > >> Suresh, >> >> On 8/19/10 9:43 AM, Suresh Krishnan wrote: >> >>> Hi Woj, >>> >>> On 10-08-19 09:22 AM, Wojciech Dec wrote: >>> >>>> There seems to be reason to explain the context/workings more clearly, >>>> both in terms of multicasting an RA and the overall expected BBF usage. >>>> >>> The draft describes how the sender of the RA deals with a tunneled RS >>> with a LIO. No RS received, nothing in the draft is applicable. >>> Multicasting an unsolicited RA is performed as per RFC4861/RFC4862. This >>> is not something covered in the draft. I am not sure what you want me to >>> explain here. As the editor of the BBF spec in question, I would have >>> thought that you would be more qualified than me to explain the BBF >>> usage. >>> >> >> I think there is some misunderstanding going on here and I believe it >> may have to do with the lack of detail (and maybe some typos) in the >> draft. It appears that sections 5 & 6 could be made more clear with a >> few additions. >> >> First, it would be useful to expand all the acronyms in Figure 1 so that >> there is a clear understanding what the roles are of all the nodes in >> the diagram. A *short* description of each node's role would be quite >> useful. >> > > Sounds good. Will do. > > > >> Second, it would be useful if the text in sections 5 & 6 referenced the >> figure so that we know what nodes are originating which messages. For >> example, section 5.1 talks about receiving an RS from a subscriber, but >> there is no node in the diagram labeled as the subscriber. Which node >> sends that RS? >> > > I will modify the figure to show the host that sends the RS. > > > >> Finally, I found the section heading of 6.1 confusing. It references a >> subscriber, but the text only talks about the access node. One can >> infer how this works, but it would be better if it was clarified so that >> we don't have differing views of what is going on. >> > > OK. > > Thanks > Suresh > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
