Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 12 October 2015 09:52 UTC

Return-Path: <gonzalo.camarillo@ericsson.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 834A21AC3E7 for <hipsec@ietfa.amsl.com>; Mon, 12 Oct 2015 02:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level:
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 il5H1T2NvUxo for <hipsec@ietfa.amsl.com>; Mon, 12 Oct 2015 02:52:00 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAC51AC3E6 for <hipsec@ietf.org>; Mon, 12 Oct 2015 02:51:59 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-e7-561b82bda6fb
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C3.98.29154.DB28B165; Mon, 12 Oct 2015 11:51:57 +0200 (CEST)
Received: from [131.160.36.125] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Mon, 12 Oct 2015 11:51:56 +0200
To: Miika Komu <mkomu@cs.hut.fi>, <hipsec@ietf.org>
References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> <561B806B.1080109@cs.hut.fi>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <561B82BD.7020506@ericsson.com>
Date: Mon, 12 Oct 2015 12:51:57 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <561B806B.1080109@cs.hut.fi>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje7eJukwg1WXbCymLprMbNG87Tmb A5PHq/61zB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY+iml4IJZRduCDewNjDO1uxg5OSQETCRO 7j7EAmGLSVy4t56ti5GLQ0jgKKPEsflbGSGcNYwSi7+/ZwWpEhZwllj56DEbiC0iYCxx8O8W qKK5jBJPH55kB0mwCVhIbLl1H2gsBwevgLbEg1YnkDCLgKrE5n+LwXpFBWIken5tALN5BQQl Ts58AlbOKaAp0XAzCiTMLGAgcWTRHFYIW15i+9s5zCC2ENDE5c9aWCYwCsxC0j0LScssJC0L GJlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgQG5cEtv612MB587niIUYCDUYmH98FtqTAh 1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA6s89u67iVxcz/ 2Jgn5Kmje+sT117jOzJyB+48bRN8xrr56EbOTcI+LcaZsQybu3/ozGguerbffPfcea9NW/Yq rbzWzGQ0d9XymslrOH895UrePHnrildBn+vUbxU8a9I6Od3xwMS6zG1Ci+/bLU6sUtuX7slf VMfKtPX7xl+NUjdzAq8cDmNSYinOSDTUYi4qTgQAILqEaCsCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/CEEhjFGhzKx4yzK_JAYVx657S_A>
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.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: <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: Mon, 12 Oct 2015 09:52:02 -0000

Hi Miika,

right, that is exactly the discussion we need to have. In general,
standards track documents should not reference Experimental specs. We
can remove the reference, as suggested by Samu below, find an
alternative reference, or figure out whether in this case it could be
acceptable to keep the reference... but if nobody intends to implement
or deploy SPKI, then removing the reference would be the obviously right
thing to do.

Any other opinions?

Cheers,

Gonzalo

