Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Mon, 04 March 2019 17:49 UTC

Return-Path: <ncamwing@cisco.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95998130DE5; Mon, 4 Mar 2019 09:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Ll1eNFcb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GP5200a8
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 GKUi35Guo_Rm; Mon, 4 Mar 2019 09:49:43 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6AA130DD6; Mon, 4 Mar 2019 09:49:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52399; q=dns/txt; s=iport; t=1551721783; x=1552931383; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZkPTh/ulAtGK2Krep45MVFXd+jNTnLNhNxkcRgEamSE=; b=Ll1eNFcbiHx8DdgZifZmnpIUW2pGlIcjm+kwrygYRdK3573z8QE6gP4y wTaMi4x0OFRsiL0a2fZEyrg9ESvkL0gQvp+kvGLwVlOOFcrCdcKR8eo1z fAuUBdnswcLsxQD08LLtg/5abP1ShJkdqb7cBjxOEWY+KHR8GoT+dvg95 k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AGrbe0B0bRWMkO9cRsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQD0byKeHraSMSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAAAFZH1c/5FdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDS9QA2h0BAsnhAiDRwOPUYNTmEkDVAsBASy?= =?us-ascii?q?EQAIXhA4iNwYNAQEDAQEDAQMCbRwMhUsGGgkdAQE3AQ8CAQglCwgBCQICAjA?= =?us-ascii?q?lAgQBCQQFgyIBgRFMAxUBnh8CihRxgS+CeAEBBYR+GIILCIEvAYhfgkgXgX+?= =?us-ascii?q?BEScfghc1hFoRZYI7MYImiXEkLoFXKoQFhySMGQkCknIZgXSFYoNIiASKZJI?= =?us-ascii?q?jAgQCBAUCDQEBBYFdIoFWcBU7KgGCQYIKBwUXE4M4ilNygSiNICSCKQEB?=
X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208,217";a="528600073"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 17:49:41 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x24Hnedf022999 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Mar 2019 17:49:40 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 11:49:40 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 11:49:40 -0600
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 4 Mar 2019 11:49:39 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZkPTh/ulAtGK2Krep45MVFXd+jNTnLNhNxkcRgEamSE=; b=GP5200a80Sbj9U1jSBo7sxGUyCHKefYZ5qNFomL2qXywRFya8906N4clmDWmwcbpQ68ZHMk7hXpBIhLwoD/cq7r53kMNxLOQJy1hm6xbBVeiIrkiEfLjg9mQ125BCDeDskyEdhftEpUuKXktMYaWrUc6IfnK84YYMeDmgNppTgE=
Received: from BN6PR11MB1732.namprd11.prod.outlook.com (10.175.99.7) by BN6PR11MB1651.namprd11.prod.outlook.com (10.172.23.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Mon, 4 Mar 2019 17:49:38 +0000
Received: from BN6PR11MB1732.namprd11.prod.outlook.com ([fe80::3df6:de14:447c:4146]) by BN6PR11MB1732.namprd11.prod.outlook.com ([fe80::3df6:de14:447c:4146%3]) with mapi id 15.20.1665.019; Mon, 4 Mar 2019 17:49:38 +0000
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mile-xmpp-grid@ietf.org" <draft-ietf-mile-xmpp-grid@ietf.org>, "mile@ietf.org" <mile@ietf.org>, "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>
Thread-Topic: Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
Thread-Index: AQHUssnCkAHCbRabj0eWurJ2legGGKXw68MAgAHt/4CAARQ2gIACFP4AgAV2oAA=
Date: Mon, 4 Mar 2019 17:49:38 +0000
Message-ID: <840D870A-36F9-4B32-918B-8F4A3D04EBDF@cisco.com>
References: <154821326562.13271.17282561556237229622.idtracker@ietfa.amsl.com> <4BD85B49-9F10-4724-B5C7-B4257D8A83CD@cisco.com> <8125411B-783D-4469-B60B-422FA4E447FF@cisco.com> <50DCB5B2-8045-4878-ACA2-A9BE1246DFF1@cisco.com> <C92CD6AF-CC03-4734-8CB4-2FACD071EBFC@cisco.com>
In-Reply-To: <C92CD6AF-CC03-4734-8CB4-2FACD071EBFC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.7.190210
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com;
x-originating-ip: [2001:420:292:1260:1dfe:3a6c:3efe:7107]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 59db95e3-2dea-4f63-967f-08d6a0c9c5b6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1651;
x-ms-traffictypediagnostic: BN6PR11MB1651:
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjExTUIxNjUxOzIzOnlabnZYUTUxVGx4RkVWNzBvc0lzSVR1cVY3?= =?utf-8?B?S0dIUlN1Q1YwRUdZNWdDaWFqb2pFVng5cGR6WkQreGxFTXZWMzdwTkt4UDlu?= =?utf-8?B?clJjK3A4ODNkRFdrOGlmN2xMSXdheElldTUraldIWW03NTFic0lBRmpaa3lt?= =?utf-8?B?T2U1R3BjNW93MmFFMkxDczEyNG9IUGoxQ0ViZ2J2OVVuWmUzczB6eXoxYUhT?= =?utf-8?B?Ky9VbEJjbGh1UzNTMit2Mlc3T3htQzZqN3VHTlQzbWZWdWJOWVp3Y0hLUzJr?= =?utf-8?B?NDZTZURhTnhIam9RRzhJYzE2SkUrdGxVcTZYRzlpLzA2cEQyZzlhNWQ0cW9s?= =?utf-8?B?dC80eHc0b1NuV05WMmlldmtuMWJSZmlGNHZ3Y1h4N2NLNFBjTG50QWZyNTh6?= =?utf-8?B?WmJ2Q1RjL3lXT0lhQk9aOUh2OEx0cEQwbUJveTlaclNXWG1vdVg1ZWh2MzJi?= =?utf-8?B?UU9lTnBiNU9MaERvZ2s0dCtsaVRHNFFKVFU2S0p5d1RxNVJacnBodEI2Zjk4?= =?utf-8?B?dElhYXhqcE5lcitZaG81Y1NxYlY0azRJMW9XTytzZjFsQ21QUVBlMFJEZEhn?= =?utf-8?B?V2wxL3EydWxmVWhoZ0w3OGFzZWoxNStPVnE2ZTF5SWg2V3dRdDdjR0RjSnZS?= =?utf-8?B?ek16OU5yK1FhNVhUcFhSVU95NnI2aHZQdllLMDdCN0ZzektpZU5NVExUZ01m?= =?utf-8?B?UnJzSDlWbWpLV3V0a1VnZ0s3d3A5dDVKRnFsWFBhUmFkanhpbFRqaXhVdDJm?= =?utf-8?B?eVhHbzZUclpkUUJHN3FWWTVvckVDRGpCM1hiNHdqaWdxWUVNRFBWWFJ0eU1N?= =?utf-8?B?UENaMUc2TVZsK2hKQVJGK0RKVzJTS3VRM25FbWNvZTNwZEQ2WmJkWGF4b0p1?= =?utf-8?B?Y0FzLytXTlpFK2JDOTg5TG9aaXJuY0xzN0RJQjAzdmZpTmN3RkdWQnZaWUts?= =?utf-8?B?UTlhR25sTWJKOHQ0c2lpaTg5QUEyZGtWZEU1dDZPTDUxemlUVSt4anB4cWVp?= =?utf-8?B?ZWc5MkMvNWlwK2MrcUJzejhVMFlaRyswbkdTRTFqMXA0M1MvNUhDOEpPTlZM?= =?utf-8?B?Qnl3c0x5Tlh4Q2tFdnNvUGdoeXdPTUFhQWVRaTJ5Y3ZKY3NldjU3aWh3M2RJ?= =?utf-8?B?TmpNZURsMWQ3K3M1TnZ3L0dsYjUrV2FGVHhjVmJ1b1VHNHdaa1ZzVzQrQWgx?= =?utf-8?B?NnVkVVk1TlFselNMZlZDOWxDLzc4NUpUOGsyUDFtTlEwMGFSUDhZV0VTNzlu?= =?utf-8?B?YjB6R1FweFdBSjBiR29XMTBuSzFKY2ZzWWU5YzVzaTE4NWVOSWR6eHF4bUdI?= =?utf-8?B?YVQrWVI1NDRpWmtnNzBWa2JPdDBLb3ZpQmhQbHdRdG5xdDhtMGxIN1dhdVpR?= =?utf-8?B?N21MZEc1K2pyKy80K0ZzK2UzNWJNL25sWDVJMG5tclcxSzF6dWxTMkpYOEFG?= =?utf-8?B?aTdPaHI0OEZDWGtqZ3c4UUptdUpLMEtCWktBbFRxakVrUEx3czFBVWVNd1Jo?= =?utf-8?B?WUhVNU5XUXFjeDJhS3N6S2tvSTdGTjZnSm1lVlhtUGxDbFc2WGJOa213TENs?= =?utf-8?B?TjJtdHBIUEE4aWtPTFRUM2RFNjJwU25ueW1za2RIVVVuR0hXWFJBMUk1REVV?= =?utf-8?B?WDJVK3c2ZDN1aEtncU55cCtNZ0RHa0s4TCtBV1krSm1VL29MQ2tXV1JyenM2?= =?utf-8?B?RmJ5RnI4TXFGZFhpTE94Z3U0L2VjSmhIZkZod3BhanhlMDJ4UUYzZ1lVdkdQ?= =?utf-8?B?U3NwZ2J6TTI0amRZY084a2RwSUEySUdSWittYm8wamM5cGF1dUFUUzlOdGhy?= =?utf-8?B?d0RUZGFvS2FWKzFHTHh0TnNDeGVqV2x4R1BBMWdseW9vSW45V1NPVDRoZ0Rw?= =?utf-8?Q?soNpwWzexPJMpaqioBef9Tc8FvPiKAQR?=
x-microsoft-antispam-prvs: <BN6PR11MB1651697B3CF21C0E48E0BA62D6710@BN6PR11MB1651.namprd11.prod.outlook.com>
x-forefront-prvs: 09669DB681
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(136003)(396003)(366004)(51444003)(199004)(189003)(54094003)(51914003)(8676002)(81156014)(81166006)(25786009)(68736007)(4326008)(97736004)(14444005)(256004)(82746002)(54896002)(6512007)(6486002)(53936002)(316002)(93886005)(71190400001)(83716004)(71200400001)(6306002)(6246003)(6436002)(54906003)(58126008)(110136005)(30864003)(6506007)(76176011)(99286004)(229853002)(105586002)(106356001)(53546011)(478600001)(46003)(2906002)(5660300002)(102836004)(86362001)(9326002)(8936002)(476003)(2616005)(446003)(33656002)(486006)(11346002)(6116002)(36756003)(186003)(7736002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1651; H:BN6PR11MB1732.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mrtaeddIMJ9Fx0MXm+/cDViYfloamW0y6XvdfFKKEz8chu7wIai4FUAaQ0IV74BTh+vzTR2+YZmI+72IcWrMlDG1L1FTDSlRwjdYD1P+mp4gELX/FLJiYKgWZiyKZfyqBL+8Q2hgZxAf6Uj7yuL9S1057BGSusNC9vLIri8jIH7iuIHcEIyGTKdiavP4plHdh6K44EhRjPvrm35IaMOveKXtFB/uKgdwuGx89Ep7jMREj0pH03SYKw/KCiLAe3f+7r5L7jsbAwYhwPz9oooiI0XlsNt8ZTsUoDFFJNO0mJdy5N+0fC5hwChGLh/pwHHqGrNDMTmzb70qa3ENRsTSKzm64YFVAOaGKJONW9o4aXNQgzpG8qe1hHHMjDZfQJX0OnhW8C3e3wMW+8MaH0bAIP39uorQZTNacrISL7E6C/A=
Content-Type: multipart/alternative; boundary="_000_840D870A36F94B32918B8F4A3D04EBDFciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 59db95e3-2dea-4f63-967f-08d6a0c9c5b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2019 17:49:38.3110 (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-Transport-CrossTenantHeadersStamped: BN6PR11MB1651
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/6eV_YoivrfDz2lOJ-LLJ6FmOto4>
Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2019 17:49:48 -0000

Hi Ben,

    Thanks for the careful review and comments, please see answers below:



    On 1/22/19, 19:14, "Ben Campbell" <ben@nostrum.com> wrote:





        ----------------------------------------------------------------------

        DISCUSS:

        ----------------------------------------------------------------------



        Hi, thanks for the readable approach to this. I like the plain English approach

        to the security considerations, in particular. But I do have some comments,

        including a couple that I think needs to be resolved before progressing the

        draft:



        1) I was surprised not to see a discussion of the "never-meet" problem. That

        is, what happens if a provider and a consumer never connect with the controller

        at the same time. Is the controller expected to store-and-forward items

        submitted to a topic prior to when the consumer connects? IIRC (and I apologize

        that I did not have time to refresh my memory on the referenced XEPs), that

        sort of behavior is optional under XEP-0060. Is it required for this use case?

        Is support for delayed delivery (xep-0203) or something similar required? Or

        perhaps platforms are expected to keep long-lived connections?

    [NCW] I think this is an implementation detail, but we've added a sentence in section 4

    To describe that it is an option per XEP-0060.



        2) The security considerations suggest that the use of TLS mitigates  all of

        the "network attacks". However, the potential or eavesdropping or data

        modification are only mentioned in terms of such "network attacks". It is also

        possible for the controller (aka XMPP server) to do those things unless some

        sort of e2e protection is used. This is not discussed in the sections about how

        the controller is trusted, nor is it discussed in the countermeasures sections.

        There is a mention of e2e protection in the privacy considerations, but I think

        that really needs treatment under the security considerations.

    [NCW] Section 8.2.3 does try to delineate the controller attacks, but we can add the

    Notion of eavesdropping and modification attacks there as well.  As to the considerations,

    We can add in 8.3.3 a sentence to the effect of using e2e protection to address this attack.







        ----------------------------------------------------------------------

        COMMENT:

        ----------------------------------------------------------------------





        *** Substantive Comments ***



        General: I expected to find a discussion of the "never



        Figure 1: I fail to understand the meaning intended by extending "data plane"

        to the right under the peer-to-peer data flow.

        [NCW] The intent is to distinctly outline the different ways in which data may be transferred.

    There were some use cases in which the data bypasses the controller and goes directly from provider to consumer.



        §3: It would be nice to somehow include authentication and authorization in

        Figure 1.

    [NCW] We have revised this figure many times and at some point had the flow for authentication/authorization

    But given the text figure nature, it made it almost unreadable.  If you feel this really must be addressed, then we would

    Have to bring back a previous figure that described that process (previous commenters had us remove it ergo its absence).



        §4: Figure 2 shows the consumer delaying the topic list request until after the

        provider has created the topic. I realize that's just for illustrative

        purposes, but I wonder what would have happened if the consumer requested the

        topic list sooner? Would it ever learn about the new topic?  Do you have

        thoughts about how often new topics will be created in the field?

    [NCW] If the consumer requests a Topic that is not recognized by the controller, then the controller would return an error.

    The flow shows the consumer effectively doing a "discovery" of available topics thru the "Request Topic List" (XEP-0030)

    As that is also the means to discover new topics....

    I can't speak in general, but in our implementation of the XMPP Controller, we find that while new topics are created dynamically, their frequency is not that high in fact, it is very infrequent.



        §5: "a Platform would send an XMPP "disco#info" request to each Topic:"

        Have people thought about how this might work if there are a _lot_ of topics?

    [NCW] That is a good question, in general, consumers that we run across have a small limited number of topics of interest (especially in the threat/security sharing domain).



        §8.1.3: Is the controller trusted to see data and to be able to modify that

        data? Or more to the point: It _can_ do those things. Is it trusted to not

        improperly use, store, or share data, and to not improperly modify data? (See

        further comments below)

    [NCW] In general, it is trusted to NOT touch the data; in the implementations we see, it is possible that the controller can eavesdrop but I do not know of any  XMPP Controller implementation that eavesdrop today.



        §8.3.2:

        - Can you elaborate on the concept of honey tokens?

    [NCW] The intent was to provide a means by which the controller, acting as the broker could effectively generate "fake" entries or messages to detect rogue providers or consumers.  However, the efficacy of such a countermeasure I think is minimal so we will remove that sentence.



        - The requirement that the grid controllers SHOULD keep auditable logs of

        platform behavior has privacy implications that need to be discussed in the

        privacy considerations. In particular, could there be some guidance around not

        logging more information than is needed for the purpose?

    [NCW] That is a fair point.  Will add a paragraph to that effect.



        §8.3.3: "permanent read-only audit logs of security-relevant

        information (especially administrative actions) should be maintained."

        Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

    [NCW] Yes, thank you for catching that.



        §8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a

        malicious provider insert so much data into a topic to make it impossible to

        receive data from that topic due to these size limits?  (That brings up a

        question: Can multiple providers insert data to the same topic?)

    [NCW] Given that it is guidance, am not sure how this presents a DoS?  The

    Search or subscription in XMPP does provide filtering capabilities to allow access

    Data subsets.

    A Topic is an abstract managed by the Controller, the controller doesn't store all of the data, the data is managed by the providers; but yes, multiple providers can publish data of the same topic.



        §8.3.6: Can you cite something or otherwise elaborate on certificate pinning?

    [NCW] The intent was to use the certificate pinning as the means for the xmpp platform to have the authorized controller(s) it should connect with....we've added a sentence to that effect.



        *** Editorial Comments:



        §2: In most of the definitions, you treat the XMPP-specific terminology inside

        the definition of the abstract term. Was there a reason to treat "Node"

        differently?

   [NCW] We called out "Node" differently as the XML examples we provided in the document reference Topic as Node.



        §3: "be a Provider or

        Consumer of interested Topics at the Broker"

        I'm not sure topics are capable of being interested. Perhaps "topics of

        interest"?

[NCW] Thanks for catching that. Will fix it in the next revision of the document.



        §4:

        - list item "e":  What does "in real time" mean in the context of a provider

        submitting data to the grid?

[NCW] There are several message exchange patterns such as real-time notifications,

request-response etc between a consumer and a provider. We meant to say that the
providers sends a real-time notification to a broker on a topic.



        - "XMPP-Grid implementations MUST adhere to the mandatory-to-implement

        and mandatory-to-negotiate features as defined in [RFC6120]."

        It's not generally necessary to say that an implementation MUST implement the

        mandatory bits of a spec. That's up to that spec to do itself.

[NCW] XMPP-Grid builds on RFC6120 and therefore it is a MUST for implementations to adhere to RFC6120.



        - "The Service Discovery per [XEP-0030] SHOULD be implemented"

        There appears to be a missing word after "Discovery". Or perhaps the use of

        "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service

        Discovery")

[NCW] Thanks for pointing this out. We changed the statement to -

Implementations SHOULD implement Service Discovery  as defined in XEP-0030 to facilitate

the means to dynamically discover the available information and namespaces (Topics) to be published or consumed.



        §8.1.4: It's a bit confusing to find CA security considerations before any

        mention that there are CAs involved.

[NCW] Our intent was to have the first paragraph in 8.1.4 describe the role of the CA in XMPP-Grid with the following. Perhaps we can clarify the first sentence to state:  “To allow XMPP=Grid Platforms to mutually authenticate with XMPP-Grid Controllers, it is expected that a CA is employed to issue certificates.”



        §8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data

        deserves to be ignored." "deserves" has connotations that I don't think apply

        here. I suspect you probably mean "... should be ignored", but were trying to

        avoid the non-normative use of "should". Such use is fine given the draft uses

       the RFC 8174 boilerplate for normative keywords.

[NCW] Thanks for pointing this out. Will fix it in the next revision of the document.



        §8.3.X: There are a number of statements that systems need to be "well

        managed", "hardened against attack", and "reduce their attack surface".  Some

        of them use normative language. These seem like glittering generalities, unless

        specific practices can be recommended or cited.

[NCW] Your comment is appreciated, the intent was to state recommended practices and did where we indicate examples, impose some normative language is needed.  Is there a suggestion you could make to improve on this?



        §8.3.1:  "(with the SCRAM-SHA-256-PLUS variant being preferred over the

        SCRAM-SHA-256 variant and SHA-256 variants [RFC7677] being preferred over SHA-1

        varients [RFC5802]" Should that be stated normatively?

[NCW] Thanks for pointing this out. Per your suggestion, we changed the text from “being preferred” to “SHOULD be preferred”



        §8.3.3: "Administrators SHOULD NOT use password-based

        authentication but should..."

        Should the second "should" be a "SHOULD"?

[NCW] Thanks for pointing this out. We changed it to SHOULD.