RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric, Brian, and others...

Since this has turned into a general discussion about DISCUSS,
etc., a few comments.  With regard to the specific appeal,
everyone should remember that, under our procedures, the focus
of an appeal in the first instance is "please reconsider this
and decide whether you really want to do it".  I still hope that
model works and that the IESG will reconsider, remove the
DISCUSS, and clear up some of what, IMO, is the mess that seems
to surround it.

To me, that mess includes (almost independent of the particular
document or appeal):

(1) The tracker categories are a matter of IESG decisions, not
of anything on which the community has ever reached consensus or
been asked to do so (something I actually consider a good
thing).  The IESG can change them as needed.   If the current
state of the tools is such that they cannot be changed, then I
believe that 

	(i) the IESG should be having a discussion with the
	IAOC, the Secretariat, and/or the Tools team as needed.
	One of those groups should report back to the community
	with a plan.  
	
	(ii) the IESG consists entirely of very smart people
	with years of experience in the industry.  Even with
	limitations imposed by the tools, I think they could
	figure out contentions to make positions absolutely
	clear to each other and to the community.   

If we have to learn a secret language (e.g., "discuss discuss")
in order to understand the status of a document, and learn it
without a dictionary or glossary, then I think the IETF is in
trouble.  If, as I assume, the absence of that glossary is
either an oversight or a too-low priority, I hope that the IETF
will take this discussion as an indication that it is time to
increase the priority.  The only other possibility I can see is
that the IESG is deliberately trying to confuse the community.
I don't believe that is happening but, if it were, it is time
for people to either grow up or start stepping down.

(2) IMO, the argument that the choice of names in an example is
a technical clarification matter, even as a judgment call, is
_extremely_ hard to justify.   I basically support 2606.  I
think it is generally a bad idea for us to use names that others
have registered and that it is a bad idea for others to register
names that we are using.   I would hope that no editor would use
color.example.com and colour.example.com in the same document in
a way that would leave the reader wondering whether the
difference was intended to make a point or was an editorial
error.  And I would expect that such examples would be swiftly
corrected if they were pointed out and were, in fact, errors.
Even that is an editorial issue, not a substantive technical
one.  There could be cases where it would interfere with clarity
enough to justify a judgment call to hold the document until it
was fixed.  But those cases would be rare and would deserve
explicit justification.  As others have pointed out, there has
been no justification in this case other than "the IESG has been
enforcing 2026 names consistently for at least five years").

Again, until we start using IDNs in examples (where I can
imagine some exceptions), all of those are issues of editorial
style and presentation, not technical substance.   And, until
and unless some descendant of Frank Ellerman's recent draft is
approved, we have no reserved IDN names or guidance anyway.


(3) I believe that it would be perfectly reasonable for the IESG
to decide to require the 2606 names, or to require them unless
justification were explicitly provided and a waiver requested
and granted.  If they want to do that, they should modify the ID
Checklist ("Nits") to say so and adjust the DISCUSS Criteria as
needed to indicate that use of other names is blocking, even for
revisions of documents that used other names.  I would hope that
they would ask for community comment and establish consensus
before reissuing those documents with these provisions, but, if
they didn't, the posting of the documents would make an appeal
possible.

However, if there is one topic in the IETF's discussions in the
last several years about procedures on which there is clear
consensus, it is that the community doesn't like unnecessary
late surprises and considers them destructive.  Regardless of
how the IESG (or anyone else) feels about the use or non-use of
2606 names, having a DISCUSS on this topic show up long after
Last Call, when much of the IESG has signed off on the document,
and with no warning in the various guideline, checklist, and
criteria documents is one of the very worst examples of such a
surprise.  This is not a technical issue associated with a
disagreement about a protocol specification in which the IESG
has to make a judgment call.  It is an editorial/procedural
matter that is easily documented, especially if the IESG has
really applied the criterion to its evaluation of every document
it has touched in the last five years.

Finally, Eric wrote...
> 	Either DISCUSS means what it implies (maybe we add some
> separate status for BLOCK), or we change the state name to an
> intentionally more ambiguous name (like HOLD, or PENDING).

I believe that there is no excuse for ambiguous categories in
this sort of area and that they are a disservice to the
community and the process.  So I want to see less ambiguity, not
more.

and kre wrote...
> If the example domain names were really an issue to anyone,
> that would have been raised during last call.   At that point,
> whether or not rough consensus existed to continue with the
> doc as it was could have been judged.

Yes, exactly.  And the fact that this was discussed, and an
explicit decision reached, months before Last Call makes the
situation even worse, IMO.

best regards,    
    john

 
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]