Re: Broadband Forum liaison to IETF on IPv6 security
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Broadband Forum liaison to IETF on IPv6 security
- To: "Stark, Barbara" <bs7652 at att.com>
- Subject: Re: Broadband Forum liaison to IETF on IPv6 security
- From: Thomas Narten <narten at us.ibm.com>
- Date: Fri, 06 Nov 2009 14:17:58 -0500
- Cc: 6man-ads at tools.ietf.org, SAVI Mailing List <savi at ietf.org>, savi-ads at tools.ietf.org, v6ops-ads at tools.ietf.org, IPv6 Operations <v6ops at ops.ietf.org>, IETF IPv6 Mailing List <ipv6 at ietf.org>
- Comments: In-reply-to "Stark, Barbara" <bs7652 at att.com> message dated "Fri, 06 Nov 2009 13:56:02 -0500."
- Delivered-to: ipv6 at core3.amsl.com
- In-reply-to: <7582BC68E4994F4ABF0BD4723975C3FA10C3768C at crexc41p>
- List-archive: <http://www.ietf.org/mail-archive/web/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- References: <AFC1ACFB-FDFA-482C-AAF9-7995F5CEFE1F at broadband-forum.org><F311A255-3303-4C9D-B270-D1D23DE31E31 at cisco.com><200911061358.nA6DwXNq025458 at cichlid.raleigh.ibm.com> <B52C3C2B-924A-4454-B863-57B02F54E5D4 at apple.com> <7582BC68E4994F4ABF0BD4723975C3FA10C3768C at crexc41p>
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.