Re: [Rswg] Making progress on RFC 7991-bis

[John C Klensin <[e-mail]>]

Chairs,

--On Tuesday, August 2, 2022 10:07 -0700 Eric Rescorla
<[e-mail]> wrote:

> Hi folks, Chairs here.
> 
> We've been watching the discussion about RFC 7991-bis and
> wanted to see if we could help guide the discussion towards
> consensus.

> PROCESS
> Under Section 3 of RFC 9280 the evolution of RFC format is the
> responsibility of this WG as:
> 
>    Policies under the purview of the RSWG and RSAB might
> include, but    are not limited to, document formats,
> processes for publication and    dissemination of RFCs, and
> overall management of the RFC Series.
> 
> With the publication of RCC 9280, the IAB no longer has a
> direct role in setting the policies for the RFC series, as
> stated in Section 3.1.1.4:
>...
> Any such document needs to come out of this WG.

While I accept (and, fwiw, mostly agree with) the conclusion, an
assertion that only this WG can publish a summary of current
status is problematic.  I hope no one feels a need to go in
either of these directions, but, much of this discussion is
about boundaries and authority...  Suppose John's description of
current status were modified to be very clear that it is
descriptive rather than not normative, that it represents his
(or a future editor's) opinion about the current status, and
that it does not define a path forward.   Because we have been
very careful since the stream model was proposed to be sure that
no stream can tell any other one what it cannot publish, either
the IAB or the ISE could, with such additional disclaimers as
they might choose to add, go ahead and publish. Under existing
procedures, they should obviously ask others for advice (and the
ISE is obligated to ask the IESG) and we assume they would give
that advice careful consideration.  But, ARIAK, nothing
discussed so far would allow the RSWG or whatever editorial
stream processes are developed to make a binding decision to
prohibit the IAB or ISE (or, I suppose in principle, the IRTF or
IESG) from publishing anything they feel that is in line with
their mission and internal procedures and that they believe is
appropriate.

Again, I hope no one thinks seriously about going there but
because decisions made now may set precedents, let's recognize
the inter-stream boundaries.  Or, if we believe the traditional
boundaries are inappropriate and, e.g., the editorial stream
should be able to control what others can publish, let's create
an issue around that and see if it gets consensus.

> RFC 9280 does not specify a precise line between policy and
> implementation detail, but ultimately it is up to this WG to
> devise a process for evolving the format, subject to approval
> by RSAB; this might include delegating some detailed decisions
> to the RPC.

Thanks for stating this clearly.  I hope no one considers it
controversial at this stage.


> SUBSTANTIVE
>...
> This work will of course take some time, but we have already
> published RFCs in the format defined in draft-irse- and nobody
> has seriously suggested that we cease publishing RFCs until a
> community consensus format is published. This makes it
> necessary to document that format. We do not see the WG as
> currently having consensus on the precise manner in which we
> do so. In particular, the chairs would ask people to focus on
> two questions.
> 
> 1. Do we need to publish the current de facto format as an
>    RFC or should it be in some other form such as an I-D
>    or a Web page?

I would stop short of "need to", but, since we have documents
published in the de factor format and we are claiming the XML
forms of those documents are stable and archival, I think an
equally archival and stable description of the vocabulary and
conventions used in those documents would be a really good idea.
If the vocabulary and format (schema) that has been used (and
will presumably continue to be used until this WG starts making
changes or authorizes a process for doing that) is not
documented in a way that is as stable as the RFCs that use it,
that becomes another argument that the decision to treat the XML
as canonical and archival was unrealistic.
 
> 2. Should we just publish the de facto format as-is
>    or should we make limited changes prior to the completion of
>    a more complete format document? If the latter, what process
>    should we use to vet those changes?

I think whatever description or disclaimers are necessary to
make clear what the document actually is and how it applies
(including an approximation to your "entirely accurate"
footnote) are limited, and non-substantive changes that should
be made before before publication. By contrast, discussions
about substantive changes, even very limited ones, could take a
fairly long time to converge (traffic on the list since the
meeting would seem to reinforce that view) and should be
avoided.  Getting a description of what we are actually doing
posted, and soon, seems important.  My sense is that there is
agreement on that point, plus or minus the opinions of anyone
who appears to believe that a continually evolving spec and
dynamic description that tracks changes is more important than a
stable description of where we stand (I am not sure there are
such people). 

However, there is another issue that I don't believe either of
your notes have addressed and that could, I believe, change your
analysis and the answers to these questions.   That is whether
it is clear that no further vocabulary changes should be made
until this WG decides how that should be done and gets that
decision through the approval process.  If there is general
agreement on that subject, any issues could probably be
addressed most efficiently by getting a clear statement from the
relevant groups that they do not intend to make further such
changes as internal decisions.    If there is not, I don't think
we are even ready to discuss a "current status" because
"current" could change immediately after publication or sooner.

best,
   john