IETF Logo Mail Archive

Re: [Last-Call] [Ext] Re: Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

Michelle Cotton <michelle.cotton@iana.org> Wed, 02 December 2020 22:17 UTC

Return-Path: <michelle.cotton@iana.org>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778BF3A158F; Wed, 2 Dec 2020 14:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 SZHvt7Sx66Cp; Wed, 2 Dec 2020 14:17:57 -0800 (PST)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 D98353A157F; Wed, 2 Dec 2020 14:17:56 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0B2MHpme012927 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Dec 2020 22:17:52 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Wed, 2 Dec 2020 14:17:50 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Wed, 2 Dec 2020 14:17:50 -0800
From: Michelle Cotton <michelle.cotton@iana.org>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, tom petch <daedulus@btconnect.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "acm@research.att.com" <acm@research.att.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [Ext] Re: [Last-Call] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard
Thread-Index: AQHWyPj4kr6XazM9qU2Tn8HVMkPmnA==
Date: Wed, 02 Dec 2020 22:17:50 +0000
Message-ID: <0E5520CC-D23F-4CF5-8512-E52CF928AEFF@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3689763470_10336077"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_13:2020-11-30, 2020-12-02 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/rBreSvY3iQRwC-lIEKliI0NHwCY>
Subject: Re: [Last-Call] [Ext] Re: Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 22:17:59 -0000

Hello,

Comments below, see [MC].
If there is any clarification needed for RFC8126, please let us know so that we can include it in a future revision.

--Michelle

On 12/2/20, 7:32 AM, "last-call on behalf of Salz, Rich" <last-call-bounces@ietf.org on behalf of rsalz=40akamai.com@dmarc.ietf.org> wrote:

    Let me comment on this. I've been one of the three TLS registry experts for a couple of years. TL;DR I think the draft is not in conflict with how things are done.


    On 12/2/20, 5:37 AM, "tom petch" <daedulus@btconnect.com> wrote:

        This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7

        ' The responsible AD will appoinht ...'
        RFC8126 seems clear that the IESG appoints and may do so in advance and 
        having more than one is recommended

    Well, the AD is part of the IESG. From what I have seen, registry experts are always appointed by the AD's, as they are expected to be the subject matter experts.

[MC] The Area Director helps identify the expert for a registry, the IESG officially approves/designates the selected person(s).

        'the expert will approve or deny..'
        RFC8126 seems clear that that is the role of IANA.  The expert 
        recommends and it is then up to IANA to act

    IANA's actions are updating the registry. The expert(s) recommendations are binding.

[MC] IANA follows the decisions by the designated experts.  IANA facilitates any communications and makes the approved updates to the registry.

    >    'the expert can approve allocations.
        No, that is the role of IANA; early allocation is possible but that is 
        the decision of IANA.

    If there's an expert, IANA will forward to the expert(s) and ask what to do.

    I think reading Section 5 justifies my views above.  Perhaps 8126 is not internally consistent in some of these details.

[MC] Early allocations are decided by the Working Group Chairs and Area Directors per RFC7120.

    -- 
    last-call mailing list
    last-call@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!vb5C1TPMltwSjmb6uQuf0v8FaQPGdMVixEjosDfvFEccssVXgMmoMzVSf_wUc3idjfPjm3E-gO0$

v2.23.0 | Report a Bug | By Email