On 22 Oct 2012, at 10:08, Arifumi Matsumoto <[email protected]> wrote:
> Brian, > > 2012/10/16 Brian E Carpenter <[email protected]>: >> Hi, >> >> I support this draft but have a couple of comments. >> >>> A: Automatic Row Addition flag. This flag toggles the Automatic >>> Row Addition flag at client hosts, which is described in the >>> section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, it >>> does not change client host behavior, that is, a client MAY >>> automatically add additional site-specific rows to the policy >>> table. If set to 0, the Automatic Row Addition flag is >>> disabled, and a client MAY NOT automatically add rows to the >>> policy table. >> >> This text includes "MAY NOT" (in upper case). This is specifically not >> covered by RFC 2119 because it's unclear. I think we want "MUST NOT" >> instead. Or do we want "SHOULD NOT"? The existence of this flag is >> a "SHOULD" in RFC 6724. > > Oops. Thank you for pointing this out. > > I think "SHOULD NOT" is better. > As we do not prohibit manual policy table configuration, so "MUST NOT" > should not work. Yes, that sounds better. >>> P: Privacy Preference flag. This flag toggles the Privacy >>> Preference flag at client hosts, which is described in the >>> section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, it >>> does not change client host behavior, that is, a client SHOULD >>> prefer temporary addresses. If set to 0, the Privacy Preference >>> flag is disabled, and a client SHOULD prefer public addresses. >> >> I am a little bothered by those two SHOULDs. It seems to me that they subtly >> modify what is said in RFC 6724, where the relevant text is quite subtle >> already. I would prefer to see the two SHOULD clauses deleted. Alternatively, >> s/SHOULD/will/ would better align the text with RFC 6724. > > It sounds good to me. We're drifting into similar territory as the M and O flags here. There was pushback before against introducing an RA option to indicate whether privacy addresses should be used. So again here I think the flag should be no more than a hint. It might be good to say 'prefer privacy addresses *where enabled*'. I think if they're not enabled, e.g. on some server that shares a link with clients, then the server should not take this hint to enable privacy addresses. The main use case here seemed to be that raised by Eric, i.e. to avoid the use of privacy addresses for ULAs within the same site. >> Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used. > > I'll delete in the revision. I think the stable privacy address draft is good and hope it will progress, but I agree it's not needed here. I guess the question is whether such addresses count as public or temporary. The idea of these addresses is to replace the SLAAC-based public address, so if we did add a note it would just be to clarify that. Tim > Thanks. > >> Regards >> Brian Carpenter >> >> On 10/10/2012 09:28, Ole Trøan wrote: >>> All, >>> >>> This message starts a two week 6MAN Working Group on advancing: >>> >>> Title : Distributing Address Selection Policy using DHCPv6 >>> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >>> Filename : draft-ietf-6man-addr-select-opt-06.txt >>> Pages : 10 >>> Date : 2012-09-21 >>> >>> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >>> >>> as Proposed Standard. Substantive comments and statements of support for >>> advancing this document should be directed to the mailing list. Editorial >>> suggestions can be sent to the authors. This last call will end on 24. >>> October 2012. >>> >>> Regards, >>> >>> Ole Trøan & Bob Hinden >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
