With respect to Standards Track - I actually agree this document is not to
be on Standards Track, as this can't be standard anyway. But I can't agree
the draft must be published as Informational, because in RFC 2026 meaning
Informational RFCs are to make a record of an 'outer-space' protocol to
I have no idea what the second sentence means.
But, yes, to clarify the point on the intended status: It's a procedural thing.
The working group had some uncertainty about whether the IESG would
accept an Informational document to do this registration. My sense is
that the WG would prefer Informational. But here's the procedural
- If we last-called this as Informational and the IESG were to decide
that it needs to be Standards Track, we'd require a new last call for
the status change.
- If we last-called this as Proposed Standard and the IESG were to
decide that it should be Informational, it could just be changed by
the IESG, without a second last call.
And, in fact, the PROTO writeup says this, in answer to the first
question on intended status:
"The requested RFC is Standards Track (Proposed Standard ).
There are some concerns whether we can register a URI in the Permanent
registry if the document status is Informational. If this is not a problem, this
document can be informational."
So from a procedural point of view, it was better to last-call it as
Proposed Standard and get the comments. And that was useful: we have
comments expressing a preference for NOT putting this on Standards
Track, and that's valuable input for the IESG.