Re: Genart telechat review of draft-ietf-taps-minset-08

Robert Sparks <rjsparks@nostrum.com> Thu, 06 September 2018 20:31 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B234130F3F; Thu, 6 Sep 2018 13:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 0I5iBrsgPtkJ; Thu, 6 Sep 2018 13:31:02 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A77F130F53; Thu, 6 Sep 2018 13:31:02 -0700 (PDT)
Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w86KV0vc095943 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Sep 2018 15:31:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local
Subject: Re: Genart telechat review of draft-ietf-taps-minset-08
To: Aaron Falk <aaron.falk@gmail.com>
Cc: gen-art@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org, Editorial Board <rfc-ed-board@rfc-editor.org>, RFC Editor <rfc-editor@rfc-editor.org>
References: <153626446703.11686.5776675418414453097@ietfa.amsl.com> <1F34FB48-249B-4CF1-B393-6EE896D03231@gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <61622b5c-438e-da04-a363-1ff9eafab556@nostrum.com>
Date: Thu, 06 Sep 2018 15:30:59 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1F34FB48-249B-4CF1-B393-6EE896D03231@gmail.com>
Content-Type: multipart/alternative; boundary="------------863CF26986A324007101B2CF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mnoNR-AhMbjxab7JodF7ECvlc8o>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Thu, 06 Sep 2018 20:31:11 -0000

Aaron -

To be a bit more clear, my point is to twist the IESGs arm about recent 
pushback on WGs publishing requirements documents...

RjS


On 9/6/18 3:22 PM, Aaron Falk wrote:
>
> On 6 Sep 2018, at 16:07, Robert Sparks wrote:
>
>     (Repeating one thing from my Last Call review for the benefit of
>     the IESG):
>
>     This was a big effort, and it appears that it was helpful to the folks
>     working on the interface document, but it's not clear how it will be
>     useful to implementers. The IESG should consider whether this, like
>     requirements documents, needs to be in the RFC series. The most likely
>     use I can see in the future would be for historians, and a different
>     and shorter presentation would serve them better.
>
> Hi Robert-
>
> This seems like more useful information for RFC Editor than for the 
> IESG. According to RFC2026 the IESG's criteria for publication for 
> Informational RFCs are:
>
>     4.2.2 Informational
>
>     ... The Informational
>     designation is intended to provide for the timely publication of a
>     very broad range of responsible informational documents from many
>     sources, subject only to editorial considerations and to verification
>     that there has been adequate coordination with the standards process
>     (see section 4.2.3).
>
> and
>
>     6.1.2 IESG Review and Approval
>
>     The IESG shall ... determine whether or not the technical quality
>     and clarity
>     of the specification is consistent with that expected for the
>     maturity level to which the specification is recommended.
>
>
> So, I don't think the IESG gets to decide that it doesn't belong in an 
> RFC just because it doesn't it wouldn't be useful to implementors or 
> historians (only two of many RFC audiences). I suggest you take your 
> concerns up with the TAPS working group, who thought it was important 
> to document their analysis, and/or Heather (cc'ed).
>
> --aaron
>