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

["Debbie Garside" <[e-mail]>]

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:[e-mail]]
> Sent: 19 June 2008 19:24
> To: [e-mail]; 'Dave Cridland'
> Cc: 'Pete Resnick'; [e-mail]; [e-mail]
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
>
>
> --On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
> <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf