Probably best if I lay out the plan that’s in my mind for progressing RFCs 3948, 4301, 4303, and 5996 from PS (Proposed Standard) to IS (Internet Standard). Steps:
1) A request gets sent to IESG to progress RFC(s) from PS to IS. I think this
ought to come from the authors to the WG and then from the WG to the IESG.
But, if the WG thinks it’s a no-brainer then I’m happy to take it directly from
the authors.
2) For #1 to not fall on its face, the four questions in RFC 6410 (copied
below) need to be answered:
(1) There are at least two independent interoperating implementations
with widespread deployment and successful operational experience.
To answer this question, somebody (maybe me) needs to create an
interoperability report. The breadth and depth of the report is up to us, as
documented in RFC 5657 (please ignore that the title of that RFC includes
progression to DS (draft standard)). The interoperability report is either the
output of a bake-off or the distillation of a questionnaire sent to
implementers. I figured sending out a questionnaire was easier than organizing
a bake-off and getting the WG to review the questions I also thought was
important. The responses to the questionnaire are turned in to the
interoperability report and that interoperability report is cited in the WG and
IETF LCs and it’s posted to:
http://www.ietf.org/iesg/implementation-report.html
Responses to the questionnaire can be sent to the list or to the person sending
out the questionnaire. Regardless the responses are going to end up being
documented in the interoperability report. I don’t think it makes sense to
anonymize the responses included in the interoperability report. I also don’t
think this interoperability report needs to be exhaustive before we move on.
We’re looking 2-3 implementations that can claim they interoperate and do some
on a wide scale.
(2) There are no errata against the specification that would cause a
new implementation to fail to interoperate with deployed ones.
For this one we’re generating new drafts that incorporate errata. Not all
errata has been included and that’s why the drafts list what was included and
they will be last called to make sure that what got included is agreed. But,
for the RFCs that have errata we’re explicitly asking this question in the
questionnaire.
(3) There are no unused features in the specification that greatly
increase implementation complexity.
Again, there’s a specific question in the questionnaire to get an answer.
(4) If the technology required to implement the specification
requires patented or otherwise controlled technology, then the
set of implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.
There are IPR filings against RFC 3948 and 5996 so there needs to be questions
added to their questionnaires about this topic. How about:
Have the IPR file against RFC XXXX hindered development or deployment?
3) If it’s going through the WG, the WG LC should include the four questions
making sure the interop report is referenced and calling out any downrefs.
This report can be documented as an internet draft for this purpose, but
there’s no need to progress it to RFC because it’s just published on the
interoperability report page.
4) After the AD gets it, the AD will IETF LC the same questions making sure to
also refer to the interop report and include the downrefs.
5) The IESG will review it and we see what happens….
Make sense?
spt
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
