ietf
[Top] [All Lists]

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

2008-06-20 08:42:56
John

I have read the documents (all of them).  I know you have been around a long
time and have a good deal of experience but I have been within IETF
processes for some 5 years now (or maybe more - seems like an eternity) and
am fairly familiar with it.

I still come out on the side of the IESG.

Sorry but we have to agree to differ on this.  Nothing personal but probably
due to my ISO experience, I am more for going with standards rather than
finding ways around them with MAYs and SHOULDs.  If there is a
recommendation within a standard IMHO it should be followed.  This is just
my humble opinion - you are welcome to yours.

I don't see what the problem is with following BCP's or with the IESG
putting a simple DISCUSS (albeit temporarily blocking) on your document
because you have not followed one - whether or not you seem to think it
fits.  And, yes, I know that is not what your appeal is about but it does
play a fairly large part nevertheless.  You have taken umbridge at a last
minute decision made by the IESG for an aspect that you think is irrelevant
to the document as a whole - editorial in otherwords.

You state that the IESG has provided a statement as to what they intend to
look at and yet you are now arguing the semantics of that statement.

I think as the IESG Chair has just stated, you should trust in your top
level management.   I would add, you should tell them when they have been
inconsistent in order that they may learn from the experience and revise
their statements as necessary.

Wrt the author's intention for publishing BCP32, it is irrelevant unless
documented within the BCP itself.  We cannot go back to the author for each
BCP or RFC and ask what was the intended use.  The document, as with any
standard, has to stand alone.



Best regards

Debbie





-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: 19 June 2008 19:24
To: debbie(_at_)ictmarketing(_dot_)co(_dot_)uk; 'Dave Cridland'
Cc: 'Pete Resnick'; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis



--On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
<debbie(_at_)ictmarketing(_dot_)co(_dot_)uk> wrote:

Maybe I and a few others thought a BCP was worth something.
Apparently not. Unlike the authors of these documents I am
not privy
to the reasoning behind them  I am just privy to the
document itself.
Neither are countless other people who observe IETF BCP's.
Perhaps I
should not bother recommending BCP 47 (full of MAY's and SHOULD's)
anymore or indeed contributing to the IETF LTRU process.
It obviously
is not worth the digital paper it is printed on.

Debbie,

Please take the time to read the relevant documents, starting
with the full text of the appeal and then the text of "the BCP"
before making comments like this.   RFC 2606/BCP32 very clearly
makes the names available for use where authors find them
useful.  It does not require them, specify that they SHOULD
be used, or call for a community consensus process to
determine the cases in which they might or might not be used.
 The author of that document has commented on this list that
nothing else, especially an implicit requirement, was
intended.  And no one else has been able to cite text in
RFC2606/BCP32 that imposes a
requirement.   But you apparently did not read those notes
either (in addition to not reading the document to which you
claim to be "privy").

The only published requirement for the use of these names is
in the "ID Checklist" (IDNits).  That document is not a BCP.
It is not even an IETF consensus documents.  It is an IESG
statement about what the IESG intends to look at.  And it says "SHOULD
preferably".    Traditionally in the IETF, "SHOULD preferably"
is a WG (or author and editor) decision as to whether there
are grounds for doing something other than what the SHOULD
recommends.  For the IESG to block a document on that basis
turns a SHOULD into a "MUST unless we choose to grant an
exception".  And, in any event, IDNits is not a BCP of any
flavor - there is no evidence of community consensus for
applying IDNits this way.

A sad day for IETF in my book.

They are always sad days for the IETF when people comment
passionately on documents they haven't read and clearly don't
understand and when they fail to read and consider other
comments in a discussion thread before posting remarks of
their own that could have been informed by those comments.

    john









_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>