Re: [sidr] WG LC for draft-ietf-sidr-signed-object-01

Andrew Chi <achi@bbn.com> Mon, 08 November 2010 15:04 UTC

Return-Path: <achi@bbn.com>
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD4C3A68C1 for <sidr@core3.amsl.com>; Mon, 8 Nov 2010 07:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F3blrYwoog5 for <sidr@core3.amsl.com>; Mon, 8 Nov 2010 07:04:53 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0AF0D3A67D0 for <sidr@ietf.org>; Mon, 8 Nov 2010 07:04:53 -0800 (PST)
Received: from dhcp89-089-231.bbn.com ([128.89.89.231]:56380 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1PFTHV-000INy-8r; Mon, 08 Nov 2010 10:05:13 -0500
Message-ID: <4CD811A5.6050103@bbn.com>
Date: Mon, 08 Nov 2010 10:05:09 -0500
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Geoff Huston <gih902@gmail.com>
References: <alpine.LFD.2.00.1011051610210.3259@localhost6.localdomain6> <6C1BE3E0-6B7F-483C-B906-27F5D904FA18@apnic.net>
In-Reply-To: <6C1BE3E0-6B7F-483C-B906-27F5D904FA18@apnic.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "sidr@ietf.org wg" <sidr@ietf.org>
Subject: Re: [sidr] WG LC for draft-ietf-sidr-signed-object-01
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 15:04:54 -0000

On 11/8/2010 7:10 AM, Geoff Huston wrote:
>
> On 06/11/2010, at 7:11 AM, Sandra Murphy wrote:
>
>> The authors of draft-ietf-sidr-signed-object-01 (http://tools.ietf.org/html/draft-ietf-sidr-signed-object-01) have requested a working group last call.
>>
>> The chairs ask the working group to consider this draft and decide if it is worthy of publication.
>>
>> This draft has not been through a last call before and next week is the IETF week, so the last call will end on 26 November.
>>
>
> I had a question about this draft that I posted to the SIDR WG mailing list on the 8th October.
>
> ----------------
> I am a little confused in reading section 4 of this draft.
>
> The intro to this section states that:
>
>   "Each RPKI signed object MUST be defined in an Internet standards
>    track document based on this profile, by specifying the following
>    data elements and validation procedure:"
>
> My question is: Why is the Content-Type Attribute listed as a distinct
> data element that requires specification?
>
> The relevant text (item 3) states that:
>
>   "Content-Type Attribute:  The mandatory Content-Type Attribute
>    MUST have its attrValues field set to the same OID as
>    eContentType in item 1."
>
> So I understand that in writing a document that uses a RPKI signed object I
> have to define the eContentType, but I DO NOT need to also define the
> Content-Type Attribute. If this is the case then why is this data element
> listed in Section 4 of the draft as being a data element that MUST
> be separately specified in the specific object specification?
>
> regards,
>
>   Geoff
> -------------------
>
> I have not seen a response posted to the SIDR WG that responds to this question. Accordingly, as it stands I do not support this draft going forward until this question is resolved, as the draft as it stands is not internally consistent, imho.
>

Thanks for catching this, Geoff.  You are correct that since the 
eContentType OID MUST equal the Content-Type Attribute, a specific 
object specification only needs to specify one, not both.  That item 
will be removed.

-Andrew