Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 22:20 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BEC130DCA; Wed, 26 Sep 2018 15:20:25 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 VlHWJD6DJjGI; Wed, 26 Sep 2018 15:20:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 3819E130DDC; Wed, 26 Sep 2018 15:20:22 -0700 (PDT)
X-AuditID: 12074424-62dff70000002757-fd-5bac0623dbdc
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id CF.15.10071.4260CAB5; Wed, 26 Sep 2018 18:20:20 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8QMKHFI027493; Wed, 26 Sep 2018 18:20:18 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QMKDdi006764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 18:20:16 -0400
Date: Wed, 26 Sep 2018 17:20:13 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ospf-segment-routing-msd@ietf.org" <draft-ietf-ospf-segment-routing-msd@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <20180926222013.GT24695@kduck.kaduk.org>
References: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com> <81633BAD-48C9-455B-9CF4-1DB6652E6BF5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <81633BAD-48C9-455B-9CF4-1DB6652E6BF5@cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqravCtibaYNNkJYvJb+cxW9w4tIHJ 4ujXPWwWM/5MZLZYf/Uki8WJJytYHdg8pvzeyOqxc9Zddo8lS34yBTBHcdmkpOZklqUW6dsl cGXc23KYreC9eMX2K+oNjGuEuhg5OSQETCSuN81h7WLk4hASWMwk8WXKNihnI6NEZ8t0Ngjn KpPEww0vmUBaWARUJaa9ncICYrMJqEg0dF9m7mLk4BAR0JTY8h4szCwwj0ni5UZ2EFtYIFfi 2KQzbCAlvEDbGnutIUY2MEqcbmgHG8krIChxcuYTqF51iT/zLoGNZBaQllj+jwMiLC/RvHU2 M4jNKWArce3JMjBbVEBZYm/fIfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3MTOnODVZ tzg5MS8vtUjXXC83s0QvNaV0EyMoCthdVHYwdvd4H2IU4GBU4uGNWL86Wog1say4MvcQoyQH k5Ior8JeoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3nXbgXK8KYmVValF+TApaQ4WJXHeiS2L o4UE0hNLUrNTUwtSi2CyMhwcShK8BaxrooUEi1LTUyvSMnNKENJMHJwgw3mAhleB1PAWFyTm FmemQ+RPMSpKifMygSQEQBIZpXlwvaAkJZG9v+YVozjQK8K8BiBVPMAEB9f9CmgwE9DgCT0r QAaXJCKkpBoYBbbL1Z3LdP6r/7E4JFdSpZblESfLV/nYlQdY/My+r5xePXVP3Dn2uV6FgZ42 e2Q/s/ln/WUy405pezpjfjTHmvXzHl77KMh2+LDZ/ed68wrz+mXWbNx9pO2eV8QFjcUHs3Za TKh2muv47xGTS/8z9XW/K9e2vJ9zxfLgnHWWJ6VcNTf1Zr10VmIpzkg01GIuKk4EAGSNMaUt AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LD_kRk_P4Zto4C2mtE8Wr-gMymQ>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 22:20:26 -0000

Hi Acee,

On Wed, Sep 26, 2018 at 10:14:21PM +0000, Acee Lindem (acee) wrote:
> Hi Ben, 
> 
> On 9/26/18, 6:02 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-ospf-segment-routing-msd-21: Discuss
>     
>     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-ospf-segment-routing-msd/
>     
>     
>     
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     
>     This is essentially a process discuss, and hopefully easy to resolve.
>     
>     In Section 4, we say:
>     
>        The meaning of the absence of both Node and Link MSD advertisements
>        for a given MSD type is specific to the MSD type.  Generally it can
>        only be inferred that the advertising node does not support
>        advertisement of that MSD type.  However, in some cases the lack of
>        advertisement might imply that the functionality associated with the
>        MSD type is not supported.  The correct interpretation MUST be
>        specified when an MSD type is defined.
>     
>     I don't think we can make this sort of normative requirement on a registry
>     created by a different document, at least not without updating the registry
>     to also point to this document.
> 
> Would you be satisfied if the same text were in both the IS-IS and OSPF document? We really want a copy registry for IGPs (which are really only disseminating the information) to Segment Routing capable routers in the routing domain. 

I think that depends on which text you're thinking about.  In particular, I
also asked for the IS-IS document to include in the IANA considerations
some guidance to the experts that the experts need to check this
requirement, and I'm not sure if that would result in just adding text to
the IANA considerations or also removing text from earlier in the document.

On a slightly different note, we do occasionally have things like "[this
other document] placed some requirements on [foo].  Those requirements also
apply here, so we are copying the following paragraph from [this other
document] below for the convenience of the reader", and I could see a
copy+reference working here.

So, if the other document enforces the normative requirement we need, but
we want to call attention to the requirement in this document as well,
copying the text with a note about where it came from should suffice.

Thanks,

Benjamin