On 12/10/2015 12:42 PM, Miika Komu wrote:
> Hi,
> 
> I don't have a strong opinion, but I guess SPKI should be dropped since
> the HIP CERT work is going proceed to the standards track.
> 
> On 10/12/2015 11:59 AM, Samu Varjonen wrote:
>> Hi Gonzalo & all,
>>
>> all but one of the nits are easily fixed. The one downref to RFC2693 is
>> the only harder one as I do not think it will ever proceed to anything
>> more than experimental. The work on RFC 2693 stopped in 1999. Over 114
>> papers have been written about it since. Even few this year but all
>> point to that experimental RFC. Moreover, it seems (in my opinion) that
>> currently there is little or no interest in continuing SPKI work nor
>> there is any interest in the industry to implement SPKI as it basically
>> provides the functionality of X509v3 with different syntax. One option
>> would be to remove the examples and mentions about SPKI in the
>> RFC6253bis. What do you guys think?
>>
>> BR,
>> Samu Varjonen
>>
>> On 02/10/15 13:15, Gonzalo Camarillo wrote:
>>> Hi Samu,
>>>
>>> thanks for revising the draft. There are still a few things that need to
>>> be fixed before I can request its publication. From the output of the
>>> nits tool:
>>>
>>> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt
>>>
>>>
>>>
>>>>    -- The abstract seems to indicate that this document obsoletes
>>>> RFC6253, but
>>>>       the header doesn't have an 'Obsoletes:' line to match this.
>>> You need to add an Obsoletes: header to the header part at the beginning
>>> of the draft. Additionally, you also need to add an Updates header as
>>> follows:
>>>
>>>    Obsoletes: 6253
>>>    Updates: 7401
>>>
>>> Note that the original RFC updated RFC 5201 and, thus, had an Updates
>>> header:
>>>
>>> https://tools.ietf.org/html/rfc6253
>>>
>>>>    == The document seems to contain a disclaimer for pre-RFC5378
>>>> work, but was
>>>>       first submitted on or after 10 November 2008.  The disclaimer
>>>> is usually
>>>>       necessary only for documents that revise or obsolete older
>>>> RFCs, and that
>>>>       take significant amounts of text from those RFCs.  If you can
>>>> contact all
>>>>       authors of the source material and they are willing to grant
>>>> the BCP78
>>>>       rights to the IETF Trust, you can and should remove the
>>>> disclaimer.
>>>>       Otherwise, the disclaimer is needed and you can ignore this
>>>> comment.
>>>>       (See the Legal Provisions document at
>>>>       http://trustee.ietf.org/license-info for more information.)
>>> You are the same authors as in the original RFC. Do you both agree to
>>> remove the disclaimer?
>>>
>>>>   == Unused Reference: 'RFC4843' is defined on line 349, but no
>>>> explicit
>>>>       reference was found in the text
>>> Does this reference need to be removed or used somewhere in the text?
>>>
>>>>    ** Downref: Normative reference to an Experimental RFC: RFC 2693
>>> RFC 6232bis is intended to be a Proposed Standard. Can we reference a
>>> Standards Track RFC instead of this one? Otherwise, we will need to talk
>>> with our AD so make sure it is OK to normatively reference an
>>> Experimental RFC.
>>>
>>>>    ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343)
>>>>    ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296)
>>> Could you please update the two references above?
>>>
>>>>    ** Downref: Normative reference to an Experimental RFC: RFC 6253
>>> This downref is obviously OK... but what about making it an
>>> Informational reference instead?
>>>
>>> Could you please revise the draft addressing all the comments above?
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>>
>>> On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>   This draft is a work item of the Host Identity Protocol Working
>>>> Group of the IETF.
>>>>
>>>>          Title           : Host Identity Protocol Certificates
>>>>          Authors         : Tobias Heer
>>>>                            Samu Varjonen
>>>>     Filename        : draft-ietf-hip-rfc6253-bis-04.txt
>>>>     Pages           : 11
>>>>     Date            : 2015-09-22
>>>>
>>>> Abstract:
>>>>     The Certificate (CERT) parameter is a container for digital
>>>>     certificates.  It is used for carrying these certificates in Host
>>>>     Identity Protocol (HIP) control packets.  This document specifies
>>>> the
>>>>     certificate parameter and the error signaling in case of a failed
>>>>     verification.  Additionally, this document specifies the
>>>>     representations of Host Identity Tags in X.509 version 3 (v3) and
>>>>     Simple Public Key Infrastructure (SPKI) certificates.
>>>>
>>>>     The concrete use cases of certificates, including how certificates
>>>>     are obtained, requested, and which actions are taken upon
>>>> successful
>>>>     or failed verification, are specific to the scenario in which the
>>>>     certificates are used.  Hence, the definition of these scenario-
>>>>     specific aspects is left to the documents that use the CERT
>>>>     parameter.
>>>>
>>>>     This document extends RFC7401 and obsoletes RFC6253.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> Hipsec mailing list
>>>> Hipsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/hipsec
>>>>
>>
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec