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

"Debbie Garside" <debbie@ictmarketing.co.uk> Fri, 20 June 2008 15:42 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67CF3A6A81; Fri, 20 Jun 2008 08:42:23 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3A13A6841; Thu, 19 Jun 2008 16:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Level:
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y9bATArZvR8; Thu, 19 Jun 2008 16:27:38 -0700 (PDT)
Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id 4ED8F3A6930; Thu, 19 Jun 2008 16:27:38 -0700 (PDT)
Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50008202594.msg; Fri, 20 Jun 2008 00:37:35 +0100
X-Spam-Processed: mx1.nexbyte.net, Fri, 20 Jun 2008 00:37:35 +0100 (not processed: message from trusted or authenticated source)
X-MDRemoteIP: 62.197.41.145
X-Return-Path: prvs=1056031e63=debbie@ictmarketing.co.uk
X-Envelope-From: debbie@ictmarketing.co.uk
Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 20 Jun 2008 00:27:27 +0100
From: "Debbie Garside" <debbie@ictmarketing.co.uk>
To: "'Pete Resnick'" <presnick@qualcomm.com>
References: <8832006D4D21836CBE6DB469@klensin-us.vbn.inter-touch.net> <485590E2.3080107@gmalcom> <p06250116c47c330c7dd0@[75.145.176.242]<4856DE3A.3090804@gmail.com> <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110> <23618.1213785541.031305@invsysm1> <059901c8d132$d65df170$0a00a8c0@CPQ86763045110> <23618.1213788490.265871@invsysm1> <069801c8d185$56f8a350$0a00a8c0@CPQ86763045110> <939E706761CC64A67D89C422@p3.JCK.COM> <07b701c8d23d$e27fe650$0a00a8c0@CPQ86763045110> <p06250107c4805f15a3c9@[75.145.176.242]>
Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Date: Fri, 20 Jun 2008 00:26:43 +0100
Message-ID: <07c801c8d263$f16f7d30$0a00a8c0@CPQ86763045110>
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjSQofq28h575NuQIK3LbLaJpZPkAAA0YHw
In-Reply-To: <p06250107c4805f15a3c9@[75.145.176.242]>
X-MDAV-Processed: mx1.nexbyte.net, Fri, 20 Jun 2008 00:37:37 +0100
X-Mailman-Approved-At: Fri, 20 Jun 2008 08:42:22 -0700
Cc: 'John C Klensin' <john-ietf@jck.com>, ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: debbie@ictmarketing.co.uk
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Pete

You should read my original message (17th June) where I talk about BCP's in
general.  I am not aware of quoting MAY's and SHOULD's wrt RFC2606 but
rather in general terms - if I have, I apologise for the error.  I have been
speaking very generally about BCP's and what I consider to be good practice.

It has been (and still is) my opinion that a BCP should be followed unless
good cause and reasoning is shown to the contrary.  Please do not
misinterpret the word "follow" but rather read my view (below) on BCP's
(which is, after all, only my view).

Should we decide for each RFC when, where and if we will follow BCP's?

Perhaps you and John are right... perhaps I don't understand what is going
on.  I just follow (and write) standards and for me a BCP is a standard that
should be followed where possible whether the wording is: IT MIGHT BE BEST,
MUST, SHOULD, MAY, or ONLY ON WEDNESDAYS! (I have a great sense of humour
Frank but not on Thursdays or when using my pink mouse ;-)).

Extract of BCP37

2. TLDs for Testing, & Documentation Examples

   There is a need for top level domain (TLD) names that can be used for
   creating names which, without fear of conflicts with current or
   future actual TLD names in the global DNS, can be used for private
   testing of existing DNS related code, examples in documentation, DNS
   related experimentation, invalid DNS names, or other similar uses.

It is my understanding that the DISCUSS was put in place because John's RFC
does not follow this BCP for Documentation Examples.  Maybe I am wrong but
this is my understanding.  The fact that this is a BCP means (for me) that
it does not need a MUST or SHOULD.  It *IS* Best Current Practice for
examples in IETF documentation by title alone.  Just my humble opinion.


Extract of BCP 9

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

The IESG is surely following BCP 9 (and thus not making up their own rules)
and my interpretation of this section on BCP's is that a BCP is the best way
forward (and thus should be "followed") for the use of whatever it documents
- whether it be example domains within RFCs and BCPs or language tags (which
is more my field).  Maybe I am wrong on this too.  I hope not as I have
spent several years following and contributing to one.

If I was writing an RFC I would follow any damn BCP that the IESG/IETF cares
to put in front of me and I really do not see the problem with that unless
it gets in the way of technical development within the IETF - in which case
I would be highlighting said BCP for an update and informing IESG and ADs
etc. as to why it cannot be followed.  This is not the case here IMHO.  This
BCP does not infringe upon any technical development and thus there is no
right to appeal (I may have this bit wrong but I am sure I read it somewhere
- doubtless someone will correct me if I have).  However, IMHO the case for
a DISCUSS is considered technical because the document does not follow "the
best way to perform" this operation according to a BCP which according to
BCP 9 - which documents the Internet Standards process - is as ratified by
the IETF community and not just the WG and the Author in question.

This is my final final word as I think you have all heard enough on my views
and whilst I am very open to other people's opinions, I have not heard
anything here to change my mind. As my opinion seems to differ from yours
and John's substantially, I obviously have not read the documents properly,
have completely misinterpreted them and completely failed to understand them
for which I, of course, apologise :-)

Best regards

Debbie Garside






> -----Original Message-----
> From: Pete Resnick [mailto:presnick@qualcomm.com]
> Sent: 19 June 2008 20:22
> To: debbie@ictmarketing.co.uk
> Cc: 'John C Klensin'; 'Dave Cridland'; iesg@ietf.org; ietf@ietf.org
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> <x-flowed>On 6/19/08 at 7:54 PM +0100, Debbie Garside wrote:
>
> >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.
> >[...]
> >I don't see what the problem is with following BCP's
>
> Please identify ANYWHERE in this BCP (RFC 2606) that says
> that anybody MUST, SHOULD, ought to, might want to think
> about, or otherwise really really needs to, use these domain names.
>
> Anywhere. Please quote text.
>
> Your repeated statements that you think there is something in
> that BCP that "should be followed" indicate that you have not
> read the BCP.
>
> The BCP registers names so that they can be used if one wants
> to. It does not say that they must be used in RFCs. It does
> not even recommend their use. It only registers the names.
>
> Perhaps the ISO is different and they don't actually say what
> they mean when they write a document. That has not been my
> experience reading ISO documents, but perhaps it's because I
> work in the IETF.
>
> pr
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax:
> (858)651-1102
>
>
>
>




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