Hi Samu, nobody seems to care about SPKI, then. Could you please go ahead revise the draft removing it?
Thanks, Gonzalo On 12/10/2015 10: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, [email protected] 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/hipsec >>> > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
