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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John Leslie wrote:

Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:
The IESG wrote:
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
  This appeared on the agenda for last week's telechat, and confused
me pretty well. Glad to see I'm not alone! ;^)
Ok, I feel better now as well :-).

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.
Well, I don't think doing some RFC Editor notes to update references is particularly hard.
IMHO, the implementation report is the hard bit.

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?
  That's an honest issue. We certainly can't make those changes without
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.

  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.
This sounds good to me.

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]