Re: [Iasa20] Benjamin Kaduk's No Objection on draft-ietf-iasa2-rfc2031bis-05: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 22 August 2019 20:24 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B80412011B; Thu, 22 Aug 2019 13:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 HvKUN8HHrjh9; Thu, 22 Aug 2019 13:24:05 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EC812011E; Thu, 22 Aug 2019 13:24:05 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7MKNukF012550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 16:23:59 -0400
Date: Thu, 22 Aug 2019 15:23:56 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-iasa2-rfc2031bis@ietf.org" <draft-ietf-iasa2-rfc2031bis@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>, "iasa2-chairs@ietf.org" <iasa2-chairs@ietf.org>, "iasa20@ietf.org" <iasa20@ietf.org>
Message-ID: <20190822202355.GO60855@kduck.mit.edu>
References: <156648122791.14805.9428385529523186162.idtracker@ietfa.amsl.com> <A6AE5909-BE85-4CAB-9220-0AA2CFCA8E8B@cable.comcast.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A6AE5909-BE85-4CAB-9220-0AA2CFCA8E8B@cable.comcast.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/Jg6Ir3oUkiushZr9_afVN7MiSwo>
Subject: Re: [Iasa20] Benjamin Kaduk's No Objection on draft-ietf-iasa2-rfc2031bis-05: (with COMMENT)
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 20:24:13 -0000

On Thu, Aug 22, 2019 at 08:19:46PM +0000, Livingood, Jason wrote:
> Thanks also for these changes! This will be incorporated into -06 shortly.
> 
> In Section 5, on ISOC taking IAB advice: not sure they have anything formal, you may want to ask them if this is important to you (I don’t think it must be resolved for the purpose of updating this document).

It's not that important to me.

> In Section 6, IETF is in charge of changing IETF documents.

I guess it depends on whether "rights to change these documents" means "to
prepare derivative works" or something else.  "rights to distribute
different content under the same RFC NNNN name" is perhaps of academic
interest, I suppose, but unlikely to ever happen in practice.
My understanding was that the Trust does not have the exclusive right to
produce derivative works for some (pre-2008) RFCs, even if it does have the
right to do so.

> In Section 7, not sure what the question is... The IETF is solely responsible for IETF working groups - ISOC plays no role in that.

Are, e.g., "IETF working groups" part of the "IETF administration" (as
opposed to, say, the "IETF workflow")?  This seems like basically an
editorial question and I'm not sure what the intent was, anyway.

Thanks,

Ben

> 
> On 8/22/19, 9:40 AM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-iasa2-rfc2031bis-05: No Objection
>     
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>     
>     
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc2031bis/
>     
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Section 1
>     
>        The growth of the Internet over several decades also led to the
>        growth of the IETF.  More and more people, organizations, and
>        companies rely on Internet Standards.  Non-technical issues, such as
>     
>     I suppose we can ignore the elephant in the room that the Internet runs on
>     Proposed Standards.
>     
>     Section 2
>     
>        community.  Open standards are an explicit part of one of the focus
>        areas in ISOC's mission: Advancing the development and application of
>        Internet infrastructure, technologies, and open standards.
>     
>     Perhaps a reference to https://www.internetsociety.org/mission/ is in
>     order?
>     
>     Section 3
>     
>        The IETF remains responsible for the development and quality of the
>        Internet Standards.  Apart from the roles described below, the IETF
>        and ISOC acknowledge that ISOC has no influence whatsoever on the
>        technical content of Internet Standards.
>     
>     As for Roman, this struck me as perhaps overly strong, and perhaps
>     intended to refer to "organizational" influence or influence "as an
>     institution", though perhaps the later text about involvement of ISOC
>     employees "as individual contributors rather than on institutional
>     grounds" suffices.
>     
>     Section 5
>     
>        The charter of the IAB (Internet Architecture Board) [RFC2850] states
>        that "the IAB acts as a source of advice and guidance to the Board of
>        Trustees and Officers of the Internet Society concerning technical,
>        architectural, procedural, and (where appropriate) policy matters
>        pertaining to the Internet and its enabling technologies".  This
>     
>     Is there anything on the  ISOC side that documents how they accept
>     advice from the IAB or reach out to the IAB for such advice?
>     
>     Section 6
>     
>        trademarks, copyrights, and intellectual property rights.  As part of
>        the IETF Trust arrangement, IETF standards documents can be freely
>        downloaded, copied, and distributed without financial or other
>        distribution restrictions, though all rights to change these
>        documents lie with the IETF.  The IETF Trust also provides legal
>     
>     Is that truly "all rights" or only as it applies to documents published
>     under the RFC 5378 terms (as opposed to, say, the "pre5378Trust200902"
>     ipr attribute in the XML vocabulary)?
>     
>     Section 7
>     
>        Under the new IASA 2.0 structure, the IETF is solely responsible for
>        its administration, including the IETF Trust, IAB, IESG, IETF working
>        groups, and other IETF processes.  A further exploration of this can
>     
>     I'm not sure whether there's a nit here or not, but it kind of reads
>     like this is saying that (e.g.) "IETF working groups" are part of the
>     IETF's "administration", which requires a certain mindset to seem true.
>     
>     Section 13
>     
>     I agree with the secdir reviewer that having a link to the LLC
>     operational agreement would be helpful.
>     
>     
>