Re: [Tzdist] AD review of draft-ietf-tzdist-service-07 - Sections 8 - 10

Ken Murchison <murch@andrew.cmu.edu> Tue, 12 May 2015 16:37 UTC

Return-Path: <murch@andrew.cmu.edu>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795721A8AF4 for <tzdist@ietfa.amsl.com>; Tue, 12 May 2015 09:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_BYLlp3jliP for <tzdist@ietfa.amsl.com>; Tue, 12 May 2015 09:37:19 -0700 (PDT)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41601A8F4F for <tzdist@ietf.org>; Tue, 12 May 2015 09:36:41 -0700 (PDT)
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t4CGadVt009854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tzdist@ietf.org>; Tue, 12 May 2015 12:36:40 -0400
Message-ID: <55522C17.5030302@andrew.cmu.edu>
Date: Tue, 12 May 2015 12:36:39 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tzdist@ietf.org
References: <CALaySJKUcgkMNsFPk0X6ur-Fw0LrB0-miQvAKYJD2rMCEFpBSQ@mail.gmail.com> <88871A9AF67EF351387A3BBF@cyrus.local>
In-Reply-To: <88871A9AF67EF351387A3BBF@cyrus.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.12.161818
X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 33%
X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/nZ49Fm08IDXoc0WZdC_zHWfkkW0>
Subject: Re: [Tzdist] AD review of draft-ietf-tzdist-service-07 - Sections 8 - 10
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 16:37:20 -0000

On 05/12/2015 12:25 PM, Cyrus Daboo wrote:
> Hi Barry,
>
> --On May 7, 2015 at 9:57:05 AM +0100 Barry Leiba 
> <barryleiba@computer.org> wrote:
>
>> -- Section 8 --
>>
>
>> *** You're specifying a Standards Track RFC *and* review by a
>> designated expert.  Why do you need both?  Presumably, time zone
>> experts in the IETF (such as the participant whom the IESG might
>> designate) will be participating in the consensus process anyway.  Why
>> is it good to set up a situation wherein one individual is empowered
>> to override (rather than to participate in and influence) IETF
>> consensus?
>>
>> Small thing: If you want a Standards Track RFC to be required, you
>> should say that the registration policy is "Standards Action", and
>> reference RFC 5226.  If you do *also* want a designated expert, you
>> should use "Standards Action and Expert Review", and you should
>> specify instructions for the designated expert.
>>
>> *** The instructions to the DE should explain what the DE should be
>> considering, and when it's appropriate to decline a registration
>> request ("reject with cause", in your terminology).  It's not
>> acceptable to give a designated expert license to reject a request
>> without any guidance about when that's appropriate.
>
> If others are OK with it, I would be willing to just go with 
> "Specification Required" (as per RFC5226) and provide suitable 
> instructions for the designated expert.

+1


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University