Re: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-03.txt

Julien Laganier <julien.ietf@gmail.com> Fri, 21 February 2014 05:04 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B241A0405 for <hipsec@ietfa.amsl.com>; Thu, 20 Feb 2014 21:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.533
X-Spam-Level: *
X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_ASCII_ART_SPACINGc=0.833, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 iIlnXRnn7PF6 for <hipsec@ietfa.amsl.com>; Thu, 20 Feb 2014 21:04:11 -0800 (PST)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68B1A03F8 for <hipsec@ietf.org>; Thu, 20 Feb 2014 21:04:11 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id if11so2758727vcb.8 for <hipsec@ietf.org>; Thu, 20 Feb 2014 21:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wdX1sgrXjEwhDUQd5nG1w7pEC9vOND/1oPAJ/MjWgj0=; b=fzj69KNCPqH7CiLouvpxnFfrHPGsm4luMHYJVZJNFpknWvCqJGnarZlDTwJbgPIsTI hNEZfim7UOJcWgQ+eVJwv7etoz3kUi3VolliL9fTSUUoPjRd77d64MEGHB8/3NqL55Hc 3cGWD0xqF8bhAGwSiFR9QF86cFJAvwZCFrPaj9eiywm/mTRBOIx+UTlXWAGgtnvSGA60 OTL8NKs1C8qqvT3zjgESOOzFvg+Mqgu4gQOtL4aWiqSi8s0SHciwyaxDpgOmBb0XOcZ0 y5nGgwmW7vR1ffAiMdQkH4hRi/EX53KbU/gEnb4ZGExQqbEauFU6YfL9dddgJdC5+EQp BvXA==
MIME-Version: 1.0
X-Received: by 10.52.68.106 with SMTP id v10mr2875818vdt.59.1392959047283; Thu, 20 Feb 2014 21:04:07 -0800 (PST)
Received: by 10.52.87.242 with HTTP; Thu, 20 Feb 2014 21:04:07 -0800 (PST)
In-Reply-To: <52D94171.3010601@nomadiclab.com>
References: <20131211030009.544.78789.idtracker@ietfa.amsl.com> <52B44714.2010903@nomadiclab.com> <CAE_dhjsHQ9qJHvTr6rN3KBwd7G-Vu9xutT7G6-fuPjmP3gtB1A@mail.gmail.com> <52D806C5.1050606@nomadiclab.com> <CAE_dhjtyKAWKCXxpiYmk=AnrECV=bJrexH3M-McktLeT6i3wkw@mail.gmail.com> <52D94171.3010601@nomadiclab.com>
Date: Thu, 20 Feb 2014 21:04:07 -0800
Message-ID: <CAE_dhjsp0svo53TG8fQeF40sQRhykrzh21ikc6wSDBqfE7ihcQ@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Ari Keranen <ari.keranen@nomadiclab.com>
Content-Type: multipart/mixed; boundary="001a1136ad2e3376c104f2e38d1e"
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/SDs2sp8LhC3uefi_DIF55CFFHpQ
Cc: "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-03.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 21 Feb 2014 05:04:15 -0000

Hi Ari,

Thanks for reviewing the draft and suggesting improvements. I have
incorporated them all in the version-to-be -05, unfortunately the
deadline has passed so I am attaching it below for your (and the rest
of the WG) review in case you spot some errors before submission
reopens.

Cheers,

--julien



On Fri, Jan 17, 2014 at 6:42 AM, Ari Keranen <ari.keranen@nomadiclab.com> wrote:
> Hi Julien,
>
>
> On 1/17/14 5:50 AM, Julien Laganier wrote:
>>
>> Hi Ari,
>>
>> On Thu, Jan 16, 2014 at 8:20 AM, Ari Keranen <ari.keranen@nomadiclab.com>
>> wrote:
>>>
>>> Hi Julien,
>>>
>>> Thanks, that looks good to me. Although reading the draft again, I was
>>> wondering is it missing some text regarding the "Insufficient resources"
>>> error?
>>
>>
>> Hmm... a registration failing because of "insufficient resources" is
>> quite explicit; it conveys enough information for a  requester to know
>> that there are no resources to create a registration at a given
>> registrar. Presumably a requester would try to register at a different
>> registrar if it knows one...
>>
>> What else would the requester need to know?
>
>
> I mean that it looks a bit strange that there's only an error code defined
> but no text at all when to use it (even if the name of the code kinda gives
> it away). I would recommend to add a sentence or two about when/how to use
> it.
>
> I spotted one (copy-paste) error in the draft, section 3.3:
>
>    If the registrar knows the Host Identities (HIs) of all the hosts
>    that are allowed to use the relaying service, it SHOULD reject
>    registrations from unknown hosts.  However, since it may be
>    unfeasible to pre-configure the relay with all the HIs, the relay
>    SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to
>    allow for certificate based authentication.
>
> This should no longer be "relaying service" and "relay" (2 instances here)
> but in general the service for which one is registering for.
>
> In the figures, at the end of the section, I was wondering why S3 is not
> announced by the registrar? Also the text is a bit unclear; almost as if RQ
> would try to register for S1 and S2 even if the figure shows only S1.
>
> In section "4.5. REG_FAILED", it says "Failure types other than zero (0) and
> one (1) have not been defined." This is obviously not true anymore. Perhaps
> here would be a good place for some text on the insufficient resources error
> code.
>
> And by the way, I guess you can have more than one REG_FAILEDs if there was
> more than one failure type? The text seems to now imply only single
> REG_FAILED.
>
> Section 6 says:
>
>    Registrars act on a voluntary basis and are willing to accept being a
>    responder and then to create HIP associations with a number of
>    previously unknown hosts.
>
> Now with the HI/cert authentication this has actually improved (you only
> potentially do things with previously unknown hosts).
>
> Otherwise I think the draft is in good shape and could move forward.
>
>
> Cheers,
> Ari
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec