[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Wed, 16 December 2020 05:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEC63A0F3A; Tue, 15 Dec 2020 21:46:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-server-cookies@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160809759955.15760.16150359769007836773@ietfa.amsl.com>
Date: Tue, 15 Dec 2020 21:46:39 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QkfbM_pjQONNfY-s6yxTJTbtA1c>
Subject: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 05:46:40 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-server-cookies-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-dnsop-server-cookies/



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

Thanks for this; very useful.  I have two small points:

— Section 3 —

   It is reasonable to change the
   Client Cookie then only if it has been compromised or after a
   relatively long period of time such as no longer than a year.  Client
   Cookies are not expected to survive a program restart.

Itis anvery small thing, but “a relatively long period of time such as no
longer than a year” strikes me as an odd way to put it, and especially so
because of the sentence that follows it.  If you’re actually suggesting that a
year is a reasonable and likely choice, please say that more clearly. 
Otherwise, you might consider suggesting a shorter period as a (lower-case)
recommendation, with the year as a maximim... or, alternatively, leave it at
the vague “relatively long” with something like, “or after a relatively long
implementation-defined period of time.  The time period should be no longer
than a year, and in any case Client Cookies are not expected to survive a
program restart.”

— Section 4.2 —
Why is it a SHOULD, rather than a MUST, to zero the reserved field?  Why might
a server not zero it for good reason?  And wouldn’t it harm future
interoperability if implementations don’t, and an extension comes along that
uses bits in that field?