Re: [bess] Benoit Claise's Discuss on draft-ietf-l3vpn-acceptown-community-09: (with DISCUSS)

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 05 February 2015 13:24 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D381A00E0; Thu, 5 Feb 2015 05:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
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 wEHcmOHDL6U4; Thu, 5 Feb 2015 05:24:40 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020C11A00FF; Thu, 5 Feb 2015 05:24:36 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t15DOT05004910; Thu, 5 Feb 2015 13:24:29 GMT
Received: from 950129200 (089144230098.atnat0039.highway.a1.net [89.144.230.98]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t15DOQMD004864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 13:24:27 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Benoit Claise' <bclaise@cisco.com>, 'The IESG' <iesg@ietf.org>
References: <20150204220758.20810.25217.idtracker@ietfa.amsl.com>
In-Reply-To: <20150204220758.20810.25217.idtracker@ietfa.amsl.com>
Date: Thu, 05 Feb 2015 13:24:27 -0000
Message-ID: <02bf01d04147$12125860$36370920$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFUH9ZPIVArkJvEqhcvMl87zNxYTZ3aSb0Q
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21304.007
X-TM-AS-Result: No--4.115-10.0-31-10
X-imss-scan-details: No--4.115-10.0-31-10
X-TMASE-MatchedRID: csPTYAMX1+HWoi+XHWon+PHkpkyUphL99xIiieITJagM74Nf6tTB9gLy tDvV39h+2s6JOBmw1fKx3RgNz941lt4bfP25e5+yFyqkfsPWu1BT4DtiSkMnWKRRX6pnQS+AEFM wn2lXrJcI0eYi5OaHTTZ41+XJiDZUeTbvPcOp7x7Wrh5exXaehoyOql5H9hUNf7RPWCFK8GKraR WKBb9AMqGxElUxUvuyQewviK7geSoYB2fOueQzj4MbH85DUZXy3QfwsVk0UbsIoUKaF27lxV1bR oMJTgJyrBksymD90T6J1MzA85lo7tZpOiLWyRiqzYBieWrKWfxkC+4jzONPiuEAlx4rjdzQcLm3 NqT9L82pYaOJ/u0yJAkCnkA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrnqg/VrSZEiM=
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/5IQOdomXcMEZB4Tf0MS7-k6GV0w>
Cc: rbonica@juniper.net, thomas.morin@rd.francetelecom.com, bess-chairs@ietf.org, draft-ietf-l3vpn-acceptown-community.all@ietf.org, bess@ietf.org
Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-l3vpn-acceptown-community-09: (with DISCUSS)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2015 13:24:41 -0000

Bit disappointed that this is a Discuss.

But let's discuss it.

> Ron's point, part of the OPS-DIR review, look valid to me. Can we please
> discuss it.
> 
> This document is well written and well thought out. It is almost ready
> for publication with one small issue.
> 
> In Section 2.3, the authors say, " ACCEPT_OWN handling SHOULD be
> controlled by configuration, and SHOULD   default to being disabled. IMO,
> they should say, "ACCEPT_OWN handling MUST be controlled by
> configuration, and MUST default to being disabled."
> 
> AFAIKS, you would never want to build a router where ACCEPT_OWN behavior
> is always on and cannot be disabled by configuration. Likewise, you would
> never want to build a router where ACCEPT_OWN behavior is the default.

I reject specifications that control what one might want to build. We produce specs to define interoperable behavior and to ensure the Internet works. We don't legislate for people producing product in niches or that is entirely unsalable.

However, let's separate the two SHOULDs.

Suppose one wanted to build an implementation where the feature is not controlled by configuration and is always disabled?
In that case you would be banned from doing so if "ACCEPT_OWN handling MUST be controlled by configuration", so I would say that "SHOULD" is correct in the first case.

I suspect the second "SHOULD" is a consequence of a compound sentence.
If we had "ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by configuration it MUST default to being disabled" then that might be closer to correct according to what Ron is suggesting.

Thanks,
Adrian

PS. Would have helped if the original review had reached the AD, shepherd, and WG. Maybe also the IETF list.