Subject: [dhcwg] Ben Campbell's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jan 2018 18:37:15 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-rfc3315bis-10: No Objection

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's comments regarding the Gen-ART review. I suspect the
resulting update will be substantial. I am a bit uncomfortable approving the
draft prior to having a chance to review the update. My discomfort does not
quite rise to the level of a DISCUSS, so I am balloting "No Objection".

-2: RFC 8174 has boilerplate that includes the ALL CAPs constraint; please
consider using that rather than rolling your own.

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 25 Jan 2018 04:29:26 +0100

> https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/
Ben,
Thank you for your review and for not unleashing your DISCUSS powers on us.

Bernie and I are maintaining a spreadsheet with all the comments we have
received and we intend to incorporate great majority of them. If you
want to track our progress with this, see here:
https://docs.google.com/spreadsheets/d/1Yu6-BSV6aWPnhPGxKMPkokSaevjpfzTXe5_98ceoUMU/edit#gid=0
Once we apply the changes, we will ask the commenters for confirmation
that the changes are ok.

In fact, the only comment we don't plan to incorporate is the one about
algorithm flexibility. We will send a detailed explanation, but the
short version is that the goal of the bis was to provide unified text
rather than add new features. Also, the clients would have to signal
somehow their capabilities. They currently do not do that. The server
would have to match that with its own algorithms. They currently do not
do that and simply assume the client is able to handle HMAC-MD5 if
reconfigure-accept option was sent. Sure, all of that can be done, but
it requires defining new options. And that's out of scope for bis type
of work.

> consider using that rather than rolling your own.
Yes, we will use that.

Tomek