Re: [Pce] Warren Kumari's No Objection on draft-ietf-lsr-pce-discovery-security-support-11: (with COMMENT)

warren@kumari.net Thu, 06 October 2022 13:10 UTC

Return-Path: <warren@kumari.net>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A302C14F5E1 for <pce@ietfa.amsl.com>; Thu, 6 Oct 2022 06:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zbIxjd25YG6 for <pce@ietfa.amsl.com>; Thu, 6 Oct 2022 06:10:55 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A729C1524D1 for <pce@ietf.org>; Thu, 6 Oct 2022 06:10:55 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id o65so1218868iof.4 for <pce@ietf.org>; Thu, 06 Oct 2022 06:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/y8rGk4dEKQjNFlmVqPkVHYvg2LTExUBNsJwMdF5A9w=; b=XXSOF0gE1odFypwICdHKEZIH22XyF3kRBAVjHJI4MTh6UK6gp9nXlICyLx5kU9ZXjc yV43Un8/LS0y8N35HngdHJs/IkM/j6DQu9EoydD6upM84zMPEFbyxvoPjWMtjVasc0Jt +w1ZJfSaJ1EnVprldfMBxAmYncVyUSpkyaOSaQDQFKT/mA+4nFQfshfQ81ys7H1sOnmp /AnQsBcINeiLU5sIupe2J4upXjg64Ug4bTB271L/rw3jRmaRuHgjM2JYE6twDckNR0IE yqNKPXO4Rs4ZxVbrxqd+LwvjYmmT5yM4QpuUHXRrqf6Zvqo2aNyXnjMYe3Kv3t7Mh5ej ksXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/y8rGk4dEKQjNFlmVqPkVHYvg2LTExUBNsJwMdF5A9w=; b=NdArZu6Awi5FxMKSq/7DVRaR+0/y//LnbZ3koGoakV2rydITmB6N5Fh+KrAnLe6mam wvhytLh1M2ljLRHWhhs0dMp8AGs0kY151rGoiGVz9NQbvcpI/4wOW9yxvQqMvsXQEzFW lPYcA/JiUh6t/k/DEzLa6MzN6nhw77pNf93BM0+LKyM+HlndUC3X6gsb+t39dlaSxdMr jn7A9LbM6SYTnGhd2DuJfcKmJ4ZYwpk8s+g9uCYqGCUF2UWiK82UKHonnrrlPA1TzkNh GWVqfrPw5Aag2yJHRUy6IwmswmJs4pbepAAnhc/6P9JF4MjcQrgL/Pw+HlUcXz3hkIDA siAA==
X-Gm-Message-State: ACrzQf32jCu3x0ar+4AViGx49+YgNlT9cCN/FXdzWvjBbSwYlvHoHlvp C9tjbDxPibUmo4c8LL0NoPwyKgxlQH1NcZjh6vauZQ==
X-Google-Smtp-Source: AMsMyM6InBtkBYKaQM6x5Xn2IxQEucOMpuz0nvaslYeRdGm1j1tgb7X/NWfmtkAHXsFLpaHfq/M9+pMFFHa35akxl3I=
X-Received: by 2002:a05:6602:2c4c:b0:6a2:faa5:79bc with SMTP id x12-20020a0566022c4c00b006a2faa579bcmr2085810iov.84.1665061853781; Thu, 06 Oct 2022 06:10:53 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 6 Oct 2022 15:10:52 +0200
Mime-Version: 1.0
X-Superhuman-Draft-ID: draft007920017b48f44a
References: <166500792646.52178.16628668590244281657@ietfa.amsl.com> <CAB75xn6=aKB2mLoxKALtVmJZJr1Tm3v_-afBmt08StS9U4bdSg@mail.gmail.com>
From: warren@kumari.net
X-Superhuman-ID: l8x2tog6.e22320b7-2118-4b4e-928a-71d6138c4622
X-Mailer: Superhuman iOS 10062
In-Reply-To: <CAB75xn6=aKB2mLoxKALtVmJZJr1Tm3v_-afBmt08StS9U4bdSg@mail.gmail.com>
Date: Thu, 06 Oct 2022 15:10:52 +0200
Message-ID: <CAHw9_iLL=G+e6soMG318ukSVc-48ti9u3eaaDsPXjSnf_O=S-A@mail.gmail.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lsr-pce-discovery-security-support@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Acee Lindem <acee@cisco.com>, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000052fe8a05ea5d6ce9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/EHpeT0SMKpYHMk313XmODPhOwSw>
Subject: Re: [Pce] Warren Kumari's No Objection on draft-ietf-lsr-pce-discovery-security-support-11: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2022 13:10:59 -0000

 Wow!

