Security of Messages Exchanged between Servers and Relay Agents
RFC 8213

Note: This ballot was opened for revision 04 and is now closed.

(Ben Campbell) Yes

Comment (2017-04-12 for -04)
No email
send info
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.

Suresh Krishnan Yes

Alexey Melnikov Yes

Comment (2017-04-12 for -04)
No email
send info
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.

(Kathleen Moriarty) Yes

Comment (2017-04-11 for -04)
No email
send info
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?

(Alia Atlas) No Objection

Comment (2017-04-12 for -04)
No email
send info
I agree with both Warren's discuss and Benoit's comments about balloting being
easier when others have already done so :-)

Deborah Brungard No Objection

Comment (2017-04-12 for -04)
No email
send info
Agree with other ADs' comments.

(Benoît Claise) No Objection

Comment (2017-04-12 for -04)
No email
send info
The advantage of a late review is that everything has been said already by other ADs :-)

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2017-04-09 for -04)
No email
send info
Thanks for producing this document, when the DISCUSSes clear :-)

Warren Kumari (was Discuss) No Objection

Comment (2017-04-20)
No email
send info
"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.

Mirja Kühlewind No Objection

Comment (2017-04-11 for -04)
No email
send info
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?

(Eric Rescorla) (was Discuss) No Objection

Comment (2017-04-24)
No email
send info
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.

Alvaro Retana No Objection

Comment (2017-04-10 for -04)
No email
send info
I agree with Warren's confusion about the relationship between this document, RFC3315 and draft-ietf-dhc-rfc3315bis.