John Leslie wrote:
Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf