Subject: Second Last Call: rfc3852 (Cryptographic Message Syntax (CMS)) to Draft Standard

From: The IESG <[email-masked]>
Date: Mon, 27 Apr 2009 06:58:42 -0700 (PDT)

The IESG has received a request from the smime WG (smime) to consider 
the following document:

- 'Cryptographic Message Syntax (CMS) '
  RFC 3852 as a Draft Standard

No technical issues were raised during the first Last Call.  However, the
Last Call failed to highlight two normative references to standards track
documents of lower maturity:  RFCs 3280 and 3281.

This abbreviated Last Call is focused solely on whether downrefs to these
Proposed Standards are appropriate in the context of RFC 3852.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-05-06.   Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/rfc/rfc3852.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/implementation.html

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=3852&rfc_flag=1

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Apr 2009 17:15:53 +0100

>documents of lower maturity:  RFCs 3280 and 3281.
Speaking as a member of the IETF community I find the question 
confusing, considering that both documents were obsoleted (or just about 
to be obsoleted in case of RFC 3281). Shouldn't this be RFC 5280 and 
draft-ietf-pkix-3281update-04.txt?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Apr 2009 09:47:12 -0700

At 5:15 PM +0100 4/27/09, Alexey Melnikov wrote:
>The IESG wrote:
>
>>The IESG has received a request from the smime WG (smime) to consider the following document:
>>
>Speaking as a member of the IETF community I find the question confusing, considering that both documents were obsoleted (or just about to be obsoleted in case of RFC 3281). Shouldn't this be RFC 5280 and draft-ietf-pkix-3281update-04.txt?

Both those documents are also not yet Draft Standards, so the question of down-reference is still the same.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Apr 2009 13:52:43 -0400

Alexey Melnikov <[email-masked]> wrote:
>> - 'Cryptographic Message Syntax (CMS)' RFC 3852 as a Draft Standard

   This appeared on the agenda for last week's telechat, and confused
me pretty well. Glad to see I'm not alone! ;^)

>> No technical issues were raised during the first Last Call.  However,
>> the Last Call failed to highlight two normative references to standards
>> track documents of lower maturity:  RFCs 3280 and 3281.

   As I understand it, the intent was to advance the status of RFC 3852
with no text changes whatsoever. I tend to support such actions, since
otherwise it seems "just too hard" to advance Proposed Standard documents
to Draft Standard.

> draft-ietf-pkix-3281update-04.txt?

   That's an honest issue. We certainly can't make those changes without
also changing the RFC number. But if we do make those changes, what else
"needs to change"? Can we avoid boilerplate change issues?

   And, provided RFC 3852 retains its original date (which I _think_ is
a given), I would opine that those references _should_not_ change.

>> This abbreviated Last Call is focused solely on whether downrefs to
>> these Proposed Standards are appropriate in the context of RFC 3852.

   So, I will comment on that: IMHO, any such downrefs are appropriate.
The issue in advancing to Draft Standard is multiple implementations.
We _have_ multiple implementations based on precisely those references.
I cannot imagine more appropriate references.

--
John Leslie <[email-masked]>

---

From: Tim Polk <[email-masked]>
Date: Mon, 27 Apr 2009 15:21:36 -0400

Alexey,

The goal of this particular exercise is to advance RFC 3852 *without*  
revision, so I called out the normative references as specified in the  
document: RFCs 3280 and 3281.  It is true that RFC 3280 has been  
obsoleted by RFC 5280, and that draft-ietf-pkix-3281update is intended  
to update 3281.  (Both documents cycled/are cycling at Proposed, so  
they would still be downrefs even if we submitted a 3852bis to address  
the references.)  And, yes this makes it more confusing to determine  
whether a downref is appropriate.

I would personally factor the clarifications in RFC 5280 in my  
evaluation of the downrefs, since I would use it as the basis for any  
new implementation of 3852, but would not consider 3281update since it  
is still a working document and subject to change.

To me, the question for the community is whether RFC 3852 achieves the  
expected characteristics of a Draft Standard (as described in 2026) in  
spite of these downrefs:
> A Draft Standard must be well-understood and known to be quite  
> stable, both in its semantics and as a basis for developing an  
> implementation.

I believe the implementation report adequately demonstrates RFC 3852  
*in its totality* is well-understood and provides a stable basis for  
developing interoperable implementations.  To my mind, this makes  
advancement appropriate in spite of the two downrefs.

Thanks,

Tim

On Apr 27, 2009, at 12:15 PM, Alexey Melnikov wrote:

> confusing, considering that both documents were obsoleted (or just  
> about to be obsoleted in case of RFC 3281). Shouldn't this be RFC  
> 5280 and draft-ietf-pkix-3281update-04.txt?
>
>> these
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Apr 2009 21:48:20 +0100

>me pretty well. Glad to see I'm not alone! ;^)
Ok, I feel better now as well :-).

>otherwise it seems "just too hard" to advance Proposed Standard documents
Well, I don't think doing some RFC Editor notes to update references is 
particularly hard.
IMHO, the implementation report is the hard bit.

>also changing the RFC number.
>
Right.
I don't think keeping the RFC number should be a goal in itself.

>But if we do make those changes, what else
>"needs to change"?
>
I would be happy to discuss this question separately and I think having 
an agreement on scope of changes would be a good thing.
I can see people's reluctance not to reopen the document though.

However, I question value of moving a document to a higher level, if it 
doesn't actually represent the up-to-date snapshot of protocols used.
Are we expecting that people would read RFC 3852, find all updates to 
normative references and make sure that they implement them, instead of 
RFCs specified in RFC 3852?

>Can we avoid boilerplate change issues?
>  
>
Updating boilerplate is a single world change in xml2rfc source.
Cutting and pasting new boilerplate is not hard either.

>I cannot imagine more appropriate references.
This sounds good to me.