Re: [Hipsec] WGLC: draft-ietf-hip-rfc5203-bis

Julien Laganier <> Thu, 11 June 2015 00:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3ED0F1B2CEE for <>; Wed, 10 Jun 2015 17:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id riGrfIvhcCnZ for <>; Wed, 10 Jun 2015 17:32:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B11B1B2D5C for <>; Wed, 10 Jun 2015 17:31:27 -0700 (PDT)
Received: by ykaz81 with SMTP id z81so3479273yka.3 for <>; Wed, 10 Jun 2015 17:31:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/n2YEY5c6OISkOnI6KJF82ZFWfAd00ty7VRbes+6tq8=; b=HgQBSAqsOo/dwm9d45/CeWxMT2zyFbeBECYzvLKQFuI1MOO/zt+NYlx/MRKyVyIMGM xWBobg7zsqxcXtdLAZyXdAPFTDn0wizrV2ure3bkhJRvyYBbN1P2MPK6QBEROsFO3QNh J9/t0gajlvRo1BS1BzV0GbtFhG7t8ZLMmruWWIXprShP6mQndpNfLB3AZ8kZKJGa5VvQ 1iUzc3BPAPb/HWSTLfZJx6LbGayvl9HyBaDtZJ2waQT9uLfW2fzTaSB95J6YCQDEdsYd mRKLv3P1dhbrB4X9ilt2nNGvFeFqPKAmxOu5BSJf8N9+Ty7PxgRCdSIOy5EN42YQ1eFz ydaA==
MIME-Version: 1.0
X-Received: by with SMTP id c126mr7829800ywb.162.1433982686613; Wed, 10 Jun 2015 17:31:26 -0700 (PDT)
Received: by with HTTP; Wed, 10 Jun 2015 17:31:26 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 10 Jun 2015 17:31:26 -0700
Message-ID: <>
From: Julien Laganier <>
To: Tom Henderson <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: HIP <>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5203-bis
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jun 2015 00:32:38 -0000

Hi Tom,

Thank you for the WGLC review. Please see inline the proposed
resolution of your WGLC comments.


On Tue, Jun 2, 2015 at 12:45 PM, Tom Henderson <> wrote:
> I discovered recently that my email this year to the HIPSEC list has not been making it to the list, and I haven't been able to resolve the issue, so I will start to send from a different address.
> Below, please find some comments on the RFC5203-bis draft that I sent on May 11.
> - Tom
> On 04/24/2015 03:09 AM, Gonzalo Camarillo wrote:
>> Hi,
>> I would like to start a WGLC on the following draft. This WGLC will end
>> on May 11th:
>> Please, send your comments to this list.
> Gonzalo and Julien, I had a fresh read of this document and it looks
> ready, aside from the following small comments.
> - Tom
> p.3  s/registration type implicated/registration type requested/


> p.4  "A host that is capable and willing to act as a registrar SHOULD
>    include a REG_INFO parameter in the R1 packets it sends during all
>    base exchanges."  Shouldn't this be constrained to include REG_INFO
> only to those hosts to which it wants to offer services (i.e. it may not
> offer such services to all peers that it talks to)?

Makes sense. I have adjusted the text to read:

        A host that is capable and willing to act as a registrar
vis-a-vis a specific
        requester SHOULD include a REG_INFO parameter in the R1 packets it
        sends during all base exchanges with that requester.

> p.4  s/unfeasible/infeasible


> p.9  what is the purpose of including minimum and maximum lifetime in
> the REG_INFO, when it can be seemingly disregarded by the registrar?
>    The requester MUST be prepared to receive any registration lifetime,
>    including ones beyond the minimum and maximum lifetime indicated in
>    the REG_INFO parameter.  It MUST NOT expect that the returned
>    lifetime will be the requested one, even when the requested lifetime
>    falls within the announced minimum and maximum.
> wouldn't it be easier to just have the requester just submit its
> request, and accept whatever the registrar gives it (which it has to do
> anyway)?  Else, please clarify what a requester should do with the
> min/max provided by the REG_INFO.

The min/max lifetime in the the REG_INFO are offered by the registrar
to the requester as guidance w.r.t. to the interval of lifetimes that
are currently acceptable to the registrar.

The provision that the requester be prepared to deal with a
registration lifetime that is not within the previously advertized
interval makes the protocol robust against a change of the acceptable
interval between its advertisement in REG_INFO and the registration
being requested and granted in REG_REQ/RESP exchange.

I've added to the REG_INFO parameter description the following
paragraph to clarify what the requester should do with these values.

     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.

> p.11 In the IANA section, I think that you want to instead request that
> IANA replace references to RFC 5203 to with references to this document,
> and to allocate two new Registration Failure Type codes for these new ones:
>    [TBD-IANA]      Insufficient resources
>    [TBD-IANA]      Invalid certificate


  This document updates the IANA Registry for HIP Parameters Types by
   replacing references to [RFC5203] by references to this document.

   This document also updates the registry for registration failure
   types by making the following failure type definitions and

   Failure Type    Reason
   ------------    --------------------------------------------
   [TBD-IANA]      Insufficient resources
   [TBD-IANA]      Invalid certificate