I didn't expect you to go to that much trouble just to make me happy, but
that all looks great to me.

Remind me that I owe y'all a frosty beverage in London (assuming you are
going)

Thank you all again,
W


On Thu, Oct 6 2022 at 9:05 AM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

> Hi Warren,
>
> Thanks for your review. Apologies for making you sad (we definitely
> don't want that :)! How about this text instead of removing ->
>
>
> 6.  Management Considerations
>
>    Manageability considerations for PCE Discovery are addressed in
>    Section 4.10 of [RFC4674] and Section 9 of [RFC5088] [RFC5089].
>
> 6.1.  Control of Policy and Functions
>
>    A PCE implementation SHOULD allow the following parameters to be
>    configured on the PCE:
>
>    *  support for TCP-AO
>
>    *  the KeyID used by TCP-AO
>
>    *  Key Chain Name
>
>    *  support for TLS
>
> 6.2.  Information and Data Model
>
>    The YANG model for PCEP [I-D.ietf-pce-pcep-yang] supports PCEP
>    security parameters (key, key chain and TLS).
>
> 6.3.  Liveness Detection and Monitoring
>
>    Normal operations of the IGP meet the requirements for liveness
>    detection and monitoring.
>
> 6.4.  Verify Correct Operations
>
>    The correlation of PCEP security information advertised against
>    information received can be achieved by comparing the information in
>    the PCED sub-TLV received by the PCC with that stored at the PCE
>    using the PCEP YANG.
>
> 6.5.  Requirements on Other Protocols and Functional Components
>
>    There are no new requirements on other protocols.
>
> 6.6.  Impact on Network Operations
>
>    Frequent changes in PCEP security information advertised in the PCED
>    sub-TLV may have a significant impact on IGP and might destabilize
>    the operation of the network by causing the PCCs to reconnect
>    sessions with PCE(s).  Section 4.10.4 of [RFC4674] and Section 9.6 of
>    [RFC5088] [RFC5089] list techniques that are applicable to this
>    document as well.
>
> Thanks!
> Dhruv
>
>
> On Thu, Oct 6, 2022 at 3:42 AM Warren Kumari via Datatracker <
> noreply@ietf.org> wrote:
>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-lsr-pce-discovery-security-support-11: 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/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I started ballotting DISCUSS on this, but, surprisingly, "You made Warren
>> sad"
>> isn't actually one of the DISCUSS criteria, and so I'm (grudgingly and
>> with bad
>> grace) balloting NoObj instead.
>>
>> ----
>> 6.  Management Considerations
>>
>>    A configuration option may be provided for advertising and
>>    withdrawing PCEP security capability via OSPF and IS-IS.
>> ----
>>
>> This section seems more than pointless to me - it seems (admittedly very
>> slightly!) harmful. It doesn't actually *say* anything useful, but the
>> very act
>> of it showing up in the index / table of contents gives the impression
>> that
>> there may be actually Management Considerations text somewhere below. This
>> initially made me all excited, and set my heart a flutter -- only to be
>> crushed
>> when I actually read it.
>>
>> Please consider ripping the section out - AFAICT, it doesn't accomplish
>> anything, other than leading to false hope...
>>
>>
>>
>>