RE: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard

"Jim Schaad" <jimsch@nwlink.com> Thu, 06 May 2010 19:45 UTC

Return-Path: <jimsch@nwlink.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DAD28C122 for <ietf@core3.amsl.com>; Thu, 6 May 2010 12:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 Kpl5ntsYR+Ll for <ietf@core3.amsl.com>; Thu, 6 May 2010 12:45:19 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id EF74628C115 for <ietf@ietf.org>; Thu, 6 May 2010 12:45:18 -0700 (PDT)
Received: from TITUS (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTP id B0F716F0F4; Thu, 6 May 2010 12:45:05 -0700 (PDT)
From: Jim Schaad <jimsch@nwlink.com>
To: 'Suresh Krishnan' <suresh.krishnan@ericsson.com>
References: <000c01caecd1$7b932000$72b96000$@com> <4BE2FBB1.9090201@ericsson.com>
In-Reply-To: <4BE2FBB1.9090201@ericsson.com>
Subject: RE: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard
Date: Thu, 06 May 2010 12:44:52 -0700
Message-ID: <005301caed54$9940ff90$cbc2feb0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrtQVupzJfDVSraQBuvD8EeoXadowAEytlg
Content-Language: en-us
X-Mailman-Approved-At: Fri, 07 May 2010 08:00:52 -0700
Cc: 'IETF discussion list' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2010 19:45:20 -0000

I am sorry I got the wrong subject list for this.  IT was a different draft
I was trying to deal with.  I will look at this document soon.

Jim


> -----Original Message-----
> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]
> Sent: Thursday, May 06, 2010 10:26 AM
> To: Jim Schaad
> Cc: 'IETF discussion list'
> Subject: Re: Last Call: draft-ietf-csi-send-cert (Certificate profile
> and certificate management for SEND) to Proposed Standard
> 
> Hi Jim,
>    I think you are commenting on the wrong document. You probably meant
> to comment on draft-housley-cms-content-constraints-extn whose last
> call
> period ended on April 19th.
> 
> Thanks
> Suresh
> 
> On 10-05-06 12:06 AM, Jim Schaad wrote:
> > I have the following comments on this document
> >
> > 1.  I find the following statement ambiguous:
> >
> > 	CCC is not used to constrain MIME encapsulated data, i.e., MIME
> >    	wrapping layers are not processed with regard to CCC.
> >
> >    I do not know if this means that processing is to stop at a MIME
> > encapsulation layer, or if it means that the id-data content type
> cannot be
> > constrained.  (Or perhaps both meanings are correct.)  IF the first
> is meant
> > I would suggest "CCC processing stops when a MIME encapsulation layer
> is
> > encountered."  If the second is meant then it should say "CCC cannot
> be used
> > to constrain the creation of the id-data content type."
> >
> > 2.  It is my personal opinion that the algorithm as described is
> overly
> > confusing.  I was able to fully understand the procedure only by
> interacting
> > with the authors and not from the document.  While there have been
> some
> > changes to the text since that time, I do not believe that the basic
> > problems with making the algorithm clear have been addressed in the
> > document.  I did supply what I considered to be a much simpler
> version of
> > the algorithm to the authors, but they decided not to make the
> changes that
> > I outlined in my suggested text.
> >
> > Jim
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf