Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 18 September 2020 12:57 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCA33A08C6; Fri, 18 Sep 2020 05:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CzTBVb8n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wwNMANU2
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 Qeev9sJ80Exm; Fri, 18 Sep 2020 05:57:33 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C753A08C7; Fri, 18 Sep 2020 05:57:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45549; q=dns/txt; s=iport; t=1600433852; x=1601643452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gR4l7abus2+FwwMnlVCnCEJQ8AKH2+PewWUU2VHPfWs=; b=CzTBVb8nPn0B4nXafXZgx3TqAY6jCHQSjFml44enze6KpDe4LHZEYFZ+ xcJ2xPhTzVhhN8Ae9aoVVwcFjK0XQGyMLDDnlN/2W0S+sskkHvUhkMz1C gjUj2Fz/MAAk5ZaIFDCrqnzedd2G6QgCITRpeOKbqk3T0fZeYfDYeCxU+ 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AD6yduBQpfRnWd4XZvWst53wHndpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ4PZJju+QtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFbWr3i3qzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNCgB2rWRf/5pdJa1fHQEBAQEJARI?= =?us-ascii?q?BBQUBgg+BIy8pKAdwWS8shDmDRgONTyaYdIFCgREDVQsBAQENAQEjCgIEAQG?= =?us-ascii?q?ESwIXghQCJDgTAgMBAQsBAQUBAQECAQYEbYUvCCUMhXIBAQEBAgESER0BATc?= =?us-ascii?q?BBAsCAQgRAwECIQEGAwICAjAUCQgCBAENBSKDBAGBfk0DDiABDqpYAoE5iGF?= =?us-ascii?q?2gTKDAQEBBYE3AoNrGIIQAwaBOIJxglxLQoZSG4FBP4E4DBCCGDU+glwBAQI?= =?us-ascii?q?BgTMBDiEQCQ0JgmEzggsikA+DIoZ9i3iQCoEACoJniHaRVgMegwyJegaOMIV?= =?us-ascii?q?GknqKYZBvhCwCBAIEBQIOAQEFgWsjgVdwFTsqAYI+UBcCDYM1imo3bgEJgkK?= =?us-ascii?q?FFIVCdDcCBgEJAQEDCXyLHQEngh4BAQ?=
X-IronPort-AV: E=Sophos;i="5.77,274,1596499200"; d="scan'208,217";a="578646656"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2020 12:57:31 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08ICvVVH030449 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Sep 2020 12:57:31 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 07:57:31 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 08:57:29 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 18 Sep 2020 08:57:29 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z7AziPsf6X5Ac9luLmF05q/wcCTCE4sBLl+JD5NKt+15mE6plYpoH0PHg+CZcVfpMSEFq1gLFy7FKW4k8HNJaxFXZ6k4vRzZtcOWQooBxK6FFDmCHnhkNVWVEuK0niC/PkYJghSVviG8ZRYFIT0tsrd9opc36SyFi32dJM2oCyCPlNnBVehYOZ0RJNAa8ACjZNt0FQRiYPDe1vvIwHwP1ymiQ6DikaRKsavJ7PDqQDG8xLthgZssVM6UVeDCxlb0AOFA4o6abcoCXRF6TG3KZfQ3fq4mC57QUYGuzHAqIFekmUBKiKKidcwmleAybf6VaOTQiqqXhHFh+QA2JOSnZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gR4l7abus2+FwwMnlVCnCEJQ8AKH2+PewWUU2VHPfWs=; b=IO0zqSgqBUCN9RP3l1AAVtSwcN6Jz4m7Vl2n6zR9sCXOLO5NtEcTgxVhCtRjWjYw0HXzfqdF3N0cZ8jDrirl27tSW7uJ5pkL59saf6uk85Lqv9WILpTNSd7O4mK9DNitwXJVTQxLTLD+8i5F0pX0EsN1b3YSqhDZOU7skWF3Ky0VPWhyWvaCcB5OIBhFaGYOEaruGHnXHc043cmsHYx/MVSWPtA5nVXIbveELy3xmHx/viaUIXGnY9GRfTLspEPUy3i2N6FZUuSJIaNP6WIxYmvC5xC/M3G+WJRP7fGtL7I4gHhXRfpWZuBkp0riFHnpH1zE7KTm1YSX8/wPR48WFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gR4l7abus2+FwwMnlVCnCEJQ8AKH2+PewWUU2VHPfWs=; b=wwNMANU243drkkvUcP7S8sSqdcQUfgsYLdui9qBaZSnVRvrujGYHrkCqw/PfiUt1ZymRt03rCRenFXrPYfeQHyFGqtFrFZf5xPvgEVMbGlA+1T1uXpvJKx0+iuJ168+fn+CLA83lURUjfngnZim2CMjGdXeF8gkJqSU/a//fCl0=
Received: from BN6PR11MB3875.namprd11.prod.outlook.com (2603:10b6:405:80::37) by BN7PR11MB2836.namprd11.prod.outlook.com (2603:10b6:406:ad::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Fri, 18 Sep 2020 12:57:28 +0000
Received: from BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::6db4:f6de:cc07:487]) by BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::6db4:f6de:cc07:487%6]) with mapi id 15.20.3348.019; Fri, 18 Sep 2020 12:57:28 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Alexander L Clemm <ludwig@clemm.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-nmda-diff.all@ietf.org" <draft-ietf-netmod-nmda-diff.all@ietf.org>
Thread-Topic: [yang-doctors] [netmod] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04
Thread-Index: AQHWi6XXGy8knHCfYEaSiW7jf0az2KlqDqQAgABKnACAA8LnAA==
Date: Fri, 18 Sep 2020 12:57:27 +0000
Message-ID: <0E3A16A2-6ABA-4868-936F-AA6C9AAF3A8E@cisco.com>
References: <159942490640.25028.10946254095755778899@ietfa.amsl.com> <EF21460A-8689-491C-AE19-942C6FA84FFC@cisco.com> <e801c95e-078e-8438-b1a0-18aaf4be3a82@clemm.org> <8759A9BF-300C-46F7-B39F-9EF4CFA2D726@cisco.com> <22126972-0920-1bb3-a73f-f4a219a59bf6@clemm.org>
In-Reply-To: <22126972-0920-1bb3-a73f-f4a219a59bf6@clemm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: clemm.org; dkim=none (message not signed) header.d=none;clemm.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2607:fea8:bee0:52e:f981:8d68:9331:1b05]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bf3b02e6-246c-438b-b5c1-08d85bd265ba
x-ms-traffictypediagnostic: BN7PR11MB2836:
x-microsoft-antispam-prvs: <BN7PR11MB283640136EAA2EB990A01CFAAB3F0@BN7PR11MB2836.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5DR2vAICIdovGxCBuiyneGZl8gs3rlDX5EjHahW6VD/d3o17XDnsWs6l0p7bMAgx2wt0uy8WBCMsf8+qgZrmDzStWjpRT27mUYg5+nzl8RtYuptHDI7xxeW8ESHJKByyHMJeu14wHYRXLRKDIQR88YZmLCwPEvua8hoG7+CvrT3NPQLXB4NJuG9tj4JbvWyh/HK/oir+YgVUubHdZT100jYEni4Zvt/vjQvjRHKbp1DUDUvNc/BCH7HlVdIzEnNPugl49yEvL+4S7e9Xlcy93pAKZlcGkWJO1FfZC02RO5wBpeHI5Wr3xsuaY/iC8aMAD644wAhEAFLMBKhBRpNzz1XUwnqa8zpea/XtP0TshLPGaOReD9rSDGX0NwTuyDlejElbK1yRxQyzctXYmWcfyQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB3875.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(396003)(136003)(366004)(478600001)(5660300002)(8676002)(6486002)(9326002)(36756003)(33656002)(6506007)(4326008)(8936002)(66446008)(76116006)(66476007)(91956017)(66556008)(86362001)(64756008)(53546011)(66946007)(186003)(83380400001)(2906002)(110136005)(54906003)(71200400001)(6512007)(166002)(2616005)(316002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: XcVtwWf0ZAlpFtb8iMt7OoWtsWhPQiP8OFQtT0q2CnQTcMsfgTbsLTX0JCZXz7NY4vIXP6F7Y7LTZFTi+8Vuinf0tga358XYsupA85Q/fi0DiIuSe1FN+OfP6Lfzxk+3oEdR4LbfP1bsMpeSBh78hBP7e/Yf54zqnA0C2XNsQmIyBbKrR0MBKDdBYIWoIIac8I3wceDrkmRZQBfNG7e4raiNXspRgfuoXVfa26sozDy5Yv1MKChzF7zo3B1DdiXglS7zcf/yormzjSpxaAYQOp6FUzkPyv18atN0+Gp/86pjBPbleBGOP9fi/L5TOkgS1YcdJ9Qar+10qgMWU2ch+V3Apkjt7rddVRAHuQKchhcz4hD5WDZiTzeFXJnCW5WZq8GPgOdcgenGIQM6Vwmr+tExWP0+MHnNNbpmeBJmi1JY0Yth3T7c/fyll3AYlOyHQkeKlcF62boe/RulEu3L8RM50waFdM6+AX7GF4QPrdZGwgB4DL5abgdy6GZ3AiG/aDQzMsS4tifuSdCs+WKcyEirsi1kpyfK05iYMDJJ2cvxDi7yHqbL+DvSgWxwbLNvjao+Qw6wUVPWHtvx4fjnfMKFfhN6U8XSsjkLd60drjQ/6dMOKJKMzXpW2Calvc+wRZnfQorRCaoZ20iR+dj2CJP/i9x+shpyAGNiPnEFtHoxsl0ZCmsCs9JxwTnaJ8o7kMNpLz0o6z1SVTAhg23R4Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0E3A16A26ABA4868936FAA6C9AAF3A8Eciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB3875.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bf3b02e6-246c-438b-b5c1-08d85bd265ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2020 12:57:27.9510 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3A6GHMObyw1gqQC7xwNDicKg8FHIZO84pDCmMS0659VjHwjkhWs/XBJ5ZW7yJ+fQYozyLNakT/BMUXOZvPpfyA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2836
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/AutKqPgERksfpjKRPj9AC_R-shw>
Subject: Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 12:57:35 -0000

Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it could be confusing (when should one be used and not the other). Adding some text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm <ludwig@clemm.org>
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>om>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>rg>, "netmod@ietf.org" <netmod@ietf.org>rg>, "draft-ietf-netmod-nmda-diff.all@ietf.org" <draft-ietf-netmod-nmda-diff.all@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating a "remove" or a "delete" in the patch.  Right now it would be acceptable to return either.  If we want to eliminate this freedom, which one would you prefer be used?  Shall we remove the possibility for "delete" and just cover it using "remove"?

Note that the place where this is specified in the model is as part of a condition that specifies when the source value should be included.   If we want to rule out that diff can return either "remove" or "delete" (indeed they are synonymous), we would need to add text to the container description that when a data object is present in the target of the comparison but not the source, that "remove" should be used to indicate that.

The model would be changed follows.  Please confirm if this looks good to you & we'll incorporate it.

OLD

           container differences {

             description

               "The list of differences, encoded per RFC8072<https://tools.ietf.org/html/rfc8072> with an

                augmentation to include source values where

                applicable.";

             uses ypatch:yang-patch {

               augment "yang-patch/edit" {

                 description

                   "Provide the value of the source of the patch,

                    respectively of the comparison, in addition to

                    the target value, where applicable.";

                 anydata source-value {

                   when "../operation = 'delete'"

                     + "or ../operation = 'merge'"

                     + "or ../operation = 'move'"

                     + "or ../operation = 'replace'"

                     + "or ../operation = 'remove'";

                   description

                     "The anydata 'value' is only used for 'delete',

                      'move', 'merge', 'replace', and 'remove'

                      operations.";

                 }

                 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>72>: YANG Patch Media Type";

               }

             }

           }




NEW:

           container differences {

             description

               "The list of differences, encoded per RFC8072<https://tools.ietf.org/html/rfc8072> with an

                augmentation to include source values where

                applicable.  Where a difference include a data object

                in the target that is not present in the source,

                this shall be indicated as a 'remove' operation

                in the patch, not as a 'delete' operation.";

             uses ypatch:yang-patch {

               augment "yang-patch/edit" {

                 description

                   "Provide the value of the source of the patch,

                    respectively of the comparison, in addition to

                    the target value, where applicable.";

                 anydata source-value {

                   when "../operation = 'merge'"

                     + "or ../operation = 'move'"

                     + "or ../operation = 'replace'"

                     + "or ../operation = 'remove'";

                   description

                     "The anydata 'value' is only used for 'merge',

                      'move','replace', and 'remove' operations.";

                 }

                 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>72>: YANG Patch Media Type";

               }

             }

           }

Thanks
--- Alex

On 9/15/2020 4:04 PM, Reshad Rahman (rrahman) wrote:

Hi Alex,



I will review the latest version.



See below for questions/responses.



On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" <yang-doctors-bounces@ietf.org on behalf of ludwig@clemm.org><mailto:yang-doctors-bounces@ietf.orgonbehalfofludwig@clemm.org> wrote:



    Hello Reshad, hello YANG Doctors,



    thank you for your review!  Please find my replies inline, <ALEX>.  We

    have also just posted -05 (thanks, Yingzhen, for doublechecking my

    updates).



    --- Alex on behalf of coauthors



    On 9/7/2020 7:06 AM, Reshad Rahman (rrahman) wrote:

    > <Here's the same message with hopefully more readable formatting>

    >

    > Review of rev -04 by Reshad Rahman

    >

    > The document is clear and well-written. While some issues have been identified, they can be resolved quickly.

    >

<snip>



    > Questions

    >    1.      YANG model: does the operation “delete” make sense for a diff operation? If it is kept, it’d be good to have some text explaining that for a diff operation, “delete” and “replace” are the same? If they’re not the same, please also add some text….

<RR> I actually meant "delete" and "remove".

    <ALEX> Here we are simply referring to the basic YANG-patch edit

    operations per https://tools.ietf.org/html/rfc8072#page-11.  Those are

    in turn derived from <edit-config> operations per

    https://tools.ietf.org/html/rfc6241#page-37.  I am not sure we need add

    to explain those, as we are directly referring to YANG-patch.



    </ALEX>

<RR> The operations are indeed well defined in RFC8072 (copied below), but they are defined from the perspective of YANG-Patch. So for YANG-Patch "delete" and "remove" are different operations, but from a diff comparison I believe they are the same (the resource must exist since it's being returned in a diff)



   +-----------+-----------------------------------------------------------------+

   | delete    | delete a data resource if it already exists; if it    |

   |                | does not exist, return an error                               |

   |                |                                                                                      |

   | remove | remove a data resource if it already exists           |

   +-----------+-----------------------------------------------------------------+



    >    3.      YANG model P9, for the “uses path:yang-patch”, why not have a  reference to RFC8072 (is it because the description above mentions RFC8072)?

    <ALEX> We are clearly referencing RFC 8072; are you suggesting to put a

    reference substatement below the uses statement?   It looks a little

    strange to me but sure, we will add it.

<RR> Not needed.



    >    4.      Section 7 mentions rate limiting requests per client. Should there be a “global” rate-limiting too, i.e not client-specific?



    <ALEX> I am not sure this is really needed as I think the number of

    management clients will in general be fairly limited to begin with, but

    we can certainly add it.  How about the following text:



    OLD:



    One possibility for an implementation to mitigate against such a

    possibility is to limit the number of requests that is served to a

    client in any one time interval, rejecting requests made at a higher

    frequency than the implementation can reasonably sustain.



    NEW:



    One possibility for an implementation to mitigate against such a

    possibility is to limit the number of requests that is served to a

    client, or to any number of clients, in any one time interval, rejecting

    requests made at a higher frequency than the implementation can

    reasonably sustain.

<RR> Good with me.



    </ALEX>



    >    5.      Wondering if section 8 should be in an Appendix (or even removed)? Also, the method suggested doesn’t seem to guarantee that the difference persisted for the “dampening” time.



    <ALEX> Personally, I do think it makes sense to include a brief

    discussion of possible further extensions.  I suggest to keep the

    section if it's okay with you, or perhaps leave it to the chair whether

    they have a preference to remove it.



    </ALEX>

<RR>Whatever the WG/chairs decide is fine with me.



Regards,

Reshad.