> 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 > IETF. 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 point: - 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. Barry