To: "SAVI Mailing List" <savi at ietf.org> Cc: "Bill Fenner" <fenner at fenron.com> Sent: Sunday, September 06, 2009 4:04 AM Subject: [savi] Consensus call on separate documents for DHCP and SLAAC
Dear all - The SAVI working group has so far taken the approach to specify the validation of DHCP-assigned IP source addresses and SLAAC-assigned IP source addresses in a single document. However, arguments have been made, and were discussed at the SAVI meeting in Stockholm, that a better approach would be to specify the two types of validation in separate documents, and to produce a framework document that describes the relationship between, and common principles of, the various IP address validation types. The bottom-line of these arguments is that the separation would be (a) justifiable and recommendable due to enough differences between the validation of DHCP-assigned and SLAAC-assigned IP source addresses, (b) in line with the working group's approach to also use separate documents for the validation of SEND-assigned IP source addresses, and IP source address validation in broadband access networks. This is a consensus call on whether the SAVI working group should change its approach towards producing separate documents for the validation of DHCP-assigned IP source addresses and SLAAC-assigned IP source addresses, plus a framework document. Please answer either "yes" or "no" to the following question: Should the SAVI working group produce separate documents for DHCP- assigned IP source addresses and SLAAC-assigned IP source addresses,plus a framework document that describes the relationship between, andcommon principles of, the various IP address validation types?
Dear WG members,I believe that's the consensus we agreed during IETF75. My answer is "yes".
Best Regards, Jun Bi
Please respond by Sunday, September 13, 2009. - Christian _______________________________________________ savi mailing list savi at ietf.org https://www.ietf.org/mailman/listinfo/savi
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.