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

Julien Laganier <julien.ietf@gmail.com> Fri, 05 August 2016 16:36 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F42712D6A1; Fri, 5 Aug 2016 09:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VSdI1QF0IP7; Fri, 5 Aug 2016 09:36:11 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03EA12D666; Fri, 5 Aug 2016 09:36:11 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id l203so36546483oib.1; Fri, 05 Aug 2016 09:36:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K0gQgoZFGKmRKpYm9EvmHAR+/NfS74VPnncPo/bnf0U=; b=LciTmpD8jCSaQWsuahE2ciIghW+BdMKzXqaYf62R5futBOYiuUrCMeRkhs9d2sVhBi TZT5bke1L3ewnOMkQWiQVkT9j9LfvpgAKmulwYCPa5zLiOlefeS3bBkvkq0dviak6ZsQ eeih3HtNaVZeuoZtffWclKYpnUL7ioKRsbXJog9JGMer+UVWzTdSqk71KKg4Nyk3BRDZ cTP8EeZ22OTW34jg2eIt8bwMn+5CWfaxSTS/ie/GYBH00Um3+Ke8g+pUdeteAQWlJTwE MpPSTV6ZO2QHosKGr5WyjQ2l4OsRmzI3KMLqe+NfCuR3QfR/Q01Hq2knE02kjJl5Blpp OV2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K0gQgoZFGKmRKpYm9EvmHAR+/NfS74VPnncPo/bnf0U=; b=nJdw5H38yeqWDikAOBZp2m5cjyAggL3PQiFx0iui9Pu1kehXR+JxAjZPlhF0p75bRG QOMkSnCXYkFzQlxnD151dLvBYrqTrluG39aSJvTZLlokX+zmNRura8nuhu82WjtPv7NR 6pWayTrqC5FfHfFCdJf0qWIDeBQ9IUyMXIEETqleGgl0tyBZI0g60j6ectZZCKMjmFEo 7SlBHl4q8u0bgvo4LLys4b7lNfE5vllQ85YrEzWcwLGl8AoxLNhI3yLFTIUWYXMUK7IT CUaiHEhj296Jx4TSOx5KYiKVrTt8sopaiq6uz316dAlQcOLZNborfxkjQmM5mF331u0P Kjsw==
X-Gm-Message-State: AEkooutA1HhE7e+nq1giFT6svJ5QdPJHY6kx+JOt89p1HF6aHLCpDwqpQnmi14QIkFowYlamVXw85eA+dKw5xA==
X-Received: by 10.202.241.66 with SMTP id p63mr49225860oih.166.1470414970943; Fri, 05 Aug 2016 09:36:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.63.52 with HTTP; Fri, 5 Aug 2016 09:36:10 -0700 (PDT)
In-Reply-To: <20160706210829.26812.48474.idtracker@ietfa.amsl.com>
References: <20160706210829.26812.48474.idtracker@ietfa.amsl.com>
From: Julien Laganier <julien.ietf@gmail.com>
Date: Fri, 5 Aug 2016 09:36:10 -0700
Message-ID: <CAE_dhjvBPf6GaqUbikkSehvCx7xqimtpyiG6=TKNX9iZiG782A@mail.gmail.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/zDY2bSIqGDXRxWJdU19AevS-DFM>
Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP <hipsec@ietf.org>, hip-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [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
Precedence: list
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: Fri, 05 Aug 2016 16:36:13 -0000

Hi Spencer,

I just realized looking at the IESG record for the draft that I didn't
answer your comment, sorry.

I don't remember how we ended up with writing this as a SHOULD NOT
(e.g., as opposed to a MUST NOT),  but at least the SHOULD NOT does
not negatively affect interoperability since, at the end of the day,
the registrar has the final word, whether it decides to grant a
lifetime that's in the advertised interval, or grant the out-of-bound
lifetime that was requested, and the granted lifetime value is
communicated over to the requester in the REG_RESPONSE.

--julien

On Wed, Jul 6, 2016 at 2:08 PM, Spencer Dawkins
<spencerdawkins.ietf@gmail.com>; wrote:
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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
>    lifetime.
>
> 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.
>
>