Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 24 May 2018 10:36 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BECF12DA1C; Thu, 24 May 2018 03:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 XY43f-pq2uvU; Thu, 24 May 2018 03:36:21 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 21F0E126B6E; Thu, 24 May 2018 03:36:20 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w4OAaHDH004978; Thu, 24 May 2018 11:36:17 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F1462204C; Thu, 24 May 2018 11:36:17 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7D9AD22042; Thu, 24 May 2018 11:36:17 +0100 (BST)
Received: from 950129200 (154.154.51.84.dyn.plus.net [84.51.154.154] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w4OAaEU0025627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2018 11:36:16 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Martin Vigoureux'" <martin.vigoureux@nokia.com>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-teas-actn-framework@ietf.org>, <teas-chairs@ietf.org>, <teas@ietf.org>, <vbeeram@juniper.net>
References: <152715220506.30129.5178063481055865022.idtracker@ietfa.amsl.com>
In-Reply-To: <152715220506.30129.5178063481055865022.idtracker@ietfa.amsl.com>
Date: Thu, 24 May 2018 11:36:08 +0100
Message-ID: <074a01d3f34b$08369d10$18a3d730$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHemPE4CN4MmGe7wOcxwUb4tLuMHKQpXXgQ
Content-Language: en-gb
X-Originating-IP: 84.51.154.154
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23864.002
X-TM-AS-Result: No--7.578-10.0-31-10
X-imss-scan-details: No--7.578-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23864.002
X-TMASE-Result: 10--7.578000-10.000000
X-TMASE-MatchedRID: eVEkOcJu0F6nykMun0J1wmzBijri5+RV+q1Y+/eEArbb6Y+fnTZUL8VJ IRTDvqF7jqkhdl7xWKaORs6i0j/GiL/KM1zCNPCMQ1OcCEvT+bfWSrKtwxqWpbrfxlRjqBJ3cvL IQwkShE5j+HZvQrhSpawI4vzcuzXzFGDwHFCuATQIVoCLGbl5T2uxioJID69RZ5yuplze9ptVNZ igaoBsysk+/tHWTDEajnWUjoc8fIda3gwPCb/m8yArD+K6XhnHrqUopAyOL/Ftw+n+iKWyyJ56G kf9zccsB/S6MOZvOgL2Cbhqa5gU19XXJW/u3j+y2Hdvv/MGE3XFphRdtkn03kN603BMe0MyOXfZ 9OHyzWYeGAwV3/f0fXk48PxckV+kTX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG7hqz53n/yPnonLET 07xvEUd+ZCOhtDP3GkEJFid1udolj10R7X/GvFJeZT8XNJIzV
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/jBc1xG8bavbfYW3xR2BiL8RCcGw>
Subject: Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 10:36:24 -0000

Hi Martin,

Thanks for the comments. Although I am not a front page author, I am answering
the first of the comments because some of the text in question was probably
mine.

I'll leave the rest for Young and Danielle.

> * I'm not sure to understand your definition of Domain. You say:
> Specifically within this document we mean a part of an operator's network that
> is under common management. I'm not sure to understand what common
> means.

The definition of "common" we're using is:
"belonging to or shared by two or more individuals or things or by all members
of a group"

So we could say (note, we also forgot to comma a subclause)
OLD
        Specifically within this document
        we mean a part of an operator's network that is under common
        management.
NEW
        Specifically, within this document,
        we mean a part of an operator's network that is under shared
        operational management using the same instances of a tool and
        the same policies.
END

(But actually, I find the original cleaner)

> Also, you add a sentence after that but it didn't help me, in fact it confused
> me further. Is it the managed entities which have something in common or is
> that the managing entities which have something in common? In the latter case
> what would be the common thing?

The following sentence is:
        Network elements will often be grouped into
        domains based on technology types, vendor profiles, and
        geographic proximity.

Examples of this would be:
- WDM equipment is managed using different instances of tools and
   different policies from TDM equipment
- Optical equipment from vendor A is managed using different instances
   of tools and different policies from vendor B
- A ring or a metro network is usually managed using different instances
  of tools and different policies from other networks

> On that matter, I would suggest to capitalise the first letter of all the
> occurrences of domain which correspond to this definition (with the hope that
> all of them do).

My experience of the RFC Editor is that they really hate that form of
capitalisation. And since *all* mentions of "domain" in this document conform to
this definition, I think the document is consistent and no capitalisation is
needed.

Cheers,
Adrian