Ballot for draft-ietf-dhc-relay-server-security
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
"This document specifies the optional requirements for relay agent and server implementations to support IPsec authentication and encryption and recommends operators enable this IPsec support." Thank you, this adequately addresses my discuss.
Thank you for writing this document. I am curious to know whether there are existing or planned implementations/deployments of this document. I am also agreeing with Warren concerns.
I am balloting "Yes", but I share the curiosity about whether people will really do this. -3, third paragraph: "MUST exchange messages securely" "Securely" is too ambiguous for a MUST. What specific protections are required? -3, paragraph 4: The list starts with no context. A sentence or paragraph describing the purpose of the list would be helpful.
Thank you very much for your work on this document. Once Warren's discuss has been cleared with adequate clarifications and 'updates' text, which I support, this will be a helpful document. It will be very nice to no longer have the discussion as to why encryption is not required for DHCP, this is a welcome and overdue change. Is there an expected change to encrypt the full path in a future revision?
I agree with both Warren's discuss and Benoit's comments about balloting being easier when others have already done so :-)
I agree with Warren's confusion about the relationship between this document, RFC3315 and draft-ietf-dhc-rfc3315bis.
The advantage of a late review is that everything has been said already by other ADs :-)
Agree with other ADs' comments.
Based on e-mail it seems like at least one company is implementing. Personally, were I voting, I'd vote against making an MTI that I expect almost nobody to follow, but I concede that there's not sufficient evidence of that to hold a discuss here.
I strongly agree with Warren's discuss. This document is an update of RFC3315 and therefore MUST carry the update tag. If someone decides not to implement this new specification, they will still only confirm to RFC3315 and not this new document. As Warren said, someone who wants this encryption needs to require conformance to this new RFC anyway. However I think the IETF should give a clear recommendation here that encryption must be used. If the working group really believes there are cases where encryption is not needed, this document must be rewritten to allow for these cases (by using SHOULD/RECOMMENDED instead of MUST/REQUIRED) and give a clear recommendation when it is acceptable to not use encryption. Further, I'm also wondering why this is not just incorporated in rfc3315bis?
Thanks for producing this document, when the DISCUSSes clear :-)