[Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Wed, 06 July 2016 21:08 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6112B04E; Wed, 6 Jul 2016 14:08:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160706210829.26812.48474.idtracker@ietfa.amsl.com>
Date: Wed, 06 Jul 2016 14:08:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/4T42beQSvqy-CxRPawHxosHujCI>
Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org
Subject: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 21:08:29 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-hip-rfc5203-bis-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:


This bis draft was an improvement. I did have one question.

I'm trying to visualize why 

   The registrar indicates the minimum and maximum registration lifetime
   that it is willing to offer to a requester.  A requester SHOULD NOT
   request registration with lifetime greater than the maximum
   registration lifetime or smaller than the minimum registration
is a SHOULD NOT - why would a requester choose to disregard the SHOULD
and send a request registration with (for example) a lifetime greater
than the maximum registration lifetime?

Is the intention for the requester to allow this, and then (for example)
cap the lifetime at the maximum registration lifetime? Or is something
else supposed to happen?

Whatever the intention is, it might be helpful to provide an explanation
about that.