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

"Livingood, Jason" <Jason_Livingood@comcast.com> Thu, 22 August 2019 20:19 UTC

Return-Path: <Jason_Livingood@comcast.com>
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 DAE73120C27 for <iasa20@ietfa.amsl.com>; Thu, 22 Aug 2019 13:19: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 B8QtVSk14ac0 for <iasa20@ietfa.amsl.com>; Thu, 22 Aug 2019 13:19:50 -0700 (PDT)
Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 2FE1712011B for <iasa20@ietf.org>; Thu, 22 Aug 2019 13:19:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1566505187; x=2430418787; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LzCNA1pVdTjmThw0a25cYNEcbqQdvzVieLY7cmX/q4E=; b=wTAzCTq1HywOtwANdT75PUsMaQs9gdAzo4abjKEZJcLkfoVRD5G4+/hfJqgZ74t5 9tQCt0duLGO+hgPGJbI4a083b86A4B2extb9c9x0e+1vW//HHYOOeMqNhvVZI5Uh r5PGB+tjh1coWw441jQXNy6QqqgTKmZ9YFPD3SgmzR4y19UqDmEbXBAQYuJ6hWVc A7AIm7VYn+uhf7lIUhV7walF4YX5q/VxzeP9zxuMnQTFEmu89JbIPj+xSY8jRd1r DMXzw34nYyharyd43L1/+An13StjwrjVjoAbdUVjEbw6w8AtP5CaBjq/cL73RIyh bzELM8OSv4HVguKN7CdbyQ==;
X-AuditID: 60729ed4-20fff700000013e0-23-5d5ef8e34b9b
Received: from COPDCEXC37.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 04.11.05088.3E8FE5D5; Thu, 22 Aug 2019 14:19:47 -0600 (MDT)
Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC37.cable.comcast.com (147.191.125.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 22 Aug 2019 16:19:46 -0400
Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.008; Thu, 22 Aug 2019 16:19:46 -0400
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "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>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-iasa2-rfc2031bis-05: (with COMMENT)
Thread-Index: AQHVWO8rhEpxeeydBk+0CgqeJAJvPKcHnAGA
Date: Thu, 22 Aug 2019 20:19:46 +0000
Message-ID: <A6AE5909-BE85-4CAB-9220-0AA2CFCA8E8B@cable.comcast.com>
References: <156648122791.14805.9428385529523186162.idtracker@ietfa.amsl.com>
In-Reply-To: <156648122791.14805.9428385529523186162.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
x-originating-ip: [68.87.29.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D95BCFAE60E5B04B991C345E0D3E7182@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsWSUDRnsu7jH3GxBrNOallsP/Ca0aL37nd2 iyXTNzJZzPgzkdniTIOlxfKNM5kc2DyWLPnJ5NF05iizx46G58wBzFENjDYlGUWpiSUuqWmp ecWpdlwKGMAmKTUtvyjVNbEopzIoNSc1EbsykMqU1JzMstQifazG6GM1J6GLKWPP+U62gjkG FdMeLGRtYPyj18XIySEhYCLxZ9keVhBbSOAIk8SWqUldjFxAdguTROPbHlYI5zSjxP/NB5lB qtgEzCTuLrwCZosI2EgsvruXGaSIWeAao8S+v+/ZQBLCAnESex5/Y4EoipfYtWw1O4RtJLHz +kewdSwCqhJda1+B1fMKuEhMfneEHeIMX4k9Lx6D9XIK+Ek8O/IczGYUEJP4fmoNE4jNLCAu cevJfCaIFwQkluw5zwxhi0q8fPwPbL6ogL7Ekh+bWSHichI9O1oZuxg5gHo1Jdbv0ocYYyWx YsMpFghbUWJK90N2iHMEJU7OfMIC0SoucfjIDtYJjJKzkGyehTBpFpJJs5BMmoVk0gJG1lWM fJZmeoaGJnqGphZ6RoZGmxjBCWvelR2Ml6d7HGIU4GBU4uFd9jwuVog1say4MvcQowQHs5II b9lEoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe1u7YWCGB9MSS1OzU1ILUIpgsEwenVAPjLvkH Zcc69DhWLu1Wqgxr+HUhob1rVdl1luhbO9sUTRp3NG7bKLduNcvLxLRjzpu+b2669mGLw9pc CT8m0UiTPSxTZQWvfH6q2lW/aROz5r6SRa9r7DuNHtha32X9E9Gx4+cziU3f5d4cCGgIeqNx 4mu7mUBv98KiQG2n1V1H13NfWd2jWvlNiaU4I9FQi7moOBEA36iu+VQDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/IBg8SsmXs7RDe7lMxTPGei8Es1A>
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: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <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:19:52 -0000

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

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

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


Jason

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.