--On Tuesday, October 15, 2019 14:19 -0400 Barry Leiba
<barryle...@computer.org> wrote:

>> If we do not have agreement on what the meaning is for the
>> relevant terms, then either
>> 1) The document should not be an IETF consensus document
>> (which even Informational publication is)
> 
> Just a point on this: it's not true.
> 
> We have a "consensus" flag in the datatracker, which triggers a
> boilerplate change.  It's always set to "yes" for Standards
> Track or BCP, but for Informational and Experimental it can be
> set either way. If it's set to "no", the boilerplate says that
> the document does not have IETF consensus.  It's possible that
> when we're done with this document it could settle into that.
> 
> It's also possible that we might convince the regext working
> group to stop processing this document and suggest to the
> authors to go to the ISE.  I don't think we're there yet, and
> at the moment the working group has consensus to publish it as
> a working group product

Barry,

I have to agree with Joel about this and one of his comments in
particular.  Every discussion we've had over the years about
identifying documents differently depending on whether there is
IETF consensus that they are sound technically and every
discussion we've had about better differentiation of IETF Stream
documents from others (including RFC++ nearly a year and a half
ago), has stressed that changes in the wording of boilerplate is
not enough.  It is, IIR, one of the reasons the RFC headers were
changed to reflect the Stream.  

In rare cases, I think it might make sense to publish a document
as "Informational, No IETF consensus" when a WG produced a spec
for which there was general consensus that the spec was sound
technically but the IETF was unsure that it was appropriate for
standards track or saw better options.  But here we have a
document that several people have suggested is not, in its
present form, sound technically.   In that situation, it seems
to me that the document should be sent back to the WG with
instructions to fix the problems and/or decide what else to do
and it should stay there until either the substantive technical
problems are resolved or the WG decides to dispose of the
document in some other way.

best,
   john



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to