[dhcwg] Mirja Kühlewind's No Objection on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Tue, 11 April 2017 12:40 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149191445619.15674.3447547103500441176.idtracker@ietfa.amsl.com>
Date: Tue, 11 Apr 2017 05:40:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/pWm48oHgyPpi4aZZd4-KZYsymII>
Subject: [dhcwg] Mirja Kühlewind's No Objection on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dhc-relay-server-security-04: 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-relay-server-security/



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

I strongly agre 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, somesome 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/RECOMMANDED instead of
MUST/REQUIRED) and give a clear recomendation when it is acceptable to
not use encryption.

Further, I'm also wondering why this is not just incorporated in
rfc3315bis?

[dhcwg] Mirja Kühlewind's No Objection on draft-i… Mirja Kühlewind