I agree with Thomas. The reason I and Wes could reply with some ideas is because we are familiar with the cable deployment and contributed text for ND Proxy behavior in cable standards. A start for diagram may be RFC4779 that DSL folks should look at and tell us what they talking about. If a DSL deployment doesn't exist in RFC4779, then for long-term one should bis RFC4779 to include the new DSL deployment so that all can reference a common doc and discuss deployment problems for IPv6.
Hemant -----Original Message----- From: savi-boun...@ietf.org [mailto:savi-boun...@ietf.org] On Behalf Of Thomas Narten Sent: Friday, November 06, 2009 2:18 PM To: Stark, Barbara Cc: 6man-...@tools.ietf.org; SAVI Mailing List; savi-...@tools.ietf.org; james woodyatt; v6ops-...@tools.ietf.org; IPv6 Operations; IETF IPv6 Mailing List Subject: Re: [savi] Broadband Forum liaison to IETF on IPv6 security > The liaison was posted in March 2009. It can be found here: > https://datatracker.ietf.org/documents/LIAISON/file621.doc This is too skimpy of problem statement for me to understand the details of the problem. I don't know that a lot is needed. Maybe 2-3 pages is enough. But show me a diagram, label the pieces, show me the properties of the pieces and explain what the *exact* problem is. Who needs to do DAD? Why doesn't it work? etc. And note that comments like (quoting from the above statement): "We can envision a number of scenarios, both malice or vendor incompetence by which this can happen." There is very little anyone can do to prevent "vendor incompetence". I hope you aren't asking the IETF to solve this problem! :-) Thomas _______________________________________________ savi mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/savi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
