[Top] [All Lists]

Re: Summary of LC comments (so far) on RFC1984 to BCP

2015-09-02 10:28:27

While I disagree with some of the details (and have written you
separately about a few of them that I think have been adequately
covered on-list), I think this is mostly a fair and balanced
summary.  I do question one pair of statements:

--On Wednesday, September 02, 2015 09:20 -0500 Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com> wrote:

It was suggested to explicitly note in the
status-change document that this is an exceptional action,
but that it falls within the processes laid out by RFC2026.

* Concerns were raised about whether moving an
Informational document to a BCP was supported by the
existing processes, or if this was a process end-run.
Discussion pointed out how this is not a violation
of process.

If the variance procedure is invoked, you can do almost
anything, but it has not been invoked.  Otherwise, an argument
that this change is justified by RFC 2026 processes would appear
to have to be justified either on the basis of our usual (but
much more recent than 2026) convention of referring to BCPs as
part of the standards track or by the invocation of Section 6.1
from Section 5.1 of 2026.  "Discussions pointed out..." is not
really a sufficient summary against that backdrop.  In

Given that 2026 separates "BCP" (in Section 5) from "Standards
Track" in Section 6 and elsewhere), making a "rules are the same
and this is allowed" conclusion is a stretch.  Inferring that
the reference in the second paragraph of Section 5 to Section
6.1.1 or the one in the third paragraph to Section 6.1 allows
the IESG to do anything to create a BCP that is allowed for
putting something on the standards track or advancing it seems
even more so.  I also note that 2026 has something very specific
to say about the relationship between Informational RFCs and
BCPs, namely:

        "Specifically, BCPs should not be viewed simply as
        stronger Informational RFCs, but rather should be viewed
        as documents suitable for a content different from
        Informational RFCs."

Getting from that to an assertion that it is ok under 2026 to
take an Informational document with content suitable for that
purpose and make it into a BCP by a status change with no change
in content seems very much inconsistent with the clearly-stated
intent of the above paragraph.


If the IESG concludes that there is community consensus for
doing this, either 

        (i) Explicitly invoke the variance procedure of RFC 2026
        Section 9, explicitly noting that the first part of
        Section 9 allows its applicability to any situation in
        which "...the procedures leads to a deadlock about a
        specific specification, or there may be situations where
        the procedures provide no guidance" even though Section
        9.1 discusses only standards track document.   Or
        (ii) Make sure the way in which you believe this is
        allowed by ("within the processes laid out by") RFC 2026
        is very carefully spelled out in the tracker statement,
        not just stated as an assertion like those quoted above.

Because the issue has been raised, approving this status change
without at least some approximation to the above would make the
decision appeal-bait.  Should some sorehead initiate such an
appeal, it would be entirely appropriate for an appellant to
request that the entire IAB be blocked from considering such an
appeal (because, as your summary indicates, they have already
expressed support for this move as a status change) and that
every IESG member who has taken a position on the
appropriateness of the change, including by not objecting to the
issuance of a Last Call that assumes the action is permitted, be
excluded as well.  Most of IESG might be able to avoid that
claim on the basis that opinions might have been changed by the
discussion but that would, itself, be a decision subject to
appeal; the IAB cannot.    Such a request in an appeal would,
IMO, bring us close to a constitutional crisis.  It would
probably not be desirable to get ourselves into that state,
especially over a document with the type of content and audience
represented by RFC 1984.

YMMD and probably does, but I thought it was important to get
the above point of view stated clearly at the point.