Sean Turner has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- s6.1, para 1: When won't using SEND without a proxy break the security? I think what you're trying to say is that using plain old SEND won't work you've got to use SEND with the proxy - right? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Is the word "proxy" missing from the following in the abstract: The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. s1 use "proxy" after DAD and then s1 para 2 says: This document explains also why DAD mechanism [RFC4862] cannot be used in a point-to-multipoint architecture with "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not affected). And could we make it clear that a proxy is needed: This document explains also why DAD mechanism [RFC4862] without a proxy cannot be used in a point-to-multipoint architecture with "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not affected). 2) s4.2: Some minor wording tweaks because I don't know what the MUST pertains to: OLD: perform actions depending on the information in the Binding Table. NEW: perform actions specified in the following sections based on the information in the Binding Table. 3) s4.2.1/s4.2.2: What happens if the BNG does reply/forward? 4) s4.1/s4.2.2: Is the neighborhood cache in s4.2.2 the same thing as the binding table in s4.1? 5) s4.2.3.2: L2 header: Which link-layer address is returned to CPE2? Is it it's own or the one from CPE1? 6) s6.1: Agree with Barry's SHOULD vs MUST discuss. 7) s6.2: r/To ensure a protection/To ensure protection 8) s6.2: not sure you really need the MAY. Maybe r/MAY/can -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
