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

"Aaron Falk" <aaron.falk@gmail.com> Thu, 06 September 2018 20:32 UTC

Return-Path: <aaron.falk@gmail.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 B451C130EBC; Thu, 6 Sep 2018 13:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Snfkrcurr-w2; Thu, 6 Sep 2018 13:32:50 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 24FAE130E9D; Thu, 6 Sep 2018 13:32:50 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id k38-v6so13855458qtk.11; Thu, 06 Sep 2018 13:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=NZL+6iP8murACHfsW2RFB7tyt33FgBw0mluv1BHeC2M=; b=elJuHNtoXqcPoi6oJoWvTGN7wj1TDN5xRgy7xJnXXwwv11nOkcE0m7DIFFa9J7j30C EAfRNbkm18e3lNoNMPYM6hrH88KhvY7F0MKTtPqC5kdtLbqPDaLdyWQk2ln+37TOYU1X 6Yujy7J78wjLQS/51FIAHtOr+H1lYiO2VpkE//PhmR1ZY74pqDOaLbnYxVs0GozFoDX8 46jY3ppj4vj2Ehqivhg4dvVRj8Gxcu+oQKH7DvNeg6FU4aYpAYFFEVIXOB9KbsvKVldC sns4jaq02UrsvLyJ0p2+w35nUMUwNyxEb4+QH1pSvmlvW2MMhdTf+E84cVwSiu3xoUUz k/Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=NZL+6iP8murACHfsW2RFB7tyt33FgBw0mluv1BHeC2M=; b=arQDYjnKTv3f4WWez7+M27HfbyaIGw9HBe8inUw+u8rj7pwpWXQDQqh+wrmgld8K1o 46fLLouyUBl5ekTsuYoH4WM3e+Q9phzZ9nJKQOiyAmBirsxK8ejHJdvKwdTKgNARGZwr PIYu0BCohRzGpPnK/iCwLFjjpDgoOrClpRD9/Tdd/TzAS4lRJir6oIDUqyIlsdTFApVM vF2z4JjNhyWN6m1jq622jwHVVlsE7kbBZGdeYviHVj+5izxOM6SaGhecLsx20LZBf3+z 8tg7+Oue22orf12V53nTr6hKDc2yUEZPhmfGLC5AoNQmVew5lgKKttTWv3eOGFH1HHs+ TiNg==
X-Gm-Message-State: APzg51AenDxepjflq+xirQgQ8Yw/VUs7S8oBWShGTkGnqa2urJdXqMJz eS6p4ULhVbRY/81z4I70QgjNxfr5
X-Google-Smtp-Source: ANB0VdZKl1vgJZuIG7vZJ6+oPf8FivUdQVyCiKTRnMSPlGbbeLX39FMngK0Ypt+K0I2fHCq+9uiU6w==
X-Received: by 2002:ac8:2b83:: with SMTP id m3-v6mr3625052qtm.36.1536265969091; Thu, 06 Sep 2018 13:32:49 -0700 (PDT)
Received: from [172.19.34.27] ([2001:4878:a000:3000:f94b:6e31:e62f:9877]) by smtp.gmail.com with ESMTPSA id g64-v6sm3130411qkc.37.2018.09.06.13.32.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 13:32:48 -0700 (PDT)
From: Aaron Falk <aaron.falk@gmail.com>
To: Robert Sparks <rjsparks@nostrum.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>
Subject: Re: Genart telechat review of draft-ietf-taps-minset-08
Date: Thu, 06 Sep 2018 16:32:46 -0400
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <538BF445-10AC-4433-948C-F96287656E1A@gmail.com>
In-Reply-To: <61622b5c-438e-da04-a363-1ff9eafab556@nostrum.com>
References: <153626446703.11686.5776675418414453097@ietfa.amsl.com> <1F34FB48-249B-4CF1-B393-6EE896D03231@gmail.com> <61622b5c-438e-da04-a363-1ff9eafab556@nostrum.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_E3B12107-6596-46C3-A18C-D699CDE39941_="
Embedded-HTML: [{"HTML":[544, 3575], "plain":[148, 1985], "uuid":"CCA6BBEA-5457-4E5F-B5F2-13473F50F64A"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/F2KHH2AGCsGli_E-S6GFv_vXqHQ>
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:32:52 -0000

Robert-

Thanks for the (quick) clarification.  I misunderstood the intent of 
your note.

--aaron

On 6 Sep 2018, at 16:30, Robert Sparks wrote:

> 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
>>