Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

<Ruediger.Geib@telekom.de> Tue, 05 March 2019 13:19 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C0130FC4; Tue, 5 Mar 2019 05:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 4Hn9k1dD6Qlg; Tue, 5 Mar 2019 05:19:09 -0800 (PST)
Received: from mailout41.telekom.de (MAILOUT41.telekom.de [194.25.225.151]) (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 84C17130F3E; Tue, 5 Mar 2019 05:19:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1551791948; x=1583327948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7u5Hfp72gDysuoGG+XkWAqD4YHH8AtWlVrrPmFTKwgk=; b=dQqqiSMjEVgqFOh0EzTz5rR/0BxesftbZyLwjWcZ4dO4MsHQxzpskVB8 G7Yda9pv+f2q5sJip5sfRtAVKf6KvBPydgy6jYZS7H9Uh1o7Bv8i8GBEy xFMTDCF8/T7bmN+UQ2y3cCvU2bg8s7ANPtWjE5gwGOPBRuUOrCPvNwlhA b/8XrtSeNFkuM68Zy/shte60o3NT+9XBcEYtYx7k1xg3hqvCfUr9t92Yd 4XF7cap08Cu7ueyFC2CaeOfcLhmvjk7UDuzwAyTo25Lu5lA0ydBtmkV2Z TepY+5iiQuE3DBMXORoHYQWiREbSX5isPJegVxtkVcl+q/2R8b2xNNetZ A==;
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 14:19:04 +0100
Received: from he105690.emea1.cds.t-internal.com ([10.169.119.68]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 05 Mar 2019 14:19:03 +0100
Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE105690.emea1.cds.t-internal.com (10.169.119.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 14:19:02 +0100
Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 5 Mar 2019 14:19:02 +0100
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 14:19:03 +0100
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0459.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Tue, 5 Mar 2019 13:19:01 +0000
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189%4]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 13:19:01 +0000
From: Ruediger.Geib@telekom.de
To: gorry@erg.abdn.ac.uk
CC: tsvwg-chairs@ietf.org, tsvwg@ietf.org, iesg@ietf.org, roland.bless@kit.edu
Thread-Topic: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
Thread-Index: AQHUyUAEdpZJCyHpGU+YgDrombg8eqXqrsuAgAFHxbCAAU0sgIAAVJiAgAKeNGCAA+m+gIAADueAgAACbICAAL5/K4AAYN4AgAAfAQCAACTigIAF8XDUgAB7vICAARc6EA==
Date: Tue, 05 Mar 2019 13:19:01 +0000
Message-ID: <LEJPR01MB0460544045836E38F73AE4039C720@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF79DEE@MISOUT7MSGUSRDE.ITServices.sbc.com> <f38b43e8-d300-f44f-1f84-f7652e4f36e2@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF7B8F6@MISOUT7MSGUSRDE.ITServices.sbc.com> <LEJPR01MB04609C8FCFADC32676FE0AB29C7A0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CAKKJt-dQjobkMSKSRenMK3VeEQeny-cZb321dEu5trYCBx5ptg@mail.gmail.com> <CAHw9_iL=aSzLWGL8R4zu1Z4QbNeFHoFgozUPANUYGatm-LpZPg@mail.gmail.com> <CAKKJt-e+6OmqG3EcGwd+92YnL-a=Ry+ymYORdwgO0cxgb1FU6Q@mail.gmail.com> <ed05bc00-2532-3f45-6821-215073f49cc2@gmail.com> <d9bec7c6-6950-f5c9-3f7a-c86db6ea02c9@kit.edu> <CAKKJt-ekXNso=nx697nEV6BwWO0HffEf-KF=m_sr1nLyUnK01w@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C89EF8A872@MISOUT7MSGUSRDE.ITServices.sbc.com> <CAKKJt-cLwshf4KqUW8nCnz1Wb68B56BDQY9ybFj-L0mvzakgJA@mail.gmail.com> <5C7CDC4E.3050606@erg.abdn.ac.uk> <CAHw9_iJC=qbt0CBT9cm6p_xGCcqpTz95MxkDE7jb2_PcVZOsjQ@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C89EF90453@MISOUT7MSGUSRDE.ITServices.sbc.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C89EF90453@MISOUT7MSGUSRDE.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d1da821e-89b3-4e9b-370d-08d6a16d223f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0459;
x-ms-traffictypediagnostic: LEJPR01MB0459:
x-microsoft-antispam-prvs: <LEJPR01MB0459572E374CC16A0697CC5B9C720@LEJPR01MB0459.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(136003)(376002)(39860400002)(396003)(366004)(199004)(189003)(53936002)(478600001)(9686003)(54896002)(236005)(6306002)(55016002)(7736002)(68736007)(33656002)(561944003)(8936002)(66066001)(72206003)(74482002)(76176011)(75402003)(14454004)(71190400001)(2906002)(2351001)(14444005)(85182001)(5640700003)(6916009)(71200400001)(316002)(296002)(54906003)(93886005)(4326008)(85202003)(105586002)(2501003)(256004)(102836004)(476003)(53546011)(1730700003)(8676002)(186003)(81156014)(106356001)(19627235002)(81166006)(52396003)(86362001)(486006)(790700001)(97736004)(5660300002)(6116002)(11346002)(26005)(3846002)(446003)(7696005)(66574012)(777600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0459; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: 1;LEJPR01MB0459;23:GYGTiBxu12N2Oj7FmJtRvy/J6YpMgfu4nkpl4zH0hNCI81VqLtMY6dDLaFZGdOzLTAwbqEFUJVUsHddMZGvuwjZzPnOJrhOfGoAfCOEson0ExqXmscHDPY1PtzInHzDg1ES4zX5STMvO0/YjaV5zDKDtuBWv90u9uoWQ42+kNOtonXbO6zrF/vFEqln7MRwFYmYWmhARXQlYU5Oxr8hppazewpIdHIx5sDAAZCSZJie4fQ2HAuJsAM4soocmWpB0R13bf9lKytlFSIvCNw+LupIMbs1iz/xVj1XvK1trs70QQkVWHg+AfaQVe1YYtRfVQqqdS+OeqvCIqqKs/2U1EHBxNgpue6RlgbpTuahIGAxJF/8DxqtjStM4EfqBYs2AQ2RnD5zCcKaTNDnbYpKuAnJ3rt5/QcYKyv+m6PPXDFrIb5Z2kDZlIIHgerVU4VuNvVIk1LN0aSZU5CPgASLxdzS5gkx6DIUd3T8yZaHB1nq92CxIWWfsiZrDswzK/qt9JQu1nhcDEZG3CsY47XBvope+deQUNJ9Aeu/6fa1oskgD7ay8/6wFYHX/TRBHIiBESwz7NFl4cs18vsu7hhhR5ugXawTcxnG9zmurXN1V/7zGIj5XCxoeSIidAcKlsfwWLxhVEJ3bhc5YwCT3oKL0MPMTJx4wOBuXIE1S+BBptodL5FaveEwco63GWSQolLQ/iqTEfPc80W4VnH/zmY/6r/FPjeNeWa3xRI4ef48dDkLP4VL6T+ZOR0c76OprovNwsYvpHyEuyC8/KC7qdCyerD6XPmwwv/WxDdBHceC27RYmnMnBQ5A+ltwLvFLLP/7x9BybuitQrtESVsUPeGUte0giQC/wHe3d3Q6Kvl7VVMvkq6cycjfJ6oadlE5WF9zmRLEA9u548hDgssbc07f1x7B/Cs/Ch+R1QbtLqHhtxzQe43/MuM1fI0IWv5VjcdKuT7jETOL4L7/kcfmOU5l1VVooxTQRhTj0b8XWGVgvfZLLb7UFGcU2/TZyKZUgz9qq64aYULrSRlVj6saDMpvm9TE2i7ZJgiNcDpepZ3T3sEoY1bleN9MG6iNHiPNQ8lfEMm6acLmJ6Kk60QWm3ijmZgZCItapR08M6QxPcRVjhZ+/Gqz4QP3zDzc7pXABw+58ZxpuHC8rDbk1+axT9ImckVX2xvuC20AXxcvN+4eLqIGCR/Wjb7tzVLxeIaedmjVhcFsYmX5kz+MIITLGPRWDY1s7zH67izLtDzx5HdwostSVa9d9M8HlG/r0XEOvv+sT28NdKRuhEzO65pSNk8QTW7W5bYq9JN1vzvbyUPSmZJzIjTosdOZ+2ZtWd/VzAiq1mzDEFNSQtHo8xpd80uSo7otPQ9oH83vwPouDD/UfGShMVErz6bqA4CPXJpNOWDYuPq73symlpy5ty+1Bu6DFf4dRTqudKb8e0oV62KDVzwkFoLERnz2MMFpCKY/q0CFJXK3MW+ENNcMiGYCeJlT0EtKyuLGOGMgzs23yu9cRyHSzvnzlUkE813CXTTvEM0O8KIOqq18P2vv4D9KSgjmTOBa8RlGOSYx2aqngUg8IEQEH+PHB+vVsSq8tIgghAXgQ
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: HA5FkvMzT+ZNA4hNdrsVYTKqqDUcKyyZXy1pg3jbDsmpo1/h9xrh+l2y2vVM1be640dXPN7C17bxK4DVrOwLq2dSkv2O7H90F04dMJhSDbtFUFhhhnDlnwWvKirqs6ciUtpUmi3uQsDh+NVKFKKTvGi8Zb6I4t5yB8UhVpfwb1uAFY7WxqH7lDSpo8zrJJGEQTTheG4hJBjMkWRFmFzaoPBDiLEJVojnL+wLE9xGJDUESkeqC9SP+wQbHSfdddLBOVb5673/sHd85qdSoR3e9bpGHOAXBZGIEysEO2s7QaB8VPFVCR83Bd6sYCdjvkRkQO4+PXeceBkvQvvET50Ettv2rpoH2FE3MErmagTNMIu7nc1nN39uDAGYfs0o0SP9FZF7RQrETsoFC2EIIsOEuGmfvfVL0ZdwM/seZjVaOAM=
Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0460544045836E38F73AE4039C720LEJPR01MB0460DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d1da821e-89b3-4e9b-370d-08d6a16d223f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 13:19:01.6768 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0459
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wxZaO-lZGvvcjfPuEAuG_38UDMM>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 13:19:13 -0000

Hi Gorry,

I agree to your proposal too.

Regards, Ruediger

Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von BRUNGARD, DEBORAH A
Gesendet: Montag, 4. März 2019 21:39
An: Warren Kumari <warren@kumari.net>; gorry@erg.abdn.ac.uk
Cc: tsvwg-chairs <tsvwg-chairs@ietf.org>; tsvwg@ietf.org; IESG <iesg@ietf.org>; Bless, Roland (TM) <roland.bless@kit.edu>
Betreff: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Ok for me-
Deborah


From: iesg <iesg-bounces@ietf.org<mailto:iesg-bounces@ietf.org>> On Behalf Of Warren Kumari
Sent: Monday, March 04, 2019 8:15 AM
To: gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>
Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>>; tsvwg-chairs <tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>>; IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; Bless, Roland (TM) <roland.bless@kit.edu<mailto:roland.bless@kit.edu>>; Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)



On Mon, Mar 4, 2019 at 3:05 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>> wrote:


I have had a little reflexion on the discussion and I quite agree the
following needs pruned/rewritten:

“However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to L, on a regular basis without consent or knowledge of the
user.”

     And I do agree with pruning this from the normative text:
     “on a regular basis without consent or knowledge of the
     user.”

     However, even though the original had become a little gabled,
     it was an attempt to capture that there *ARE* implications.
     We spent time talking about these implications in the WG and
     a lot of time trying to write text to avoid accidental remarking.

     I am still somewhat unclear how an operator could safely just map
     traffic to the LE   class, without a priori knowing what the flow
     expects. Sure, an operator could setup a BA-classifier and understand
     that application “X” wants this service.. If it does that then that
     traffic will receive the treatment of LE traffic for the rest of the
     path. If I understood the intention, it was to remind people that
     this isn’t just another “lower level” in the diffserv hierarchy -
     traffic mapped to this class needs to be resilient to starvation,
     and expect that this will happen.

     I suggest an explanation could be added after the clause to be
     pruned to avoid this not working out well:

     “Remarking traffic from another PHB results in that traffic
     being "downgraded”. This changes the way the network treats this
     traffic and it is important not to violate the operational
     objectives of the original PHB.”

That sounds reasonable to me.....

W



Gorry

P.S. Roland, I also just saw a few clauses saying “In case ....”, I don’t
know how I missed that in my review, but these read ambiguously to me: I
could it would be better if the phrase was “In the case that”.

On 28/02/2019, 18:30, Spencer Dawkins at IETF wrote:
> Thanks, Deborah!
>
> Roland, could you submit an updated version of this draft, so I can approve
> it before Wednesday of IETF 104? :-)
>
> Thanks,
>
> Spencer
>
> On Thu, Feb 28, 2019 at 10:18 AM BRUNGARD, DEBORAH A<db3546@att.com<mailto:db3546@att.com>>  wrote:
>
>> Yes, I’m ok with the abbreviated sentence as Warren and others suggested
>> “"Non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to LE."
>>
>>
>>
>> Thanks everyone-
>>
>> Deborah
>>
>>
>>
>> *From:* Spencer Dawkins at IETF<spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>
>> *Sent:* Thursday, February 28, 2019 9:27 AM
>> *To:* Bless, Roland (TM)<roland.bless@kit.edu<mailto:roland.bless@kit.edu>>
>> *Cc:* Brian E Carpenter<brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>; Warren Kumari<
>> warren@kumari.net<mailto:warren@kumari.net>>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; BRUNGARD, DEBORAH A<db3546@att.com<mailto:db3546@att.com>>;
>> IESG<iesg@ietf.org<mailto:iesg@ietf.org>>; tsvwg-chairs<tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>>
>> *Subject:* Re: [tsvwg] Warren Kumari's Discuss on
>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>>
>>
>>
>> So, Warren/Deborah, are we good on SHOULD NOT here?
>>
>>
>>
>> Spencer
>>
>>
>>
>> On Thu, Feb 28, 2019 at 2:38 AM Bless, Roland (TM)<roland.bless@kit.edu<mailto:roland.bless@kit.edu>>
>> wrote:
>>
>> Hi,
>>
>> Am 27.02.19 um 22:44 schrieb Brian E Carpenter:
>>> On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote:
>>>> Hi, Warren,
>>>>
>>>> On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari<warren@kumari.net<mailto:warren@kumari.net>>
>> wrote:
>>>>>
>>>>> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF<
>>>>> spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>  wrote:
>>>>>
>>>>>> So, just to follow up,
>>>>>>
>>>>>> On Mon, Feb 25, 2019 at 2:48 AM<Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>  wrote:
>>>>>>
>>>>>>> Deborah, Warren,
>>>>>>>
>>>>>>> IETF doesn't specify SLAs or related text, I agree. The LE
>> performance
>>>>>>> is worse than default forwarding. I'm unhappy if my peer demotes my
>> traffic
>>>>>>> to LE and points to an IETF standard allowing this.  What about:
>>>>>>>
>>>>>>> DISCUSSED CHANGE so far:
>>>>>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT be
>>>>>>> remarked to LE on a regular basis.
>>>>>>>
>>>>>>> SOMEWHAT MORE PRECISELY DEFINED OPTION
>>>>>>> Non-LE traffic (e.g., BE traffic) MUST NOT be
>>>>>>> remarked to LE by default.
>>>>>>>
>>>>>>> I'd like to avoid LE to result in a "default below default" and
>> prefer
>>>>>>> IETF standards not allow fancy interpretations..
>>>>>>>
>>>>>> This document was approved on the last telechat, but we're having a
>>>>>> Discuss-level discussion about it now, which means that I should be
>> taking
>>>>>> this conversation very seriously (because "new technical objections
>> are
>>>>>> always in order").
>>>>>>
>>>>>> Am I understanding that
>>>>>>
>>>>>>     - Deborah (and, IIRC, Warren) are thinking that MUST is the wrong
>>>>>>     answer, because we don't tell operators how to mark traffic in
>> their
>>>>>>     networks, but
>>>>>>
>>>>>>
>>>>> Warren is thinking that, if you provide any sort of SHOULD/MUST
>> guidance
>>>>> regarding when it is appropriate to mark "abnormal" traffic, you have
>> to be
>>>>> able to define what you mean by normal and abnormal...
>>>>>
>>>>> Personally I would think that just: "Non-LE traffic (e.g., BE traffic)
>>>>> SHOULD NOT be remarked to LE." (or MUST NOT) without any qualifiers
>> would
>>>>> be best -- we are not the protocol police and don't have an enforcement
>>>>> arm, so we cannot really stop it. Where I think we run into trouble is
>>>>> saying "It is OK to do this on Thursdays when there is a half moon and
>> the
>>>>> wind blows from the South-East, but not at other times" (what if these
>> is
>>>>> only a slight breeze? Thursday where? or a waxing gibbous moon?) - I
>> think
>>>>> we should just say "You shouldn't remark",with the understanding that
>> some
>>>>> will and not open the "under these circumstances" can of worms at all
--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf