From nobody Mon Apr 2 11:52:25 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23A126DFF for ; Mon, 2 Apr 2018 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 wJ-zRpwmxkdX for ; Mon, 2 Apr 2018 11:52:22 -0700 (PDT) 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 E99E91241F8 for ; Mon, 2 Apr 2018 11:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1716; q=dns/txt; s=iport; t=1522695141; x=1523904741; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WbZ3d2X+EDzuBa6Fa3yIMxcXKyrh9AKW+dCtZskuD8w=; b=XowMuIUJTwH8Cs9Xn2yrSSdVuwUEYYfMduwZRM4Lp4BxOe2vOzdz3Px+ 7tpL6WSU6EFnIIgUw2goBa9OHuRYLf8jE2p8Qj0X9bMo5x2otKPc6Upjo SQ1Gbb+3I/+DFFe0Gh8VQlIf0Ae0t4AGpP+PAvbV9TE+7lb+O0O6KNZ7w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAAAXe8Ja/5FdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNCYW8oi1yNAoFLKYEPklMUgWYLGAuEFUwChDIhNBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUkAQEBAQIBAQEwATsGFQsSBi4nIg4GAQwGAgEBF4RqCA+vd4h?= =?us-ascii?q?AgiAFh2GBVD+BLoJigxEBAQOBIRWFdwKXOgiFUYhXBoEwg1mCNyKEVYkVhmi?= =?us-ascii?q?BJRw4gVJNIxU6gkOQaSMwjgkBAQ?= X-IronPort-AV: E=Sophos;i="5.48,396,1517875200"; d="scan'208";a="376809071" 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; 02 Apr 2018 18:52:21 +0000 Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w32IqKOk027688; Mon, 2 Apr 2018 18:52:21 GMT To: Haoyu song , opsawg References: <78A2745BE9B57D4F9D27F86655EB87F937499CAA@SJCEML521-MBB.china.huawei.com> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwk4EGBEC AAYFAjyDmkAAEgkQb2iPiv4Uz4cHZUdQRwABASe5AJ9fXM2tqFFNbP8dGkXuazypmrN04gCf W667omy3jekPNqcEdQ4HNQ/rKYA= Organization: Cisco Message-ID: Date: Mon, 2 Apr 2018 14:52:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F937499CAA@SJCEML521-MBB.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] network telemetry framework X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 18:52:24 -0000 On 3/21/18 04:01, Haoyu song wrote: > Dear all, > > > > The WG presentation triggered a lot warm discussions on this topic. > > While we agree that at present its too aggressive to try to unify the > telemetry protocols, we feel it is needed to formalize the terminologies > and clarify the technique classifications from multiple dimensions so to > ensure we have a common language in addressing such issues for the > upcoming network architectures such intent driven network. Thanks for continuing to work on this document, Haoyu. The idea of a "common taxonomy" is a good one. However, the current draft mentions a desire to "[integrate] multiple telemetry approaches" into a framework. I think the comments stated in London were of the vein that given the amount of work involved (and the use cases and solutions that have been put forward thus far), this is a monumental undertaking. As a contributor, perhaps there is something unique to the IBN/IDN architecture(s) that need a well-defined, common framework to how telemetry is approached. That would at least refine scope a bit more. > > > > The latest version can be found at: > > https://tools.ietf.org/html/draft-song-ntf-01 > > The document is still at its early stage. Please continue to provide > your comments and suggestions to scope it and contribute to it. The -01 modifications do help with readability, and I do encourage others to read and comment. Joe > > Thank you very much! > > > > Best regards, > > Haoyu > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Apr 2 14:32:13 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4DE12D95F for ; Mon, 2 Apr 2018 14:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7AsVY9Tjb9Ng for ; Mon, 2 Apr 2018 14:32:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 BE6EB12D95C for ; Mon, 2 Apr 2018 14:32:10 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 21408A7981851 for ; Mon, 2 Apr 2018 22:32:07 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 2 Apr 2018 22:32:08 +0100 Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Mon, 2 Apr 2018 14:32:01 -0700 From: Haoyu song To: Joe Clarke , opsawg Thread-Topic: [OPSAWG] network telemetry framework Thread-Index: AdPA6rVtrOwiIqT5RQ2Lk3zKreHADgKA7FkAAA1M2NA= Date: Mon, 2 Apr 2018 21:32:00 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F93749E731@SJCEML521-MBB.china.huawei.com> References: <78A2745BE9B57D4F9D27F86655EB87F937499CAA@SJCEML521-MBB.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] network telemetry framework X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 21:32:12 -0000 Hi Joe, Thanks for the comment! Yes it's clear our first step would be to set up the common taxonomy in thi= s area and help people to understand the status quo as well as the technica= l gaps.=20 We do believe there are something unique to IBN/IDN in terms of the network= telemetry. We have heard people expressed the desire to=20 1) normalize the data collection means 2) be able to interactively refine the data collection 3) be able to collect customized data on the on-demand basis 4) be able to directly collect data from the data plane forwarding path Some existing work shows the potentials to meet some of the requirements, b= ut I feel we are still far from that. So I think this document at least can partially serve the purpose to clear = the path. =20 We welcome collaborations on this topic because we believe this work needs = the contributions from the entire community. Best, Haoyu=20 -----Original Message----- From: Joe Clarke [mailto:jclarke@cisco.com]=20 Sent: Monday, April 02, 2018 11:52 AM To: Haoyu song ; opsawg Subject: Re: [OPSAWG] network telemetry framework On 3/21/18 04:01, Haoyu song wrote: > Dear all, >=20 > =A0 >=20 > The WG presentation triggered a lot warm discussions on this topic. >=20 > While we agree that at present it's too aggressive to try to unify the=20 > telemetry protocols, we feel it is needed to formalize the=20 > terminologies and clarify the technique classifications from multiple=20 > dimensions so to ensure we have a common language in addressing such=20 > issues for the upcoming network architectures such intent driven network. Thanks for continuing to work on this document, Haoyu. The idea of a "comm= on taxonomy" is a good one. However, the current draft mentions a desire t= o "[integrate] multiple telemetry approaches" into a framework. I think the comments stated in London were of the vein that given the amoun= t of work involved (and the use cases and solutions that have been put forw= ard thus far), this is a monumental undertaking. As a contributor, perhaps there is something unique to the IBN/IDN architecture(s) that need a well-defined, common framework to how telemetry= is approached. That would at least refine scope a bit more. >=20 > =A0 >=20 > The latest version can be found at: >=20 > https://tools.ietf.org/html/draft-song-ntf-01 >=20 > The document is still at its early stage. Please continue to provide=20 > your comments and suggestions to scope it and contribute to it. The -01 modifications do help with readability, and I do encourage others t= o read and comment. Joe >=20 > Thank you very much! >=20 > =A0 >=20 > Best regards, >=20 > Haoyu >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From nobody Tue Apr 3 00:14:32 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D612E741; Tue, 3 Apr 2018 00:14:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152273966682.13958.15967692371929458972@ietfa.amsl.com> Date: Tue, 03 Apr 2018 00:14:26 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-19.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:14:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-19.txt Pages : 58 Date : 2018-04-03 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-19 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 3 00:17:46 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB4C12E741 for ; Tue, 3 Apr 2018 00:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.489 X-Spam-Level: X-Spam-Status: No, score=-13.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 SAGnCRf5TYLZ for ; Tue, 3 Apr 2018 00:17:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC1C12E049 for ; Tue, 3 Apr 2018 00:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3783; q=dns/txt; s=iport; t=1522739862; x=1523949462; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=zb33AWqtmFaegSQ42p5eSil3aBBaW7AxI6L60fXaZ78=; b=g6VpxhTwljFLp1foDQU6fwyPkzLce0Iws9YWbL0tj9eVm3FlEwvgjWmL IwhT1iaaz3ijgVPA/uxNaIPgvEZqz9t0DsYClz5gQitLAfqPlXj0E0xbs qJJw5OZL1auDXy60qJFoUFBYJ7UJCaCdNbX6w2Af3Tout+GEKXol5J6UA w=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAQCaKcNa/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQjLEMZD4NfiABejXApgQ+SVYF6CAMYC4QVSwImhDI0GAE?= =?us-ascii?q?CAQEBAQEBAmsoQhABhEcJAQEBAwEBIUsGBRALEgYqAgInIg4TBgIBAViEMQ+?= =?us-ascii?q?tWoIciEGCFg+JdIEMIoJigxEBAQIBARaEQhOCQQKHM5AHCIM0gVBOiFcGgTA?= =?us-ascii?q?6gx+CN4R3iRWGaIElHDiBUjMaCBsVGSGBHQiBHgmQRj0whkyIDQE?= X-IronPort-AV: E=Sophos; i="5.48,398,1517875200"; d="asc'?scan'208"; a="2920091" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 07:17:40 +0000 Received: from [10.61.74.181] (ams3-vpn-dhcp2741.cisco.com [10.61.74.181]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w337HdrR027529 for ; Tue, 3 Apr 2018 07:17:39 GMT Cc: opsawg@ietf.org References: <152273966682.13958.15967692371929458972@ietfa.amsl.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: <542b8f05-56b7-5b1b-8e60-d2b6e0c03a04@cisco.com> Date: Tue, 3 Apr 2018 09:17:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152273966682.13958.15967692371929458972@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3NK9VG0s5720ScsIHUbSOZKJRIatuyJcN" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-19.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:17:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3NK9VG0s5720ScsIHUbSOZKJRIatuyJcN Content-Type: multipart/mixed; boundary="fl53BtFqITsQ2CRbL30mRi2s1Nv3Uj9sV"; protected-headers="v1" From: Eliot Lear Cc: opsawg@ietf.org Message-ID: <542b8f05-56b7-5b1b-8e60-d2b6e0c03a04@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-19.txt References: <152273966682.13958.15967692371929458972@ietfa.amsl.com> In-Reply-To: <152273966682.13958.15967692371929458972@ietfa.amsl.com> --fl53BtFqITsQ2CRbL30mRi2s1Nv3Uj9sV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US All, This (hopefully last) addresses concerns raised by the apps area.=C2=A0 I= t takes their recommendation to create a reserved space within the MUD-URL field for the DHCP and LLDP options.=C2=A0 The other choice was to have a= lengthy discussion about BCP-190 during IESG review, and that seemed counterproductive at this stage. Regards, Eliot On 03.04.18 09:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Operations and Management Area Working= Group WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-19.txt > Pages : 58 > Date : 2018-04-03 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL, an X.509 certificate extension and a means to sign > and verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-19 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-19 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --fl53BtFqITsQ2CRbL30mRi2s1Nv3Uj9sV-- --3NK9VG0s5720ScsIHUbSOZKJRIatuyJcN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrDKpMACgkQh7ZrRtnS ejNxEgf+MRRbLuaBx4uZY07kAx3M6/sdYxc6PEVIqacamm9b3Del/oOGyz3YdsBc UDXAZmZUe/+DHcq4MixhSEG79Q6gXaWlHzi+RS2pAI1zINQUcArZGFkTyYxf/36U 7afh+gcILAyVkH/UAcagfF1bKQIGAd5SESFu/3+JkrH43MPyP7qbCFzt58IycxW5 7wVExb2aGpcWC6RbAxvUOYBlcyjjiQugyqgh3pLh3py4n0T3oD9iUt6PDAkXJCpb /ivgDpfldydT3rEb0nLIuTAEFo//B8ydNKFyjOwhp5mfpKbzyVOxqZbr04kGalz0 W268NEWa9onIyMuqZCzOO594YfA8xg== =cigT -----END PGP SIGNATURE----- --3NK9VG0s5720ScsIHUbSOZKJRIatuyJcN-- From nobody Tue Apr 3 06:12:00 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B17127698 for ; Tue, 3 Apr 2018 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 vd7sfEuCvXYz for ; Tue, 3 Apr 2018 06:11:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85421205D3 for ; Tue, 3 Apr 2018 06:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6802; q=dns/txt; s=iport; t=1522761112; x=1523970712; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=XbC+VdFSV186efMF24Fnrfn3QNRZILLh8hn84oOwlv4=; b=EaIEfCa1It5NS9D4qcIrBLhyFFZWdGaBEEuqvYTRFsbHIbUNYbhHnm1O EGaUOMCswgNvJCyoQI6DA2Nz9WF0U3GMUMENuNnnueMxUK6eST0hogBFG yPW57EeytmuuD/9bjJoE9HlvTQAP3qECbRBXK7ZbgMQJJRR6U2gSbSemG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQBbfMNa/4cNJK1dGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNCYW+EB4gAjQSBSwiBMJJVgXoLI4kiITQYAQIBAQEBAQECax0?= =?us-ascii?q?LhUxLOAgCJgJLFA0IAQEQB4RyD61YghyIQ4IgBYEJhliBVD+BDCIMgVqCPYF?= =?us-ascii?q?QAgMBhFiCVAKHGQmBS4MFgR2DNoZ2CIVSiFcGgTCDWYI3IoRVhyaBb4ZogSU?= =?us-ascii?q?cOIFSTSMVOoJEgiuOPSOMKiuCGAEB?= X-IronPort-AV: E=Sophos;i="5.48,401,1517875200"; d="scan'208";a="365464285" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 13:11:51 +0000 Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w33DBpAq017767 for ; Tue, 3 Apr 2018 13:11:51 GMT To: "opsawg@ietf.org" From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwk4EGBEC AAYFAjyDmkAAEgkQb2iPiv4Uz4cHZUdQRwABASe5AJ9fXM2tqFFNbP8dGkXuazypmrN04gCf W667omy3jekPNqcEdQ4HNQ/rKYA= Organization: Cisco Message-ID: Date: Tue, 3 Apr 2018 09:11:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] [IETF101]: Ops Area and OPSAWG Minutes X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 13:12:00 -0000 Below are the minutes captured from the combined Ops Area and OPSAWG meeting at IETF101. These have also been posted to https://datatracker.ietf.org/doc/minutes-101-opsawg/ . Please let the chairs know of any corrections. Thanks. What: Combined OpsAWG / OpsArea When: 13:30-15:30 Monday Afternoon session I Where: Blenheim Ops-Area Section --------------------- Administrivia - scribes, minutes, etc. Benoit / Warren / Ignas 10 minutes AD transition Warren: Much thanks to Benoit, and a bottle! Benoit - Many YANG Modules 3214 in the catalog as of this morning. What needs to be improved: - how do we update the modules efficiently ? + need major and minor version control. + great to have RFC number, but need lighter update process + need EXAMPLES, and auto-updates for them. + IANA validation of the latest version? Eliot Lear - thanks for being the *level head in the room* Issue with Coordinator: Problem with YANG isthat there is code associated. Need to commitment to make updates from new model champions, to achieve Operational Excellence! Ignas - Develop the models that address the actual OPS need. need to focus on the requirements FROM USERs (for models, etc.) need to evolve our work to the useablility phase. Joe Clarke: How do we move faster, more like the OS model? The goal is: Be better about producing OPS need at the required velocity! Open Mic No questions! Ops-Area Working Group Section ------------------------------ Administrivia - scribes, note well, etc. Ignas / Tianran / Joe Ignas is transitioning to become Ops Area AD after Benoit. Joe has become a third co-chair in opsawg and after Ignas becomes AD, opsawg will continue to have two co-chairs for the time being Tianran provided an update of drafts: + draft-ietf-opsawg-capwap-alt-tunnel-12 - In RFC Editor Queue + draft-ietf-opsawg-ipfix-bgp-community-05 - First Last Call - Could benefit from more operator review + draft-ietf-opsawg-nat-yang-13 and draft-ietf-opsawg-mud-18 - Sent to IESG and pending telechat scheduling + draft-ietf-opsawg-tacacs-08 - In progress (see below) Alan De Kok came to the mic to discuss draft-ietf-opsawg-tacacs-08 + Authors are not engaging with the working group + Periodically, a revision that addresses some comments is submitted with no follow-up discussion + Authors have used verbatim Security Considerations text without attribution Joe agreed with Alan on the engagement and took the AI to follow up with the authors + Since then, revision -09 has been posted addressing some of Joe's contributor reviews + Authors committing to a new revision with follow-up to address Alan's remaining issues Eliot Lear presented a MUD update + Current document awaiting April 19, 2018 telechat + Some minor changes will be required prior to ratification + Next round of work will include how to describe bandwidth usage + While not strictly IETF-focused, 802.11 on-boarding is a prescient issue for IoT devices + URL composition and domain name lifetimes also need some thought Zhenqiang Li presented draft-ietf-opsawg-ipfix-bgp-community + All comments and suggestions incorporated in the draft + BGP community information can now be exported with specific flows + He asked if it's ready for the next step - Benoit commented that this draft should not say it "Updates" RFC7012 - Four people have read revision -05 - New version will be published that removes the "Updates" text Haoyu Song presented draft-song-ntf : Toward a network telemetry framework + Visibility is necessary for control + More visibility is required + Existing OAM framework is insufficient for Intent-Based Networks + Lots of piecemeal solutions exist + Lack of collaboration + Data quantity will be large and must be processed in real-time + Data comes from many different sources + The network needs to pre-process the data + But measurement functions must not interfere with the main function of the devices + Telemetry should partitioned into different "planes" + There should be a unified solution space + Ignas commented (as a contributor): - "I get the feeling you are trying to boil multiple oceans." - At the same time the majority of components already exist; areas already covered - This feels more like product design rather than protocol design - What is wrong with the current OAM? + Authors reiterated the need for a unifying framework + Joe commented (as co-chair) that more scoping is needed for this work - Perhaps focus should be specific to Intent-based networking - Currently, it feels too broad, especially given that it touches so much work already in progress or that has been ratified + Authors will look to refocus the text + More reviews are needed Chongfeng Xie presented draft-li-opsawg-address-pool-management-arch : Coordinated Address Space Management + CASM is a general architecture to handle the management of address pools + This document can form the basis for future work on modeling and design + Use cases include: - Address poll configuration - NAT & CGN - Address configuration of IPAM - SDN controller - Interfaces to the RPKI + Field trial of a CASM solution conducted between Huawei, ZTE, H3C, and Certus + Joe asked what has changed between the BOF held in IETF98 and now - There were comments that came out of the BOF that were merged into the text - Two drafts that were worked on prior to the BOF have been merged + Joe as a contributor - Looks like two fused drafts - There was confusing terminology - The text currently references expired drafts - Problem space is interesting - More refinement is required for the draft + Tianran polled the WG for interest - Six have read it - A few more show interest + More discussion is needed on the mailing list + Ignas had a conversation with enterprise operators - Lots of interest in this area - ONUG consists of a number of enterprise operators that have a need for this type of solution - Solution should be extended to handle containers, VLAN assignments, etc. Qin Wu draft-wu-opsawg-network-overlay-resource-model + Define a resource-facing model for resource management (network re-optimization, path selection, binding between the service and the path + Bridge between Service-centric models and network-centric models + This resource model can be mapped from the Customer-facing service model + Out of time in the meeting + Joe asked how many people have read this - 10 have read it - Seems to be lots of interest One last round of applause for Benoit! Joe (on behalf of the co-chairs) From nobody Wed Apr 4 04:40:58 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0E127241 for ; Wed, 4 Apr 2018 04:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 lhm_cFBOaF9d for ; Wed, 4 Apr 2018 04:40:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC394127286 for ; Wed, 4 Apr 2018 04:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3896; q=dns/txt; s=iport; t=1522842037; x=1524051637; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fwee03h/3cyhscbqbRgMjGPyYZQTrDPd2ngKFsJV/SU=; b=YF7V84Gnrq5zzN7CfyVNsBvm3noTOf5q/av6M5wroa8iokpRl+hxPSFT Qm+rBKP0NWlEeFB25h+73+m+Dkw7SK6LkuKfos78H+VGDeaUeihCTyMWW B9ycVTciS+2ylYGQxKcZrbeFagAOExg/aDx/RgthSZyZG0Ets6gAzNHCp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAACDuMRa/40NJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNCYW8oCoNViACNCIFTIYEPklWBegsYC4QVSwIahDEhNBg?= =?us-ascii?q?BAgEBAQEBAQJrHAELhSIBAQEBAwEBIRE6GwIBCBEDAQIDAiYCAgIlCxUICAI?= =?us-ascii?q?EE4UND6tvghyEV4NsgiWBCYZZghOBLgyCVoMRAQECAQEWgUIXgmkwgiQChyK?= =?us-ascii?q?JI4Z2CAKFUYhegTA6gx+HMIkVhkECERMBgSQBHDiBUnAVGSEqAYIYCQqKfYU?= =?us-ascii?q?+bwEBjE+BFwEB?= X-IronPort-AV: E=Sophos;i="5.48,405,1517875200"; d="scan'208";a="94314731" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 11:40:36 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w34BeajM023140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Apr 2018 11:40:36 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Apr 2018 06:40:35 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Wed, 4 Apr 2018 06:40:35 -0500 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 130, Issue 14 Thread-Index: AQHTwUbsfmnFbOeimE+yTJJHyvvu26Pw5MAA Date: Wed, 4 Apr 2018 11:40:35 +0000 Message-ID: <7BD5E35C-9191-445F-85BE-40B8DAC79134@cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.136.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] OPSAWG Digest, Vol 130, Issue 14 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 11:40:58 -0000 SGVsbG8gT1BTQVdHLA0KDQpSZWdhcmRpbmcgdGhlIFQrIGRvY3VtZW50OiBWZXJzaW9uIDkgKGJl bG93KSBoYWQgYSBzbWFsbCBudW1iZXIgb2YgbWFpbmx5IHR5cG9ncmFwaGljIGNvcnJlY3Rpb25z Lg0KDQpXZSBiZWxpZXZlIHRoYXQgdGhlIG1haW4gYXJlYSBvZiBkZWZpY2llbmN5IGluIHRoZSBk b2N1bWVudCBpcyBzZWN0aW9uIDkgKFNlY3VyaXR5KS4NCg0KT3VyIHBsYW4gaXMgdG8gcG9zdCB0 aGlzIHNwZWNpZmljIHNlY3Rpb24gdG8gdGhlIGxpc3QgZm9yIHJldmlldyBuZXh0IHdlZWsgKGFm dGVyIHNvbWUgaW5pdGlhbCBjbGVhbmluZyksIGFuZCBoZW5jZSB0byByZXNwb25kIG1vcmUgaW50 ZXJhY3RpdmVseSB0aGFuIHdlIGhhdmUgcHJldmlvdXNseS4gDQoNCkhvcGVmdWxseSB0aGlzIHdp bGwgcmVzdWx0IGluIGEgc2VjdXJpdHkgc2VjdGlvbiB0aGF0IGlzIGluIG1vcmUgcmVhc29uYWJs ZSBzaGFwZSBmb3IgdGhlIG5leHQgdXBsb2FkIG9mIHRoZSBkb2N1bWVudC4NCg0KTWFueSB0aGFu a3MuDQoNCiAgICBNZXNzYWdlOiAyDQogICAgRGF0ZTogV2VkLCAyMSBNYXIgMjAxOCAxMDo1NDow MSAtMDcwMA0KICAgIEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgIFRvOiA8aS1k LWFubm91bmNlQGlldGYub3JnPg0KICAgIENjOiBvcHNhd2dAaWV0Zi5vcmcNCiAgICBTdWJqZWN0 OiBbT1BTQVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9wc2F3Zy10YWNhY3MtMDkudHh0DQog ICAgTWVzc2FnZS1JRDogPDE1MjE2NTQ4NDE2OC43Mzk2LjYzMDI4MzkxMDA2MzU4OTgxOTJAaWV0 ZmEuYW1zbC5jb20+DQogICAgQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYt OCINCiAgICANCiAgICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIFdv cmtpbmcgR3JvdXAgV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBUaGUgVEFDQUNTKyBQcm90b2NvbA0KICAgICAgICAgICAgQXV0aG9ycyAgICAgICAg IDogVGhvcnN0ZW4gRGFobQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmVqIE90 YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRG91Z2xhcyBDLiBNZWR3YXkgR2FzaA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGF2aWQgQ2FycmVsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBMb2wgR3JhbnQNCiAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1vcHNhd2ctdGFjYWNzLTA5LnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiA0Mw0KICAg IAlEYXRlICAgICAgICAgICAgOiAyMDE4LTAzLTIxDQogICAgDQogICAgQWJzdHJhY3Q6DQogICAg ICAgVEFDQUNTKyBwcm92aWRlcyBEZXZpY2UgQWRtaW5pc3RyYXRpb24gZm9yIHJvdXRlcnMsIG5l dHdvcmsgYWNjZXNzDQogICAgICAgc2VydmVycyBhbmQgb3RoZXIgbmV0d29ya2VkIGNvbXB1dGlu ZyBkZXZpY2VzIHZpYSBvbmUgb3IgbW9yZQ0KICAgICAgIGNlbnRyYWxpemVkIHNlcnZlcnMuICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvdG9jb2wgdGhhdCBpcw0KICAgICAgIHVzZWQg YnkgVEFDQUNTKy4NCiAgICANCiAgICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy10YWNhY3MvDQogICAgDQogICAgVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy10YWNhY3MtMDkNCiAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy0wOQ0KICAgIA0K ICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNhd2ctdGFj YWNzLTA5DQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQog ICAgDQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg DQogICAgU3ViamVjdDogRGlnZXN0IEZvb3Rlcg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgT1BTQVdHIG1haWxpbmcgbGlzdA0K ICAgIE9QU0FXR0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb3BzYXdnDQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgDQogICAgRW5kIG9mIE9QU0FXRyBEaWdlc3QsIFZvbCAxMzAsIElzc3VlIDE0DQog ICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgDQoNCg== From nobody Wed Apr 4 08:32:01 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07F212DA24 for ; Wed, 4 Apr 2018 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 9K5yCKLWi1H4 for ; Wed, 4 Apr 2018 08:31:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C29312DA0A for ; Wed, 4 Apr 2018 08:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=692; q=dns/txt; s=iport; t=1522855918; x=1524065518; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=0LiP5rFFhC2ENq2IBKP90cz4Vd5dllRjNJIZjRkxGjo=; b=XKLlOfCuozQ/dDkeIbvZp1vOE2gIZ3LCCd4Xd2UfmVdnekQPhtWzE8j7 9B/ndPBNwLo5szl7qeyRRy9khmnaiFms3pckNxMHURHtMmHRaAwMxqXd3 S2oNpQmPN9P1joZdvNqbKJ28s5l9d1ziTDr8ZBpI7aqo49HlEhuo9wNz7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAgBb78Ra/5RdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNCgVCEB5UIgVOBMJRPC4R5hEwhOBQBAgEBAQEBAQJsHQu?= =?us-ascii?q?FTIELAiYCXw0IAQGFCat1ghyIQYIlgQmGWYFUP4EuDIQXgxqDFIJUApc+CI4?= =?us-ascii?q?rBoEkhh6Eeo99gSUzIYFSTSMVgn6CK44+I4tdgkQBAQ?= X-IronPort-AV: E=Sophos;i="5.48,406,1517875200"; d="scan'208";a="369664854" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 15:31:57 +0000 Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w34FVult020383 for ; Wed, 4 Apr 2018 15:31:57 GMT To: "opsawg@ietf.org" From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA Organization: Cisco Message-ID: Date: Wed, 4 Apr 2018 11:31:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] [IETF101] Minutes revision X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:32:00 -0000 Laurent Ciavaglia reminded me of a couple of other comments on draft-song-ntf that were raised during the presentation. To that end, a rev -03 of the minutes has been posted with these additional two comments from Tim and Laurent: + Tim Carey stated, intent could be realized in many different ways and each with many sources of data and from different protocols. How to correlate those sources of data back to intents would be highly valuable. + Laurent Ciavaglia commented some functions do not seem to be addressed in the document, and asked for clarification on the data transport/distribution, as well as data storage functions and their respective optimization. Joe From nobody Mon Apr 9 04:48:16 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9FF12DA22; Mon, 9 Apr 2018 04:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152327448178.14913.16076169790613659247@ietfa.amsl.com> Date: Mon, 09 Apr 2018 04:48:01 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-20.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 11:48:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-20.txt Pages : 58 Date : 2018-04-09 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-20 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 9 04:50:05 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AEB124B17 for ; Mon, 9 Apr 2018 04:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.49 X-Spam-Level: X-Spam-Status: No, score=-13.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 d0OdktquP3UM for ; Mon, 9 Apr 2018 04:50:02 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD5D1241F5 for ; Mon, 9 Apr 2018 04:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1523274601; x=1524484201; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rVbu+4u1t7ZHzPcobgYd6/ALQjGK9SBRUyMCpStGUao=; b=gEqK4u3UBl893Nda3Ca9bIvUg18OJo+3SC34mEsZZZ9TqKX5sV0l2Lng T4pMg09x25eR/CArRC16iENMeghJ3n9OXKTimY5Qli4u16Ss2qGMbWNic FwJvGLsgEgBsA+UbA1wiBi4zc+0VmfIQxHz9cSgppOeXaJg64w13t19WE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGBADxUsta/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQjbxkPg2CIAV6NdymBD5JdgXoLGAuEFUsCJoI0NBgBAgE?= =?us-ascii?q?BAQEBAQJsHAxCAQEBAgEGAgcBhEIJAQEBAwEBIUsLEAsSBgICJgICJyIOEwY?= =?us-ascii?q?CAQFYhDEPpGKCHIg9gh6BCYh1gS6CYoMRAQECAQEWhEITgkEChzeQEAiFVoh?= =?us-ascii?q?ZBoEyO4MggjeEf4kchmqBJRw4JoEsMxoIGxUZIYEdCIEeCYsHhUA9MIRtgUC?= =?us-ascii?q?DLIMFgmsB?= X-IronPort-AV: E=Sophos;i="5.48,427,1517875200"; d="scan'208";a="3088563" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 11:49:53 +0000 Received: from [10.61.240.208] ([10.61.240.208]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w39BnqLo001918 for ; Mon, 9 Apr 2018 11:49:53 GMT Cc: opsawg@ietf.org References: <152327448178.14913.16076169790613659247@ietfa.amsl.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: Date: Mon, 9 Apr 2018 13:49:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152327448178.14913.16076169790613659247@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-20.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 11:50:04 -0000 Hi, The only change in this draft is to an example, which is based on change to the ACL model that I hadn't caught earlier. Eliot On 09.04.18 13:48, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-20.txt > Pages : 58 > Date : 2018-04-09 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an > LLDP TLV, a URL, an X.509 certificate extension and a means to sign > and verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-20 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-20 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Apr 9 10:58:05 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EADF12D88E; Mon, 9 Apr 2018 10:57:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152329667548.30723.13155842895888603902@ietfa.amsl.com> Date: Mon, 09 Apr 2018 10:57:55 -0700 Archived-At: Subject: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 17:57:56 -0000 Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-opsawg-mud-20 Reviewer: Robert Sparks Review Date: 2018-04-09 IETF LC End Date: 2017-11-07 IESG Telechat date: 2018-04-19 Summary: Almost ready but with minor issues to address before publication as a standards track RFC Minor issues: Section 3.15 is confused, and I don't think you'll get the implementation you intend with the MUST in the current language. direction-indicated is not a flag. The text about dropping should talk about matching the direction that was indicated. The quoted issues below are from my early review of -08. I don't think they've been addressed or responded to. Apologies if I missed a response. > The document proposes "reputation services". It needs more words about > whether those exist, and what scopes the architecture imagines (an > enterprise might have a different idea of a reputation service than a > residence). There is a notion of "decent web reputations" in the security > considerations section. Who determines that? The security considerations > section should talk about attacks against the reputation services. > I think there needs to be more discussion of the PKI used for signing MUD > files. > Consider discussing whether the stacks used by typical things will let > them add DHCP options (or include bits in the other protocols being > enabled). If it's well known (I can't say) that these stacks typically > _won't_ provide that functionality, then you should punch up the > discussion of the controllers mapping other identifiers to MUD URLs on > behalf of the thing. > You suggest the DHCP Client (which is a thing) SHOULD log or report > improper acknowledgments from servers. That's asking a bit much from > a thing. I suspect the requirement is unrealistic and should be removed > or rewritten to acknowledge that things typically won't do that. > The security and deployment considerations sections talk about what the > need for coordination if control over the domain name used in the URL > changes. It should talk more about what happens if the new administration > of the domain is not interested in facilitating a transition (consider > the case of a young company with a few thousand start-up-ish things out > there that loses a suit over its name). Please discuss whether or not > suddenly losing the MUD assisted network configuration is expected to > leave the devices effectively cut-off. > Right now, you leave the DHCP server (when it's used) responsible for > clearing state in the MUD controller. Please discuss what happens when > those are distinct elements (as you have in the end of section 9.2) and > the DHCP server reboots. Perhaps it would make sense for the DHCP server > to hand the length of the lease it has granted to the MUD controller and > let the MUD controller clean up on its own? Nits: There is tension between the paragraph in the introduction that characterizes the manufacturer as the entity that provides the mud file and the third bullet in the intent list about speeding vulnerability resolution for devices that are no longer supported by the manufacturer (you intend here that someone other than the original manufacturer or integrator is providing a new mud file). Instead of "A light bulb is intended to light a room.", I suggest "A light bulb is intended to light a given space." (There are lightbulbs meant for outdoor use, and others for only inside cabinets or appliances.) Instead of "We make use of YANG because of the time and effort spent to develop accurate..." I suggest "We make use of YANG because it provides accurate..." At the end of section 1.7, instead of "For these reasons only a limited subset YANG-based configuration is permitted in a MUD file.", I suggest "For these reasons, the YANG-based configuration in a MUD file is limited to the YANG modules defined in this document." or something similar. In section 3.6, the parenthesized clause does not belong in the sentence in which it currently appears. I suggest it belongs somewhere in the previous sentence. In section 3.13 you talk about classes that are standardized. Where does someone find out about standardized classes? Micro-nits: "Our work begins with" in section 1.5 is awkward and I suspect will cause problems if this document is translated into other languages. At "======= The MUD URL identifies" in section 5, I suggest deleting the = signs. Please provide a reference or better description for "so-called east-west infection"" The string "enorcement" appears a couple of times in the models. It is intended to be "enforcement". From nobody Tue Apr 10 03:43:44 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCC126D73; Tue, 10 Apr 2018 03:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 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 dbtJWT_UMB3H; Tue, 10 Apr 2018 03:43:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF392120724; Tue, 10 Apr 2018 03:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24792; q=dns/txt; s=iport; t=1523357019; x=1524566619; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Uzofvlz439L6eIC5wyuQ+oaxwCj/HkeRjcEmz9wYq+4=; b=XZYKK+HpXPtAZmOtsv31boIJZqAcpZ/TJzhHu2csCoENlssWBjSTLa/S fKsf9vEwMyuFAn7SBxgsfpnA2TxLYKf3dFe8pUuIyzhGoNcQeOfNgJTbn DGbAsWGgZSlu1dVX2RAdXvSEfKyrKhhRr5Lr4ubKGKxUXjeuRXHC4fPnI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7BQBUlMxa/xbLJq0YAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgxOBEG+ECIgBXo17KYEPkl0UgWYLI4RgAoJjNBgBAgE?= =?us-ascii?q?BAQEBAQJsHAxCEAGETwEBAQECASNWEAsOBAIEKgICSQ4GAQwIAQGFAQgPigq?= =?us-ascii?q?cL4IcH4glghoFiX6BDCKBZnyDEQKBGB0PAjaCYIJUAocRKA+EM4RWhngIhVa?= =?us-ascii?q?GSYIQBgKBMINbgjeEf4kfhmyBJRw4gVIzGggbFTqCRIIaBReIWYVAPYcMhXg?= =?us-ascii?q?CJAeCGAEB?= X-IronPort-AV: E=Sophos;i="5.48,431,1517875200"; d="scan'208,217";a="3058274" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2018 10:43:36 +0000 Received: from [10.61.75.252] (ams3-vpn-dhcp3068.cisco.com [10.61.75.252]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3AAhZ13028575; Tue, 10 Apr 2018 10:43:36 GMT To: Robert Sparks , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: <10591659-b464-ad66-a499-6567202cc782@cisco.com> Date: Tue, 10 Apr 2018 12:43:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152329667548.30723.13155842895888603902@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------20F333BA504CEE9BD7336E9E" Content-Language: en-US Archived-At: Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 10:43:44 -0000 This is a multi-part message in MIME format. --------------20F333BA504CEE9BD7336E9E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert and thanks again for the review.  Please see below for responses.  These are my personal views.  The WG chairs / shepherds may have different opinions. On 09.04.18 19:57, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-opsawg-mud-20 > Reviewer: Robert Sparks > Review Date: 2018-04-09 > IETF LC End Date: 2017-11-07 > IESG Telechat date: 2018-04-19 > > Summary: Almost ready but with minor issues to address before publication as a > standards track RFC > > Minor issues: > > Section 3.15 is confused, and I don't think you'll get the implementation you > intend with the MUST in the current language. direction-indicated is not a > flag. The text about dropping should talk about matching the direction that was > indicated. Having reread this section (and perhaps I am a bit too close to the text), perhaps it is a bit confused.  How about something along the following lines: 3.15.  direction-initiated    When applied this matches the direction in which a TCP connection is    initiated.  When direction initiated is "from-device", packets that are    transmitted in the direction of a thing MUST be dropped unless the thing    has first initiated a TCP connection.  This node may be implemented in    its simplest form by looking at naked SYN bits, but may also be implemented    through more stateful mechanisms.     [RFC6092] specifies IPv6 guidance best    practices.  While that document is scoped specifically to IPv6, its    contents are applicable for IPv4 as well.  Better? > > The quoted issues below are from my early review of -08. I don't think they've > been addressed or responded to. Apologies if I missed a response. > >> The document proposes "reputation services". It needs more words about >> whether those exist, and what scopes the architecture imagines (an >> enterprise might have a different idea of a reputation service than a >> residence). There is a notion of "decent web reputations" in the security >> considerations section. Who determines that? The security considerations >> section should talk about attacks against the reputation services. >> I think there needs to be more discussion of the PKI used for signing MUD >> files. > While this section is admittedly a bit vague, we need some operational experience to develop the appropriate use of PKI as an anchor for reputations.  This having been said, if you have a specific proposal for text, I'd be interested in what you have to say. >> Consider discussing whether the stacks used by typical things will let >> them add DHCP options (or include bits in the other protocols being >> enabled). If it's well known (I can't say) that these stacks typically >> _won't_ provide that functionality, then you should punch up the >> discussion of the controllers mapping other identifiers to MUD URLs on >> behalf of the thing. We did indeed add some text about this, almost verbatim to what you have above (I think at your suggestion).  This can be found in the introduction toward the bottom of page 9. > >> You suggest the DHCP Client (which is a thing) SHOULD log or report >> improper acknowledgments from servers. That's asking a bit much from >> a thing. I suspect the requirement is unrealistic and should be removed >> or rewritten to acknowledge that things typically won't do that. I propose to delete that paragraph to match that we do not wish DHCP servers to modify their state.  This would address your concern (also see below). > >> The security and deployment considerations sections talk about what the >> need for coordination if control over the domain name used in the URL >> changes. It should talk more about what happens if the new administration >> of the domain is not interested in facilitating a transition (consider >> the case of a young company with a few thousand start-up-ish things out >> there that loses a suit over its name). Please discuss whether or not >> suddenly losing the MUD assisted network configuration is expected to >> leave the devices effectively cut-off. The example you are talking about is a subset of what happens if the file simply doesn't exist.  At worst, one is left in a situation no worse than we are today: that is, someone will have to manually decide policy, or apply a default policy.  This particular text is the subject of separate piece of work that Thorsten Dahm and Steve Rich are considering, and it is also the subject of some ongoing research.  That is to say: we might be able to do better in the future when we have some operational experience. > >> Right now, you leave the DHCP server (when it's used) responsible for >> clearing state in the MUD controller. Please discuss what happens when >> those are distinct elements (as you have in the end of section 9.2) and >> the DHCP server reboots. Perhaps it would make sense for the DHCP server >> to hand the length of the lease it has granted to the MUD controller and >> let the MUD controller clean up on its own? Ok, two issues: 1. There was some text that should have been removed, referring to the DHCP server returning the MUD-URL as part of state.  With everyone's permission, I propose to remove that text.  No additional DHCP server state should be required to implement this option. 2. I agree that we could be a bit more descriptive about what would happen if a reboot of the DHCP server.  I also like your idea about mentioning the lease time to the MUD controller.  With that in mind, how about the following text: With that in mind, I propose the following edit: DHCP servers may implement MUD functionality themselves or they may pass along appropriate information to a network management system or MUD controller.  A DHCP server that does process the MUD URL MUST adhere to the process specified in {{RFC2818}} and {{RFC5280}} to validate the TLS certificate of the web server hosting the MUD file.  Those servers will retrieve the file, process it, create and install the necessary configuration on the relevant network element.  Servers SHOULD monitor the gateway for state changes on a given interface.  A DHCP server that does not provide MUD functionality and has forwarded a MUD URL to a MUD controller MUST notify the MUD controller of any corresponding change to the DHCP state of the client (such as expiration or explicit release of a network address lease). Should the DHCP server fail, in the case when it implements the MUD controller functionality, any backup mechanisms SHOULD include the MUD state, and the server SHOULD resolve the status of clients upon its restart, similar to what it would do, absent MUD controller functionality.  In the case where the DHCP server forwards information to the MUD controller, the MUD controller will either make use of redundant DHCP servers for information, or otherwise clear state based on other network information, such as monitoring port status on a switch via SNMP, Radius accounting, or similar mechanisms. > > Nits: > > There is tension between the paragraph in the introduction that characterizes > the manufacturer as the entity that provides the mud file and the third bullet > in the intent list about speeding vulnerability resolution for devices that > are no longer supported by the manufacturer (you intend here that someone other > than the original manufacturer or integrator is providing a new mud file). Perhaps this is best fixed by dropping the phrase "by the manufacturer"? > > Instead of "A light bulb is intended to light a room.", I suggest > "A light bulb is intended to light a given space." (There are lightbulbs > meant for outdoor use, and others for only inside cabinets or appliances.) Ok. > > Instead of "We make use of YANG because of the time and effort spent to develop > accurate..." I suggest "We make use of YANG because it provides accurate..." Ok. > > At the end of section 1.7, instead of "For these reasons only a limited subset > YANG-based configuration is permitted in a MUD file.", I suggest "For these > reasons, the YANG-based configuration in a MUD file is limited to the YANG > modules defined in this document." or something similar. s/defined/specified/ but otherwise ok. > > In section 3.6, the parenthesized clause does not belong in the sentence in > which it currently appears. I suggest it belongs somewhere in the previous > sentence. I've removed it and rewritten as follows: The intent is for administrators to be able to see a brief displayable description of the Thing. > > In section 3.13 you talk about classes that are standardized. Where does > someone find out about standardized classes? They're described in the document > > Micro-nits: > > "Our work begins with" in section 1.5 is awkward and I suspect will cause > problems if this document is translated into other languages. If you *know* this to be a problem, I will make a change. > > At "======= The MUD URL identifies" in section 5, I suggest deleting the = > signs. I believe this is corrected. > > Please provide a reference or better description for "so-called east-west > infection"" I'll change this to "lateral infection (infection of devices that reside near one another)". > > The string "enorcement" appears a couple of times in the models. It is intended > to be "enforcement". > Thanks for catching these. --------------20F333BA504CEE9BD7336E9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Robert and thanks again for the review.  Please see below for responses.  These are my personal views.  The WG chairs / shepherds may have different opinions.


On 09.04.18 19:57, Robert Sparks wrote:
Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-20
Reviewer: Robert Sparks
Review Date: 2018-04-09
IETF LC End Date: 2017-11-07
IESG Telechat date: 2018-04-19

Summary: Almost ready but with minor issues to address before publication as a
standards track RFC 

Minor issues:

Section 3.15 is confused, and I don't think you'll get the implementation you
intend with the MUST in the current language. direction-indicated is not a
flag. The text about dropping should talk about matching the direction that was
indicated.

Having reread this section (and perhaps I am a bit too close to the text), perhaps it is a bit confused.  How about something along the following lines:

3.15.  direction-initiated

   When applied this matches the direction in which a TCP connection is
   initiated.  When direction initiated is "from-device", packets that are
   transmitted in the direction of a thing MUST be dropped unless the thing
   has first initiated a TCP connection.  This node may be implemented in
   its simplest form by looking at naked SYN bits, but may also be implemented
   through more stateful mechanisms.
 
  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well. 


Better?


The quoted issues below are from my early review of -08. I don't think they've
been addressed or responded to. Apologies if I missed a response.


The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.


      

        
I think there needs to be more discussion of the PKI used for signing MUD
files.


      

      
 

    

    

    While this section is admittedly a bit vague, we need some
    operational experience to develop the appropriate use of PKI as an
    anchor for reputations.  This having been said, if you have a
    specific proposal for text, I'd be interested in what you have to
    say.

    

    

      

      

        
Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being 
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

      

    

    

    We did indeed add some text about this, almost verbatim to what you
    have above (I think at your suggestion).  This can be found in the
    introduction toward the bottom of page 9.

    

    

      

        

      

      
 


      

        
You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.

      

    

    

    I propose to delete that paragraph to match that we do not wish DHCP
    servers to modify their state.  This would address your concern
    (also see below).

    

    

      

        

      

      
 


      

        
The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration
of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off. 

      

    

    

    The example you are talking about is a subset of what happens if the
    file simply doesn't exist.  At worst, one is left in a situation no
    worse than we are today: that is, someone will have to manually
    decide policy, or apply a default policy.  This particular text is
    the subject of separate piece of work that Thorsten Dahm and Steve
    Rich are considering, and it is also the subject of some ongoing
    research.  That is to say: we might be able to do better in the
    future when we have some operational experience.

    

    

    

      

        

      

      
 


      

        
Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

      

    

    

    Ok, two issues:

    
    
      
  1. There was some text that should have been removed, referring
        to the DHCP server returning the MUD-URL as part of state.  With
        everyone's permission, I propose to remove that text.  No
        additional DHCP server state should be required to implement
        this option.
    2. 
      
  2. I agree that we could be a bit more descriptive about what
        would happen if a reboot of the DHCP server.  I also like your
        idea about mentioning the lease time to the MUD controller. 
        With that in mind, how about the following text:
    3. 
    

    


    

    
With that in mind, I propose the following edit:

    
DHCP servers may implement MUD functionality themselves or they
      may

      pass along appropriate information to a network management system
      or

      MUD controller.  A DHCP server that does process the MUD URL MUST
      adhere

      to the process specified in {{RFC2818}} and {{RFC5280}} to
      validate

      the TLS certificate of the web server hosting the MUD file.  Those

      servers will retrieve the file, process it, create and install the

      necessary configuration on the relevant network element.  Servers

      SHOULD monitor the gateway for state changes on a given
      interface.  A

      DHCP server that does not provide MUD functionality and has
      forwarded

      a MUD URL to a MUD controller MUST notify the MUD controller

      of any corresponding change to the DHCP state of the client

      (such as expiration or explicit release of a network address
      lease).

      

      Should the DHCP server fail, in the case when it implements the
      MUD

      controller functionality, any backup mechanisms SHOULD include the
      MUD

      state, and the server SHOULD resolve the status of clients upon
      its

      restart, similar to what it would do, absent MUD controller

      functionality.  In the case where the DHCP server forwards
      information

      to the MUD controller, the MUD controller will either make use of

      redundant DHCP servers for information, or otherwise clear state
      based

      on other network information, such as monitoring port status on a

      switch via SNMP, Radius accounting, or similar mechanisms.

    

    

    

      

        

      

      
 
Nits:

There is tension between the paragraph in the introduction that characterizes
the manufacturer as the entity that provides the mud file and the third bullet
in the intent list about speeding vulnerability resolution for devices that
are no longer supported by the manufacturer (you intend here that someone other
than the original manufacturer or integrator is providing a new mud file).

    

    

    Perhaps this is best fixed by dropping the phrase "by the
    manufacturer"?

    

    

      

Instead of "A light bulb is intended to light a room.", I suggest 
"A light bulb is intended to light a given space." (There are lightbulbs
meant for outdoor use, and others for only inside cabinets or appliances.)

    

    

    Ok.

    

    

      

Instead of "We make use of YANG because of the time and effort spent to develop
accurate..." I suggest "We make use of YANG because it provides accurate..."

    

    

    Ok.

    

      

At the end of section 1.7, instead of "For these reasons only a limited subset
YANG-based configuration is permitted in a MUD file.", I suggest "For these
reasons, the YANG-based configuration in a MUD file is limited to the YANG
modules defined in this document." or something similar.

    

    s/defined/specified/ but otherwise ok.

    

    

      

In section 3.6, the parenthesized clause does not belong in the sentence in 
which it currently appears. I suggest it belongs somewhere in the previous
sentence.

    

    

    I've removed it and rewritten as follows:

    

    The intent is for administrators to be able to see a

    brief displayable description of the Thing. 

    

    

      

In section 3.13 you talk about classes that are standardized. Where does 
someone find out about standardized classes?

    

    

    They're described in the document

    

      

Micro-nits:

"Our work begins with" in section 1.5 is awkward and I suspect will cause
problems if this document is translated into other languages.

    

    

    If you *know* this to be a problem, I will make a change.

    

    

      

At "======= The MUD URL identifies" in section 5, I suggest deleting the =
signs.

    

    

    I believe this is corrected.

    

      

Please provide a reference or better description for "so-called east-west
infection""

    

    

    I'll change this to "lateral infection (infection of devices that
    reside near one another)".

    

      

The string "enorcement" appears a couple of times in the models. It is intended
to be "enforcement".



    

    Thanks for catching these.

    

  


--------------20F333BA504CEE9BD7336E9E--


From nobody Tue Apr 10 06:03:30 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C628B127601; Tue, 10 Apr 2018 06:03:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Scott Bradner 
To: 
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.77.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152336540077.13556.13954379711415125489@ietfa.amsl.com>
Date: Tue, 10 Apr 2018 06:03:20 -0700
Archived-At: 
Subject: [OPSAWG] Opsdir telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 13:03:21 -0000

Reviewer: Scott Bradner
Review result: Has Nits

I did an OPS-DIR review of Manufacturer Usage Description Specification <
draft-ietf-opsawg-mud > The specification is well written and clear (I also
agree with Robert Spark's nits).

One suggestion about document organization: I would either move the discussion
of what should be done if the MUD controller can not retrieve the MUD file for
some reason or another out of the security considerations section to after
section 1.9 or at least include a forward pointer to the discussion.



From nobody Tue Apr 10 07:12:02 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A25E1289B0; Tue, 10 Apr 2018 07:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 vit_cmBH4DQe; Tue, 10 Apr 2018 07:12:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F3A127871; Tue, 10 Apr 2018 07:11:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=741; q=dns/txt; s=iport; t=1523369519; x=1524579119; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=r7KFJa6bLckwWjCoj7s/LarqyxDoGGYZvjWcPnpUGno=; b=WmZtwy9xL8TI6ANIlraqwsFcSAPlFturavzoW/VmZWXFOClij2FMQvV1 Q6JXCz8MAcvfhGB6ea5EDYa7pm36VaYPnlNbFFaYtGY6fnQpBcirTsaXV OjkqCvyjUe7y3vGxRc2iNxVdubtdOZclqFsZLNQ3jMgXRjsGEU62fFjkZ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgB2xcxa/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUShAiIX41+KYEPlFgLhQMCgmc3FQECAQEBAQEBAmwohSM?= =?us-ascii?q?BBSMPAUYQCw4KAgImAgJXBgEMCAEBhQmmMYIciEWCH4EJiHWBLoJih2+CVAK?= =?us-ascii?q?HPJAUCI4wBoEzg1uCN4R/kA6BJTIigVIzGggbFYJ+gh8Xjhk9j00BAQ?=
X-IronPort-AV: E=Sophos;i="5.48,432,1517875200";  d="scan'208";a="3112052"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2018 14:11:55 +0000
Received: from [10.61.75.252] (ams3-vpn-dhcp3068.cisco.com [10.61.75.252]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3AEBsJU004309; Tue, 10 Apr 2018 14:11:55 GMT
To: Scott Bradner , ops-dir@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152336540077.13556.13954379711415125489@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: 
Date: Tue, 10 Apr 2018 16:11:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152336540077.13556.13954379711415125489@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Opsdir telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 14:12:01 -0000

Hi Scott,

Thanks for your review.  Please see below.


On 10.04.18 15:03, Scott Bradner wrote:
> Reviewer: Scott Bradner
> Review result: Has Nits
>
> I did an OPS-DIR review of Manufacturer Usage Description Specification <
> draft-ietf-opsawg-mud > The specification is well written and clear (I also
> agree with Robert Spark's nits).
>
> One suggestion about document organization: I would either move the discussion
> of what should be done if the MUD controller can not retrieve the MUD file for
> some reason or another out of the security considerations section to after
> section 1.9 or at least include a forward pointer to the discussion.
>

I think this is a good point.  Section 1.6 ok with you?

Eliot


From nobody Tue Apr 10 07:23:09 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2DE12D864; Tue, 10 Apr 2018 07:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 4behBuxIJPub; Tue, 10 Apr 2018 07:23:02 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEC91270AB; Tue, 10 Apr 2018 07:22:59 -0700 (PDT)
Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3AEMrSn026239 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Apr 2018 09:22:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local
To: Eliot Lear , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>
From: Robert Sparks 
Message-ID: 
Date: Tue, 10 Apr 2018 09:22:53 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <10591659-b464-ad66-a499-6567202cc782@cisco.com>
Content-Type: multipart/alternative; boundary="------------7777D376BC84DF41A658AA78"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 14:23:07 -0000

This is a multi-part message in MIME format.
--------------7777D376BC84DF41A658AA78
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 4/10/18 5:43 AM, Eliot Lear wrote:
>
> Hi Robert and thanks again for the review.  Please see below for 
> responses.  These are my personal views.  The WG chairs / shepherds 
> may have different opinions.
>
Thank you for the very quick response!
>
>
> On 09.04.18 19:57, Robert Sparks wrote:
>> Reviewer: Robert Sparks
>> Review result: Ready with Issues
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-opsawg-mud-20
>> Reviewer: Robert Sparks
>> Review Date: 2018-04-09
>> IETF LC End Date: 2017-11-07
>> IESG Telechat date: 2018-04-19
>>
>> Summary: Almost ready but with minor issues to address before publication as a
>> standards track RFC
>>
>> Minor issues:
>>
>> Section 3.15 is confused, and I don't think you'll get the implementation you
>> intend with the MUST in the current language. direction-indicated is not a
>> flag. The text about dropping should talk about matching the direction that was
>> indicated.
>
> Having reread this section (and perhaps I am a bit too close to the 
> text), perhaps it is a bit confused.  How about something along the 
> following lines:
>
> 3.15.  direction-initiated
>
>    When applied this matches the direction in which a TCP connection is
>    initiated.  When direction initiated is "from-device", packets that are
>    transmitted in the direction of a thing MUST be dropped unless the 
> thing
>    has first initiated a TCP connection.  This node may be implemented in
>    its simplest form by looking at naked SYN bits, but may also be 
> implemented
>    through more stateful mechanisms.
>
>   [RFC6092] specifies IPv6 guidance best
>    practices.  While that document is scoped specifically to IPv6, its
>    contents are applicable for IPv4 as well.
>
>
> Better?
wfm
>
>> The quoted issues below are from my early review of -08. I don't think they've
>> been addressed or responded to. Apologies if I missed a response.
>>
>>> The document proposes "reputation services". It needs more words about
>>> whether those exist, and what scopes the architecture imagines (an
>>> enterprise might have a different idea of a reputation service than a
>>> residence). There is a notion of "decent web reputations" in the security
>>> considerations section. Who determines that? The security considerations
>>> section should talk about attacks against the reputation services.
>>> I think there needs to be more discussion of the PKI used for signing MUD
>>> files.
>>   
>
> While this section is admittedly a bit vague, we need some operational 
> experience to develop the appropriate use of PKI as an anchor for 
> reputations.  This having been said, if you have a specific proposal 
> for text, I'd be interested in what you have to say.
Do you envision enterprises or manufacturers creating a new set of 
anchors of trust, or are you hoping to reuse the web PKI or something 
else? If you don't know and all of these are on the table, mentioning it 
would help implementers avoid assumptions that could hinder deployment.
>
>>> Consider discussing whether the stacks used by typical things will let
>>> them add DHCP options (or include bits in the other protocols being
>>> enabled). If it's well known (I can't say) that these stacks typically
>>> _won't_ provide that functionality, then you should punch up the
>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>> behalf of the thing.
>
> We did indeed add some text about this, almost verbatim to what you 
> have above (I think at your suggestion).  This can be found in the 
> introduction toward the bottom of page 9.
I'm not seeing it in -20. Maybe its in your working copy but not issued 
yet, or 9 above isn't where you meant to point? I did a quick search for 
DHCP through the document and didn't spot the discussion. Apologies if 
I'm just missing it.

>>   
>>> You suggest the DHCP Client (which is a thing) SHOULD log or report
>>> improper acknowledgments from servers. That's asking a bit much from
>>> a thing. I suspect the requirement is unrealistic and should be removed
>>> or rewritten to acknowledge that things typically won't do that.
>
> I propose to delete that paragraph to match that we do not wish DHCP 
> servers to modify their state.  This would address your concern (also 
> see below).
ack
>
>>   
>>> The security and deployment considerations sections talk about what the
>>> need for coordination if control over the domain name used in the URL
>>> changes. It should talk more about what happens if the new administration
>>> of the domain is not interested in facilitating a transition (consider
>>> the case of a young company with a few thousand start-up-ish things out
>>> there that loses a suit over its name). Please discuss whether or not
>>> suddenly losing the MUD assisted network configuration is expected to
>>> leave the devices effectively cut-off.
>
> The example you are talking about is a subset of what happens if the 
> file simply doesn't exist.  At worst, one is left in a situation no 
> worse than we are today: that is, someone will have to manually decide 
> policy, or apply a default policy.  This particular text is the 
> subject of separate piece of work that Thorsten Dahm and Steve Rich 
> are considering, and it is also the subject of some ongoing research.  
> That is to say: we might be able to do better in the future when we 
> have some operational experience.
OK. I suppose the detail I was hoping to see was some insight into 
recovery (how my hypothetical company above could start providing new 
MUD files that the existing devices would be convinced to use). I'll 
accept that is "future work".
>
>
>>   
>>> Right now, you leave the DHCP server (when it's used) responsible for
>>> clearing state in the MUD controller. Please discuss what happens when
>>> those are distinct elements (as you have in the end of section 9.2) and
>>> the DHCP server reboots. Perhaps it would make sense for the DHCP server
>>> to hand the length of the lease it has granted to the MUD controller and
>>> let the MUD controller clean up on its own?
>
> Ok, two issues:
>
>  1. There was some text that should have been removed, referring to
>     the DHCP server returning the MUD-URL as part of state. With
>     everyone's permission, I propose to remove that text.  No
>     additional DHCP server state should be required to implement this
>     option.
>  2. I agree that we could be a bit more descriptive about what would
>     happen if a reboot of the DHCP server.  I also like your idea
>     about mentioning the lease time to the MUD controller. With that
>     in mind, how about the following text:
>
>
> With that in mind, I propose the following edit:
>
> DHCP servers may implement MUD functionality themselves or they may
> pass along appropriate information to a network management system or
> MUD controller.  A DHCP server that does process the MUD URL MUST adhere
> to the process specified in {{RFC2818}} and {{RFC5280}} to validate
> the TLS certificate of the web server hosting the MUD file. Those
> servers will retrieve the file, process it, create and install the
> necessary configuration on the relevant network element. Servers
> SHOULD monitor the gateway for state changes on a given interface.  A
> DHCP server that does not provide MUD functionality and has forwarded
> a MUD URL to a MUD controller MUST notify the MUD controller
> of any corresponding change to the DHCP state of the client
> (such as expiration or explicit release of a network address lease).
>
> Should the DHCP server fail, in the case when it implements the MUD
> controller functionality, any backup mechanisms SHOULD include the MUD
> state, and the server SHOULD resolve the status of clients upon its
> restart, similar to what it would do, absent MUD controller
> functionality.  In the case where the DHCP server forwards information
> to the MUD controller, the MUD controller will either make use of
> redundant DHCP servers for information, or otherwise clear state based
> on other network information, such as monitoring port status on a
> switch via SNMP, Radius accounting, or similar mechanisms.
>
>
wfm - thanks
>>   
>> Nits:
>>
>> There is tension between the paragraph in the introduction that characterizes
>> the manufacturer as the entity that provides the mud file and the third bullet
>> in the intent list about speeding vulnerability resolution for devices that
>> are no longer supported by the manufacturer (you intend here that someone other
>> than the original manufacturer or integrator is providing a new mud file).
>
> Perhaps this is best fixed by dropping the phrase "by the manufacturer"?
ok
>
>> Instead of "A light bulb is intended to light a room.", I suggest
>> "A light bulb is intended to light a given space." (There are lightbulbs
>> meant for outdoor use, and others for only inside cabinets or appliances.)
>
> Ok.
>
>> Instead of "We make use of YANG because of the time and effort spent to develop
>> accurate..." I suggest "We make use of YANG because it provides accurate..."
>
> Ok.
>> At the end of section 1.7, instead of "For these reasons only a limited subset
>> YANG-based configuration is permitted in a MUD file.", I suggest "For these
>> reasons, the YANG-based configuration in a MUD file is limited to the YANG
>> modules defined in this document." or something similar.
> s/defined/specified/ but otherwise ok.
>
>> In section 3.6, the parenthesized clause does not belong in the sentence in
>> which it currently appears. I suggest it belongs somewhere in the previous
>> sentence.
>
> I've removed it and rewritten as follows:
>
> The intent is for administrators to be able to see a
> brief displayable description of the Thing.
ok
>
>> In section 3.13 you talk about classes that are standardized. Where does
>> someone find out about standardized classes?
>
> They're described in the document
Ah. maybe in 3.13 you could say "classes standardized by this document 
or future RFCs"?

>> Micro-nits:
>>
>> "Our work begins with" in section 1.5 is awkward and I suspect will cause
>> problems if this document is translated into other languages.
>
> If you *know* this to be a problem, I will make a change.
I can't demonstrate a problem.

>
>> At "======= The MUD URL identifies" in section 5, I suggest deleting the =
>> signs.
>
> I believe this is corrected.
>> Please provide a reference or better description for "so-called east-west
>> infection""
>
> I'll change this to "lateral infection (infection of devices that 
> reside near one another)".
ok
>> The string "enorcement" appears a couple of times in the models. It is intended
>> to be "enforcement".
>>
> Thanks for catching these.
>
And thank you again for the quick response.


--------------7777D376BC84DF41A658AA78
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 4/10/18 5:43 AM, Eliot Lear wrote:

    

    

      
      
Hi Robert and thanks again for the review.  Please see below
        for responses.  These are my personal views.  The WG chairs /
        shepherds may have different opinions.

      

    

    Thank you for the very quick response!

    

      
 

      

      
On 09.04.18 19:57, Robert Sparks
        wrote:

      

      

        
Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-20
Reviewer: Robert Sparks
Review Date: 2018-04-09
IETF LC End Date: 2017-11-07
IESG Telechat date: 2018-04-19

Summary: Almost ready but with minor issues to address before publication as a
standards track RFC 

Minor issues:

Section 3.15 is confused, and I don't think you'll get the implementation you
intend with the MUST in the current language. direction-indicated is not a
flag. The text about dropping should talk about matching the direction that was
indicated.

      

      

      Having reread this section (and perhaps I am a bit too close to
      the text), perhaps it is a bit confused.  How about something
      along the following lines:

      

      3.15.  direction-initiated

      

         When applied this matches the direction in which a TCP
      connection is

         initiated.  When direction initiated is "from-device", packets
      that are

         transmitted in the direction of a thing MUST be dropped unless
      the thing

         has first initiated a TCP connection.  This node may be
      implemented in

         its simplest form by looking at naked SYN bits, but may also be
      implemented

         through more stateful mechanisms.

        

        [RFC6092] specifies IPv6 guidance best

         practices.  While that document is scoped specifically to IPv6,
      its

         contents are applicable for IPv4 as well.  

      

      

      Better?

    

    wfm

    
 

      

        
The quoted issues below are from my early review of -08. I don't think they've
been addressed or responded to. Apologies if I missed a response.



        

          
The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.


        

        

          
I think there needs to be more discussion of the PKI used for signing MUD
files.


        

        
 

      

      

      While this section is admittedly a bit vague, we need some
      operational experience to develop the appropriate use of PKI as an
      anchor for reputations.  This having been said, if you have a
      specific proposal for text, I'd be interested in what you have to
      say.

    

    Do you envision enterprises or manufacturers creating a new set of
    anchors of trust, or are you hoping to reuse the web PKI or
    something else? If you don't know and all of these are on the table,
    mentioning it would help implementers avoid assumptions that could
    hinder deployment.

    
 

      

        

          
Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being 
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

        

      

      

      We did indeed add some text about this, almost verbatim to what
      you have above (I think at your suggestion).  This can be found in
      the introduction toward the bottom of page 9.

    

    I'm not seeing it in -20. Maybe its in your working copy but not
    issued yet, or 9 above isn't where you meant to point? I did a quick
    search for DHCP through the document and didn't spot the discussion.
    Apologies if I'm just missing it.

    

    

      

        
 

        
 


        

          
You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.

        

      

      

      I propose to delete that paragraph to match that we do not wish
      DHCP servers to modify their state.  This would address your
      concern (also see below).

    

    ack

    
 

      

        
 

        
 


        

          
The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration
of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off. 

        

      

      

      The example you are talking about is a subset of what happens if
      the file simply doesn't exist.  At worst, one is left in a
      situation no worse than we are today: that is, someone will have
      to manually decide policy, or apply a default policy.  This
      particular text is the subject of separate piece of work that
      Thorsten Dahm and Steve Rich are considering, and it is also the
      subject of some ongoing research.  That is to say: we might be
      able to do better in the future when we have some operational
      experience.

    

    OK. I suppose the detail I was hoping to see was some insight into
    recovery (how my hypothetical company above could start providing
    new MUD files that the existing devices would be convinced to use).
    I'll accept that is "future work".

    
 

      

      

        
 

        
 


        

          
Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

        

      

      

      Ok, two issues:

      
    
        
  1. There was some text that should have been removed, referring
          to the DHCP server returning the MUD-URL as part of state. 
          With everyone's permission, I propose to remove that text.  No
          additional DHCP server state should be required to implement
          this option.
    2. 
        
  2. I agree that we could be a bit more descriptive about what
          would happen if a reboot of the DHCP server.  I also like your
          idea about mentioning the lease time to the MUD controller. 
          With that in mind, how about the following text:
    3. 
      

      


      

      
With that in mind, I propose the following edit:

      
DHCP servers may implement MUD functionality themselves or they
        may

        pass along appropriate information to a network management
        system or

        MUD controller.  A DHCP server that does process the MUD URL
        MUST adhere

        to the process specified in {{RFC2818}} and {{RFC5280}} to
        validate

        the TLS certificate of the web server hosting the MUD file. 
        Those

        servers will retrieve the file, process it, create and install
        the

        necessary configuration on the relevant network element. 
        Servers

        SHOULD monitor the gateway for state changes on a given
        interface.  A

        DHCP server that does not provide MUD functionality and has
        forwarded

        a MUD URL to a MUD controller MUST notify the MUD controller

        of any corresponding change to the DHCP state of the client

        (such as expiration or explicit release of a network address
        lease).

        

        Should the DHCP server fail, in the case when it implements the
        MUD

        controller functionality, any backup mechanisms SHOULD include
        the MUD

        state, and the server SHOULD resolve the status of clients upon
        its

        restart, similar to what it would do, absent MUD controller

        functionality.  In the case where the DHCP server forwards
        information

        to the MUD controller, the MUD controller will either make use
        of

        redundant DHCP servers for information, or otherwise clear state
        based

        on other network information, such as monitoring port status on
        a

        switch via SNMP, Radius accounting, or similar mechanisms.

      

      

    

    wfm - thanks

    

      

        
 

        
 
Nits:

There is tension between the paragraph in the introduction that characterizes
the manufacturer as the entity that provides the mud file and the third bullet
in the intent list about speeding vulnerability resolution for devices that
are no longer supported by the manufacturer (you intend here that someone other
than the original manufacturer or integrator is providing a new mud file).

      

      

      Perhaps this is best fixed by dropping the phrase "by the
      manufacturer"?

    

    ok

    
 

      

        
Instead of "A light bulb is intended to light a room.", I suggest 
"A light bulb is intended to light a given space." (There are lightbulbs
meant for outdoor use, and others for only inside cabinets or appliances.)

      

      

      Ok.

      

      

        
Instead of "We make use of YANG because of the time and effort spent to develop
accurate..." I suggest "We make use of YANG because it provides accurate..."

      

      

      Ok.

      

        
At the end of section 1.7, instead of "For these reasons only a limited subset
YANG-based configuration is permitted in a MUD file.", I suggest "For these
reasons, the YANG-based configuration in a MUD file is limited to the YANG
modules defined in this document." or something similar.

      

      s/defined/specified/ but otherwise ok.

      

      

        
In section 3.6, the parenthesized clause does not belong in the sentence in 
which it currently appears. I suggest it belongs somewhere in the previous
sentence.

      

      

      I've removed it and rewritten as follows:

      

      The intent is for administrators to be able to see a

      brief displayable description of the Thing. 

    

    ok

    
 

      

        
In section 3.13 you talk about classes that are standardized. Where does 
someone find out about standardized classes?

      

      

      They're described in the document

    

    Ah. maybe in 3.13 you could say "classes standardized by this
    document or future RFCs"?

    

    

      

        
Micro-nits:

"Our work begins with" in section 1.5 is awkward and I suspect will cause
problems if this document is translated into other languages.

      

      

      If you *know* this to be a problem, I will make a change.

    

    I can't demonstrate a problem.

    

    
 

      

        
At "======= The MUD URL identifies" in section 5, I suggest deleting the =
signs.

      

      

      I believe this is corrected.

      

        
Please provide a reference or better description for "so-called east-west
infection""

      

      

      I'll change this to "lateral infection (infection of devices that
      reside near one another)".

    

    ok

    

      

        
The string "enorcement" appears a couple of times in the models. It is intended
to be "enforcement".



      

      Thanks for catching these.

      

    

    And thank you again for the quick response.

    

  


--------------7777D376BC84DF41A658AA78--


From nobody Tue Apr 10 10:20:28 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864711270A0; Tue, 10 Apr 2018 10:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rpSadp60AGvm; Tue, 10 Apr 2018 10:20:20 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E712B126CD8; Tue, 10 Apr 2018 10:20:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 742DA6475252; Tue, 10 Apr 2018 13:20:18 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUx85KimrjfC; Tue, 10 Apr 2018 13:20:14 -0400 (EDT)
Received: from [10.220.219.137] (wrls-140-247-0-130.wrls.harvard.edu [140.247.0.130]) by sobco.sobco.com (Postfix) with ESMTPSA id 8404B647522A; Tue, 10 Apr 2018 13:20:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Scott Bradner 
In-Reply-To: 
Date: Tue, 10 Apr 2018 13:20:13 -0400
Cc: ops-dir@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <152336540077.13556.13954379711415125489@ietfa.amsl.com> 
To: Eliot Lear 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
Subject: Re: [OPSAWG] Opsdir telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 17:20:22 -0000

wfm

thanks

Scott

> On Apr 10, 2018, at 10:11 AM, Eliot Lear  wrote:
>=20
> Hi Scott,
>=20
> Thanks for your review.  Please see below.
>=20
>=20
> On 10.04.18 15:03, Scott Bradner wrote:
>> Reviewer: Scott Bradner
>> Review result: Has Nits
>>=20
>> I did an OPS-DIR review of Manufacturer Usage Description =
Specification <
>> draft-ietf-opsawg-mud > The specification is well written and clear =
(I also
>> agree with Robert Spark's nits).
>>=20
>> One suggestion about document organization: I would either move the =
discussion
>> of what should be done if the MUD controller can not retrieve the MUD =
file for
>> some reason or another out of the security considerations section to =
after
>> section 1.9 or at least include a forward pointer to the discussion.
>>=20
>=20
> I think this is a good point.  Section 1.6 ok with you?
>=20
> Eliot
>=20
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


From nobody Tue Apr 10 13:09:14 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD812D779; Tue, 10 Apr 2018 13:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 u5hyBJ14bpTv; Tue, 10 Apr 2018 13:09:10 -0700 (PDT)
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 8FD72127876; Tue, 10 Apr 2018 13:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=339; q=dns/txt; s=iport; t=1523390950; x=1524600550; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=H62BgMErM82ATywtPw2CJZld/iZw5Jubg23TWavUoq4=; b=ILZ9UoUVS/GtDGgnV1LUQ+CDn0Lg3/NHXk0ndlPVYu1nBOs3taLVwEXW rKI0FhHUzn9KXkRatRPfilotsTXpbCOpeiaueWyIO6u1pPGDhTt/RD66X 1mjtB35nflY3lzyhiFnZklADBJC4I5o8u/UTsVg7wd4uq0BPJ6KmQ7SxC k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQCBGc1a/5FdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNCgVCECIgBjRKBS4E4kl6BeguHSyE0GAECAQEBAQEBAmw?= =?us-ascii?q?dC4VMgQsCJgJfDQgBAYUJpnKCHIhEgh+BCYZigVQ/gQwiilGCVAKLfotSCIE?= =?us-ascii?q?0jHwGgSUBhh+Ef5AOgSUcOIFSTSMVOoJEkGkjj00BAQ?=
X-IronPort-AV: E=Sophos;i="5.48,433,1517875200"; d="scan'208";a="379269896"
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; 10 Apr 2018 20:09:09 +0000
Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w3AK99QX010987; Tue, 10 Apr 2018 20:09:09 GMT
To: "opsawg@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: <9491fadc-8dd0-6fa1-26b1-cc7035e48f3c@cisco.com>
Date: Tue, 10 Apr 2018 16:09:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OPSAWG] Typo in latest MUD draft (-20)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 20:09:12 -0000

MUD authors, I was reading through the XML, and I noticed a typo in your
IANA considerations:


  Name: ietf-mud
  XML Namespace: urn:ietf:params:xml:ns:yang:ietf-mud
  Prefix: ief-mud
  Reference: This memo


You're missing the 't' in the ietf-mud prefix.

Joe


From nobody Tue Apr 10 13:31:52 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E72412895E; Tue, 10 Apr 2018 13:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 5oa33bEB0FoP; Tue, 10 Apr 2018 13:31:44 -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 BB9B51272E1; Tue, 10 Apr 2018 13:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2159; q=dns/txt; s=iport; t=1523392303; x=1524601903; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WfSDmKJYaiilp5+daJAWJJfn0Ia6b/yjbUjw6X8P2yU=; b=LjeWFWcdH05Xzdo8nW+bnkCXM3sbzVTZ1RJG6/m6wv1SfuEYF4jyCj0f pQULCW2nySFtIf5N6rvzIetgjbCayC4GWZMshN9N+3rs2kcYIMfzVyrd6 iu7tCSL28hYSbFSSFcRp1pkcE4gB7wBVTDlNge+5m+lCEpGaFV67bjzji 0=;
X-IronPort-AV: E=Sophos;i="5.48,433,1517875200"; d="scan'208";a="96449581"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2018 20:31:43 +0000
Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w3AKVgxc007968; Tue, 10 Apr 2018 20:31:43 GMT
To: Eliot Lear , Robert Sparks , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: 
Date: Tue, 10 Apr 2018 16:31:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <10591659-b464-ad66-a499-6567202cc782@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 20:31:46 -0000

On 4/10/18 06:43, Eliot Lear wrote:
> With that in mind, I propose the following edit:
> 
> DHCP servers may implement MUD functionality themselves or they may
> pass along appropriate information to a network management system or
> MUD controller.  A DHCP server that does process the MUD URL MUST adhere
> to the process specified in {{RFC2818}} and {{RFC5280}} to validate
> the TLS certificate of the web server hosting the MUD file.  Those
> servers will retrieve the file, process it, create and install the
> necessary configuration on the relevant network element.  Servers
> SHOULD monitor the gateway for state changes on a given interface.  A
> DHCP server that does not provide MUD functionality and has forwarded
> a MUD URL to a MUD controller MUST notify the MUD controller
> of any corresponding change to the DHCP state of the client
> (such as expiration or explicit release of a network address lease).
> 
> Should the DHCP server fail, in the case when it implements the MUD
> controller functionality, any backup mechanisms SHOULD include the MUD
> state, and the server SHOULD resolve the status of clients upon its
> restart, similar to what it would do, absent MUD controller
> functionality.  In the case where the DHCP server forwards information
> to the MUD controller, the MUD controller will either make use of
> redundant DHCP servers for information, or otherwise clear state based
> on other network information, such as monitoring port status on a
> switch via SNMP, Radius accounting, or similar mechanisms.

Robert says this text works for him, and it does address the comments,
but I wonder if it's getting too far afield where at this point you're
re-describing a MUD controller as a software feature of DHCP?  That is,
do we really need to call out that a DHCP server can _also_ be a MUD
controller?  They may be co-resident on the same server, they may be in
the same process space.  Does it matter?

It seems to me, the most valuable part of this text is the in the second
paragraph where the DHCP state's impact on the MUD controller (where
ever that is) is described.

Joe


From nobody Tue Apr 10 23:35:38 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDB9126C2F; Tue, 10 Apr 2018 23:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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
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 l8BhOjgaIKjR; Tue, 10 Apr 2018 23:35:22 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1EF1241FC; Tue, 10 Apr 2018 23:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34964; q=dns/txt; s=iport; t=1523428522; x=1524638122; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=q8wrvAh7sMn7/DqlTo9VnL/zAdfl8rQ9qeeT+upaYOY=; b=a5Bn1eC6GMvq7wC9ZCXQ1WpfHH9nTh1GVWT4/WHiYvSaoH7n428VZulW +ibcSKViWZUHEaDufCvyZB0gz5wvF6YILf2gtxfH5tyMDfvZuWSv8vX3P gYCQ97/9ZW86OsgPQqa3u+0YE5dsC+bOCjNYaxngoavnUO+7UtFYAatQI c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYBAA8q81a/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgxMEgQxvhAqIAV6NfimBD5JeFIFmCyOEYAKCazQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSIBAQEBAgEaCVYQCw4EAgQgCgICSQ4GAQwIAQGFAQgPiX2?= =?us-ascii?q?cKoIcH4gxghoFigGBDCKBZnyDEQKBGB0PAjaCYIJUAocNBygFCoQzhFeGewi?= =?us-ascii?q?FVoZKghAGgTODWoI3hH+JH4ZvgSUcOIFSMxoIGxU6gkSCGgUXegEIh1aFQD2?= =?us-ascii?q?MbAIkB4IYAQE?=
X-IronPort-AV: E=Sophos;i="5.48,434,1517875200"; d="scan'208,217";a="3076485"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2018 06:35:19 +0000
Received: from [10.61.160.124] ([10.61.160.124]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3B6ZIq7010233; Wed, 11 Apr 2018 06:35:18 GMT
To: Robert Sparks , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com> 
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: 
Date: Wed, 11 Apr 2018 08:35:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------ACB27F9B4CD32B67120747BF"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 06:35:28 -0000

This is a multi-part message in MIME format.
--------------ACB27F9B4CD32B67120747BF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi Robert,

A few additional comments below:


On 10.04.18 16:22, Robert Sparks wrote:
>
>
>
> On 4/10/18 5:43 AM, Eliot Lear wrote:
>>
>> Hi Robert and thanks again for the review.  Please see below for
>> responses.  These are my personal views.  The WG chairs / shepherds
>> may have different opinions.
>>
> Thank you for the very quick response!
>>
>>
>> On 09.04.18 19:57, Robert Sparks wrote:
>>> Reviewer: Robert Sparks
>>> Review result: Ready with Issues
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the draft.
>>>
>>> For more information, please see the FAQ at
>>>
>>> .
>>>
>>> Document: draft-ietf-opsawg-mud-20
>>> Reviewer: Robert Sparks
>>> Review Date: 2018-04-09
>>> IETF LC End Date: 2017-11-07
>>> IESG Telechat date: 2018-04-19
>>>
>>> Summary: Almost ready but with minor issues to address before publication as a
>>> standards track RFC 
>>>
>>> Minor issues:
>>>
>>> Section 3.15 is confused, and I don't think you'll get the implementation you
>>> intend with the MUST in the current language. direction-indicated is not a
>>> flag. The text about dropping should talk about matching the direction that was
>>> indicated.
>>
>> Having reread this section (and perhaps I am a bit too close to the
>> text), perhaps it is a bit confused.  How about something along the
>> following lines:
>>
>> 3.15.  direction-initiated
>>
>>    When applied this matches the direction in which a TCP connection is
>>    initiated.  When direction initiated is "from-device", packets
>> that are
>>    transmitted in the direction of a thing MUST be dropped unless the
>> thing
>>    has first initiated a TCP connection.  This node may be implemented in
>>    its simplest form by looking at naked SYN bits, but may also be
>> implemented
>>    through more stateful mechanisms.
>>  
>>   [RFC6092] specifies IPv6 guidance best
>>    practices.  While that document is scoped specifically to IPv6, its
>>    contents are applicable for IPv4 as well. 
>>
>>
>> Better?
> wfm
>>
>>> The quoted issues below are from my early review of -08. I don't think they've
>>> been addressed or responded to. Apologies if I missed a response.
>>>
>>>> The document proposes "reputation services". It needs more words about
>>>> whether those exist, and what scopes the architecture imagines (an
>>>> enterprise might have a different idea of a reputation service than a
>>>> residence). There is a notion of "decent web reputations" in the security
>>>> considerations section. Who determines that? The security considerations
>>>> section should talk about attacks against the reputation services.
>>>> I think there needs to be more discussion of the PKI used for signing MUD
>>>> files.
>>>  
>>
>> While this section is admittedly a bit vague, we need some
>> operational experience to develop the appropriate use of PKI as an
>> anchor for reputations.  This having been said, if you have a
>> specific proposal for text, I'd be interested in what you have to say.
> Do you envision enterprises or manufacturers creating a new set of
> anchors of trust, or are you hoping to reuse the web PKI or something
> else? If you don't know and all of these are on the table, mentioning
> it would help implementers avoid assumptions that could hinder deployment.

Thanks for the guidance.   In fact I think we need to more clearly
specify the signature in terms of the purpose.  The tools (openssl)
support S/MIME signing easily enough for CMS.  I think this is what we
want, and it implies that we are *not* using the webpki, but instead
just getting an S/MIME certificate.  This implies that the signers will
have to be "admitted" on first sight.  Would that work for you?

Also see below.


>>
>>>> Consider discussing whether the stacks used by typical things will let
>>>> them add DHCP options (or include bits in the other protocols being 
>>>> enabled). If it's well known (I can't say) that these stacks typically
>>>> _won't_ provide that functionality, then you should punch up the
>>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>>> behalf of the thing.
>>
>> We did indeed add some text about this, almost verbatim to what you
>> have above (I think at your suggestion).  This can be found in the
>> introduction toward the bottom of page 9.
> I'm not seeing it in -20. Maybe its in your working copy but not
> issued yet, or 9 above isn't where you meant to point? I did a quick
> search for DHCP through the document and didn't spot the discussion.
> Apologies if I'm just missing it.

Actually it's in two places.  See where we say in Section 1.5:

   It is possible that there may be other means for a MUD URL to be
   learned by a network.  For instance, some devices may already be
   fielded or have very limited ability to communicate a MUD URL, and
   yet can be identified through some means, such as a serial number or
   a public key.  In these cases, manufacturers may be able to map those
   identifiers to particular MUD URLs (or even the files themselves).
   Similarly, there may be alternative resolution mechanisms available
   for situations where Internet connectivity is limited or does not
   exist.  Such mechanisms are not described in this memo, but are
   possible.  Implementors should allow for this sort of flexibility of
   how MUD URLs may be learned.

Elsewhere we say:

   If a MUD controller is not able to fetch a MUD URL, other means MAY
   be used to import MUD files and associated signature files.  So long
   as the signature of the file can be validated, the file can be used.
   In such environments, controllers SHOULD warn administrators when
   cache-validity expiry is approaching so that they may check for new
   files.

So I'm hoping between the two we have you covered ;-).

More below.

>
>>>  
>>>> You suggest the DHCP Client (which is a thing) SHOULD log or report 
>>>> improper acknowledgments from servers. That's asking a bit much from
>>>> a thing. I suspect the requirement is unrealistic and should be removed
>>>> or rewritten to acknowledge that things typically won't do that.
>>
>> I propose to delete that paragraph to match that we do not wish DHCP
>> servers to modify their state.  This would address your concern (also
>> see below).
> ack
>>
>>>  
>>>> The security and deployment considerations sections talk about what the
>>>> need for coordination if control over the domain name used in the URL
>>>> changes. It should talk more about what happens if the new administration
>>>> of the domain is not interested in facilitating a transition (consider
>>>> the case of a young company with a few thousand start-up-ish things out
>>>> there that loses a suit over its name). Please discuss whether or not
>>>> suddenly losing the MUD assisted network configuration is expected to
>>>> leave the devices effectively cut-off. 
>>
>> The example you are talking about is a subset of what happens if the
>> file simply doesn't exist.  At worst, one is left in a situation no
>> worse than we are today: that is, someone will have to manually
>> decide policy, or apply a default policy.  This particular text is
>> the subject of separate piece of work that Thorsten Dahm and Steve
>> Rich are considering, and it is also the subject of some ongoing
>> research.  That is to say: we might be able to do better in the
>> future when we have some operational experience.
> OK. I suppose the detail I was hoping to see was some insight into
> recovery (how my hypothetical company above could start providing new
> MUD files that the existing devices would be convinced to use). I'll
> accept that is "future work".

Ok,
>>
>>
>>>  
>>>> Right now, you leave the DHCP server (when it's used) responsible for
>>>> clearing state in the MUD controller. Please discuss what happens when
>>>> those are distinct elements (as you have in the end of section 9.2) and
>>>> the DHCP server reboots. Perhaps it would make sense for the DHCP server
>>>> to hand the length of the lease it has granted to the MUD controller and
>>>> let the MUD controller clean up on its own?
>>
>> Ok, two issues:
>>
>>  1. There was some text that should have been removed, referring to
>>     the DHCP server returning the MUD-URL as part of state.  With
>>     everyone's permission, I propose to remove that text.  No
>>     additional DHCP server state should be required to implement this
>>     option.
>>  2. I agree that we could be a bit more descriptive about what would
>>     happen if a reboot of the DHCP server.  I also like your idea
>>     about mentioning the lease time to the MUD controller.  With that
>>     in mind, how about the following text:
>>
>>
>> With that in mind, I propose the following edit:
>>
>> DHCP servers may implement MUD functionality themselves or they may
>> pass along appropriate information to a network management system or
>> MUD controller.  A DHCP server that does process the MUD URL MUST adhere
>> to the process specified in {{RFC2818}} and {{RFC5280}} to validate
>> the TLS certificate of the web server hosting the MUD file.  Those
>> servers will retrieve the file, process it, create and install the
>> necessary configuration on the relevant network element.  Servers
>> SHOULD monitor the gateway for state changes on a given interface.  A
>> DHCP server that does not provide MUD functionality and has forwarded
>> a MUD URL to a MUD controller MUST notify the MUD controller
>> of any corresponding change to the DHCP state of the client
>> (such as expiration or explicit release of a network address lease).
>>
>> Should the DHCP server fail, in the case when it implements the MUD
>> controller functionality, any backup mechanisms SHOULD include the MUD
>> state, and the server SHOULD resolve the status of clients upon its
>> restart, similar to what it would do, absent MUD controller
>> functionality.  In the case where the DHCP server forwards information
>> to the MUD controller, the MUD controller will either make use of
>> redundant DHCP servers for information, or otherwise clear state based
>> on other network information, such as monitoring port status on a
>> switch via SNMP, Radius accounting, or similar mechanisms.
>>
>>
> wfm - thanks
>>>  
>>> Nits:
>>>
>>> There is tension between the paragraph in the introduction that characterizes
>>> the manufacturer as the entity that provides the mud file and the third bullet
>>> in the intent list about speeding vulnerability resolution for devices that
>>> are no longer supported by the manufacturer (you intend here that someone other
>>> than the original manufacturer or integrator is providing a new mud file).
>>
>> Perhaps this is best fixed by dropping the phrase "by the manufacturer"?
> ok
>>
>>> Instead of "A light bulb is intended to light a room.", I suggest 
>>> "A light bulb is intended to light a given space." (There are lightbulbs
>>> meant for outdoor use, and others for only inside cabinets or appliances.)
>>
>> Ok.
>>
>>> Instead of "We make use of YANG because of the time and effort spent to develop
>>> accurate..." I suggest "We make use of YANG because it provides accurate..."
>>
>> Ok.
>>> At the end of section 1.7, instead of "For these reasons only a limited subset
>>> YANG-based configuration is permitted in a MUD file.", I suggest "For these
>>> reasons, the YANG-based configuration in a MUD file is limited to the YANG
>>> modules defined in this document." or something similar.
>> s/defined/specified/ but otherwise ok.

Just one clarification- this text needed to be wordsmithed a little bit
more.  Keep in mind that the ACL model is supported as discussed in the
draft.

>>
>>> In section 3.6, the parenthesized clause does not belong in the sentence in 
>>> which it currently appears. I suggest it belongs somewhere in the previous
>>> sentence.
>>
>> I've removed it and rewritten as follows:
>>
>> The intent is for administrators to be able to see a
>> brief displayable description of the Thing.
> ok
>>
>>> In section 3.13 you talk about classes that are standardized. Where does 
>>> someone find out about standardized classes?
>>
>> They're described in the document
> Ah. maybe in 3.13 you could say "classes standardized by this document
> or future RFCs"?

Ahh!  ok.  I see the confusion.  I think an example may be appropriate
here (we are literally getting a lot of operational experience with this
day by day now).

Suppose you have a manufacturer X who has products P, D, and Q.  They
each want to talk to the same controller or group of controllers.  Use
of "my-controller" may invoke a process on a MUD controller that
requires that the administrator populate the class for each device P, D,
and Q.  Whereas with use of a controller class, the administrator only
has to populate the class once.

Similarly, the use of the word standardized naked like that is probably
unhelpful.  One could imagine, for instance, Fairhair or some other
consortium deciding to create standard classes.

What I propose is two changes to facilitate better understanding:

 1. To include the simple example described above.
 2. To add an optional "documentation"  element in the "mud" container
    that consists of a URL that points to documents for each class, when
    so used.

Thoughts?

Eliot


--------------ACB27F9B4CD32B67120747BF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Robert,

    
A few additional comments below:

    

    

    
On 10.04.18 16:22, Robert Sparks wrote:

    

    

      
      


      

      

      
On 4/10/18 5:43 AM, Eliot Lear wrote:

      

      

        
Hi Robert and thanks again for the review.  Please see below
          for responses.  These are my personal views.  The WG chairs /
          shepherds may have different opinions.

        

      

      Thank you for the very quick response!

      

        
 

        

        
On 09.04.18 19:57, Robert Sparks
          wrote:

        

        

          
Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-20
Reviewer: Robert Sparks
Review Date: 2018-04-09
IETF LC End Date: 2017-11-07
IESG Telechat date: 2018-04-19

Summary: Almost ready but with minor issues to address before publication as a
standards track RFC 

Minor issues:

Section 3.15 is confused, and I don't think you'll get the implementation you
intend with the MUST in the current language. direction-indicated is not a
flag. The text about dropping should talk about matching the direction that was
indicated.

        

        

        Having reread this section (and perhaps I am a bit too close to
        the text), perhaps it is a bit confused.  How about something
        along the following lines:

        

        3.15.  direction-initiated

        

           When applied this matches the direction in which a TCP
        connection is

           initiated.  When direction initiated is "from-device",
        packets that are

           transmitted in the direction of a thing MUST be dropped
        unless the thing

           has first initiated a TCP connection.  This node may be
        implemented in

           its simplest form by looking at naked SYN bits, but may also
        be implemented

           through more stateful mechanisms.

          

          [RFC6092] specifies IPv6 guidance best

           practices.  While that document is scoped specifically to
        IPv6, its

           contents are applicable for IPv4 as well.  

        

        

        Better?

      

      wfm

      
 

        

          
The quoted issues below are from my early review of -08. I don't think they've
been addressed or responded to. Apologies if I missed a response.



          

            
The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.


          

          

            
I think there needs to be more discussion of the PKI used for signing MUD
files.


          

          
 

        

        

        While this section is admittedly a bit vague, we need some
        operational experience to develop the appropriate use of PKI as
        an anchor for reputations.  This having been said, if you have a
        specific proposal for text, I'd be interested in what you have
        to say.

      

      Do you envision enterprises or manufacturers creating a new set of
      anchors of trust, or are you hoping to reuse the web PKI or
      something else? If you don't know and all of these are on the
      table, mentioning it would help implementers avoid assumptions
      that could hinder deployment.

    

    

    Thanks for the guidance.   In fact I think we need to more clearly
    specify the signature in terms of the purpose.  The tools (openssl)
    support S/MIME signing easily enough for CMS.  I think this is what
    we want, and it implies that we are not using the webpki,
    but instead just getting an S/MIME certificate.  This implies that
    the signers will have to be "admitted" on first sight.  Would that
    work for you?

    

    Also see below.

    

    

    

      
 

        

          

            
Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being 
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

          

        

        

        We did indeed add some text about this, almost verbatim to what
        you have above (I think at your suggestion).  This can be found
        in the introduction toward the bottom of page 9.

      

      I'm not seeing it in -20. Maybe its in your working copy but not
      issued yet, or 9 above isn't where you meant to point? I did a
      quick search for DHCP through the document and didn't spot the
      discussion. Apologies if I'm just missing it.

    

    

    Actually it's in two places.  See where we say in Section 1.5:

    

       It is possible that there may be other means for a MUD URL to be

       learned by a network.  For instance, some devices may already be

       fielded or have very limited ability to communicate a MUD URL,
    and

       yet can be identified through some means, such as a serial number
    or

       a public key.  In these cases, manufacturers may be able to map
    those

       identifiers to particular MUD URLs (or even the files
    themselves).

       Similarly, there may be alternative resolution mechanisms
    available

       for situations where Internet connectivity is limited or does not

       exist.  Such mechanisms are not described in this memo, but are

       possible.  Implementors should allow for this sort of flexibility
    of

       how MUD URLs may be learned.

    

    Elsewhere we say:

    

       If a MUD controller is not able to fetch a MUD URL, other means
    MAY

       be used to import MUD files and associated signature files.  So
    long

       as the signature of the file can be validated, the file can be
    used.

       In such environments, controllers SHOULD warn administrators when

       cache-validity expiry is approaching so that they may check for
    new

       files.

    

    So I'm hoping between the two we have you covered ;-).

    

    More below.

    

    
 

      

        

          
 

          
 


          

            
You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.

          

        

        

        I propose to delete that paragraph to match that we do not wish
        DHCP servers to modify their state.  This would address your
        concern (also see below).

      

      ack

      
 

        

          
 

          
 


          

            
The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration
of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off. 

          

        

        

        The example you are talking about is a subset of what happens if
        the file simply doesn't exist.  At worst, one is left in a
        situation no worse than we are today: that is, someone will have
        to manually decide policy, or apply a default policy.  This
        particular text is the subject of separate piece of work that
        Thorsten Dahm and Steve Rich are considering, and it is also the
        subject of some ongoing research.  That is to say: we might be
        able to do better in the future when we have some operational
        experience.

      

      OK. I suppose the detail I was hoping to see was some insight into
      recovery (how my hypothetical company above could start providing
      new MUD files that the existing devices would be convinced to
      use). I'll accept that is "future work".

    

    

    Ok,

    

      
 

        

        

          
 

          
 


          

            
Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

          

        

        

        Ok, two issues:

        
    
          
  1. There was some text that should have been removed,
            referring to the DHCP server returning the MUD-URL as part
            of state.  With everyone's permission, I propose to remove
            that text.  No additional DHCP server state should be
            required to implement this option.
    2. 
          
  2. I agree that we could be a bit more descriptive about what
            would happen if a reboot of the DHCP server.  I also like
            your idea about mentioning the lease time to the MUD
            controller.  With that in mind, how about the following
            text:
    3. 
        

        


        

        
With that in mind, I propose the following edit:

        
DHCP servers may implement MUD functionality themselves or
          they may

          pass along appropriate information to a network management
          system or

          MUD controller.  A DHCP server that does process the MUD URL
          MUST adhere

          to the process specified in {{RFC2818}} and {{RFC5280}} to
          validate

          the TLS certificate of the web server hosting the MUD file. 
          Those

          servers will retrieve the file, process it, create and install
          the

          necessary configuration on the relevant network element. 
          Servers

          SHOULD monitor the gateway for state changes on a given
          interface.  A

          DHCP server that does not provide MUD functionality and has
          forwarded

          a MUD URL to a MUD controller MUST notify the MUD controller

          of any corresponding change to the DHCP state of the client

          (such as expiration or explicit release of a network address
          lease).

          

          Should the DHCP server fail, in the case when it implements
          the MUD

          controller functionality, any backup mechanisms SHOULD include
          the MUD

          state, and the server SHOULD resolve the status of clients
          upon its

          restart, similar to what it would do, absent MUD controller

          functionality.  In the case where the DHCP server forwards
          information

          to the MUD controller, the MUD controller will either make use
          of

          redundant DHCP servers for information, or otherwise clear
          state based

          on other network information, such as monitoring port status
          on a

          switch via SNMP, Radius accounting, or similar mechanisms.

        

        

      

      wfm - thanks

      

        

          
 

          
 
Nits:

There is tension between the paragraph in the introduction that characterizes
the manufacturer as the entity that provides the mud file and the third bullet
in the intent list about speeding vulnerability resolution for devices that
are no longer supported by the manufacturer (you intend here that someone other
than the original manufacturer or integrator is providing a new mud file).

        

        

        Perhaps this is best fixed by dropping the phrase "by the
        manufacturer"?

      

      ok

      
 

        

          
Instead of "A light bulb is intended to light a room.", I suggest 
"A light bulb is intended to light a given space." (There are lightbulbs
meant for outdoor use, and others for only inside cabinets or appliances.)

        

        

        Ok.

        

        

          
Instead of "We make use of YANG because of the time and effort spent to develop
accurate..." I suggest "We make use of YANG because it provides accurate..."

        

        

        Ok.

        

          
At the end of section 1.7, instead of "For these reasons only a limited subset
YANG-based configuration is permitted in a MUD file.", I suggest "For these
reasons, the YANG-based configuration in a MUD file is limited to the YANG
modules defined in this document." or something similar.

        

        s/defined/specified/ but otherwise ok.

      

    

    

    Just one clarification- this text needed to be wordsmithed a little
    bit more.  Keep in mind that the ACL model is supported as discussed
    in the draft.

    

    

      
 

        

          
In section 3.6, the parenthesized clause does not belong in the sentence in 
which it currently appears. I suggest it belongs somewhere in the previous
sentence.

        

        

        I've removed it and rewritten as follows:

        

        The intent is for administrators to be able to see a

        brief displayable description of the Thing. 

      

      ok

      
 

        

          
In section 3.13 you talk about classes that are standardized. Where does 
someone find out about standardized classes?

        

        

        They're described in the document

      

      Ah. maybe in 3.13 you could say "classes standardized by this
      document or future RFCs"?

    

    

    Ahh!  ok.  I see the confusion.  I think an example may be
    appropriate here (we are literally getting a lot of operational
    experience with this day by day now).

    

    Suppose you have a manufacturer X who has products P, D, and Q. 
    They each want to talk to the same controller or group of
    controllers.  Use of "my-controller" may invoke a process on a MUD
    controller that requires that the administrator populate the class
    for each device P, D, and Q.  Whereas with use of a controller
    class, the administrator only has to populate the class once.

    

    Similarly, the use of the word standardized naked like that is
    probably unhelpful.  One could imagine, for instance, Fairhair or
    some other consortium deciding to create standard classes.

    

    What I propose is two changes to facilitate better understanding:

    
    
      
  1. To include the simple example described above.
    2. 
      
  2. To add an optional "documentation"  element in the "mud"
        container that consists of a URL that points to documents for
        each class, when so used.
    3. 
    

    
Thoughts?

    

    
Eliot

    

  


--------------ACB27F9B4CD32B67120747BF--


From nobody Tue Apr 10 23:36:52 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649CF126C2F for ; Tue, 10 Apr 2018 23:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 W_aJDbjlvljq for ; Tue, 10 Apr 2018 23:36:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1951241FC for ; Tue, 10 Apr 2018 23:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=467; q=dns/txt; s=iport; t=1523428608; x=1524638208; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=n8SApRGqHJ9wbRhAM8sVl+P1sWj8WiCaolOvO/DFemk=; b=h8O93xGUZnj4h+OLQ1sUCKkwSdqbOBJhq0dLRO87Qw0vkEC2LJayd/tn UUZMq9cHK7OOSQw5dKKkTjucL3517/0aoRtViub5+JvKjqA/jHEXgt1OL iVUjovIR/5qYOlW6wAnEEkg/xCiWghwPcEZ4oQq/95dRPpMCCajgsJoxb 4=;
X-IronPort-AV: E=Sophos;i="5.48,434,1517875200";  d="scan'208";a="3122799"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2018 06:36:46 +0000
Received: from [10.61.160.124] ([10.61.160.124]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3B6ajxQ005479; Wed, 11 Apr 2018 06:36:46 GMT
To: Joe Clarke , "opsawg@ietf.org" 
References: <9491fadc-8dd0-6fa1-26b1-cc7035e48f3c@cisco.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <53d8adc1-ece7-29a2-f474-b72527fd5cbf@cisco.com>
Date: Wed, 11 Apr 2018 08:36:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <9491fadc-8dd0-6fa1-26b1-cc7035e48f3c@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Typo in latest MUD draft (-20)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 06:36:50 -0000

Right you are!

Corrected in my working copy.

Eliot



On 10.04.18 22:09, Joe Clarke wrote:
> MUD authors, I was reading through the XML, and I noticed a typo in your
> IANA considerations:
>
> 
>   Name: ietf-mud
>   XML Namespace: urn:ietf:params:xml:ns:yang:ietf-mud
>   Prefix: ief-mud
>   Reference: This memo
> 
>
> You're missing the 't' in the ietf-mud prefix.
>
> Joe
>


From nobody Wed Apr 11 09:15:37 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65B112711E; Wed, 11 Apr 2018 09:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 WVihd5CzyyJ1; Wed, 11 Apr 2018 09:15:21 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396F21200FC; Wed, 11 Apr 2018 09:15:21 -0700 (PDT)
Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BGFGq2083976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 11:15:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local
To: Eliot Lear , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>  
From: Robert Sparks 
Message-ID: <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com>
Date: Wed, 11 Apr 2018 11:15:16 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------87FFFB5EAC24100EA92FF58C"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 16:15:27 -0000

This is a multi-part message in MIME format.
--------------87FFFB5EAC24100EA92FF58C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 4/11/18 1:35 AM, Eliot Lear wrote:
>
> Hi Robert,
>
> A few additional comments below:
>
>
> On 10.04.18 16:22, Robert Sparks wrote:
>>
>>
>>
>> On 4/10/18 5:43 AM, Eliot Lear wrote:
>>>
>>> Hi Robert and thanks again for the review.  Please see below for 
>>> responses.  These are my personal views.  The WG chairs / shepherds 
>>> may have different opinions.
>>>
>> Thank you for the very quick response!
>>>
>>>
>>> On 09.04.18 19:57, Robert Sparks wrote:
>>>> Reviewer: Robert Sparks
>>>> Review result: Ready with Issues
>>>>
>>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>>> by the IESG for the IETF Chair. Please wait for direction from your
>>>> document shepherd or AD before posting a new version of the draft.
>>>>
>>>> For more information, please see the FAQ at
>>>>
>>>> .
>>>>
>>>> Document: draft-ietf-opsawg-mud-20
>>>> Reviewer: Robert Sparks
>>>> Review Date: 2018-04-09
>>>> IETF LC End Date: 2017-11-07
>>>> IESG Telechat date: 2018-04-19
>>>>
>>>> Summary: Almost ready but with minor issues to address before publication as a
>>>> standards track RFC
>>>>
>>>> Minor issues:
>>>>
>>>> Section 3.15 is confused, and I don't think you'll get the implementation you
>>>> intend with the MUST in the current language. direction-indicated is not a
>>>> flag. The text about dropping should talk about matching the direction that was
>>>> indicated.
>>>
>>> Having reread this section (and perhaps I am a bit too close to the 
>>> text), perhaps it is a bit confused.  How about something along the 
>>> following lines:
>>>
>>> 3.15.  direction-initiated
>>>
>>>    When applied this matches the direction in which a TCP connection is
>>>    initiated.  When direction initiated is "from-device", packets 
>>> that are
>>>    transmitted in the direction of a thing MUST be dropped unless 
>>> the thing
>>>    has first initiated a TCP connection.  This node may be 
>>> implemented in
>>>    its simplest form by looking at naked SYN bits, but may also be 
>>> implemented
>>>    through more stateful mechanisms.
>>>
>>>   [RFC6092] specifies IPv6 guidance best
>>>    practices.  While that document is scoped specifically to IPv6, its
>>>    contents are applicable for IPv4 as well.
>>>
>>>
>>> Better?
>> wfm
>>>
>>>> The quoted issues below are from my early review of -08. I don't think they've
>>>> been addressed or responded to. Apologies if I missed a response.
>>>>
>>>>> The document proposes "reputation services". It needs more words about
>>>>> whether those exist, and what scopes the architecture imagines (an
>>>>> enterprise might have a different idea of a reputation service than a
>>>>> residence). There is a notion of "decent web reputations" in the security
>>>>> considerations section. Who determines that? The security considerations
>>>>> section should talk about attacks against the reputation services.
>>>>> I think there needs to be more discussion of the PKI used for signing MUD
>>>>> files.
>>>>   
>>>
>>> While this section is admittedly a bit vague, we need some 
>>> operational experience to develop the appropriate use of PKI as an 
>>> anchor for reputations.  This having been said, if you have a 
>>> specific proposal for text, I'd be interested in what you have to say.
>> Do you envision enterprises or manufacturers creating a new set of 
>> anchors of trust, or are you hoping to reuse the web PKI or something 
>> else? If you don't know and all of these are on the table, mentioning 
>> it would help implementers avoid assumptions that could hinder 
>> deployment.
>
> Thanks for the guidance.   In fact I think we need to more clearly 
> specify the signature in terms of the purpose.  The tools (openssl) 
> support S/MIME signing easily enough for CMS.  I think this is what we 
> want, and it implies that we are *not* using the webpki, but instead 
> just getting an S/MIME certificate.  This implies that the signers 
> will have to be "admitted" on first sight.  Would that work for you?
Sure
>
> Also see below.
>
>
>>>
>>>>> Consider discussing whether the stacks used by typical things will let
>>>>> them add DHCP options (or include bits in the other protocols being
>>>>> enabled). If it's well known (I can't say) that these stacks typically
>>>>> _won't_ provide that functionality, then you should punch up the
>>>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>>>> behalf of the thing.
>>>
>>> We did indeed add some text about this, almost verbatim to what you 
>>> have above (I think at your suggestion).  This can be found in the 
>>> introduction toward the bottom of page 9.
>> I'm not seeing it in -20. Maybe its in your working copy but not 
>> issued yet, or 9 above isn't where you meant to point? I did a quick 
>> search for DHCP through the document and didn't spot the discussion. 
>> Apologies if I'm just missing it.
>
> Actually it's in two places.  See where we say in Section 1.5:
>
>    It is possible that there may be other means for a MUD URL to be
>    learned by a network.  For instance, some devices may already be
>    fielded or have very limited ability to communicate a MUD URL, and
>    yet can be identified through some means, such as a serial number or
>    a public key.  In these cases, manufacturers may be able to map those
>    identifiers to particular MUD URLs (or even the files themselves).
>    Similarly, there may be alternative resolution mechanisms available
>    for situations where Internet connectivity is limited or does not
>    exist.  Such mechanisms are not described in this memo, but are
>    possible.  Implementors should allow for this sort of flexibility of
>    how MUD URLs may be learned.
>
> Elsewhere we say:
>
>    If a MUD controller is not able to fetch a MUD URL, other means MAY
>    be used to import MUD files and associated signature files.  So long
>    as the signature of the file can be validated, the file can be used.
>    In such environments, controllers SHOULD warn administrators when
>    cache-validity expiry is approaching so that they may check for new
>    files.
>
> So I'm hoping between the two we have you covered ;-).
Yes, I'll let this point go. You have well covered discussing 
controllers being able to map things to MUD URLs. You still don't 
explicitly discuss whether existing libraries would let things provide 
the URL in DHCP - that's what I was scanning for. But again, I'll let it go.
>
> More below.
>
>>
>>>>   
>>>>> You suggest the DHCP Client (which is a thing) SHOULD log or report
>>>>> improper acknowledgments from servers. That's asking a bit much from
>>>>> a thing. I suspect the requirement is unrealistic and should be removed
>>>>> or rewritten to acknowledge that things typically won't do that.
>>>
>>> I propose to delete that paragraph to match that we do not wish DHCP 
>>> servers to modify their state.  This would address your concern 
>>> (also see below).
>> ack
>>>
>>>>   
>>>>> The security and deployment considerations sections talk about what the
>>>>> need for coordination if control over the domain name used in the URL
>>>>> changes. It should talk more about what happens if the new administration
>>>>> of the domain is not interested in facilitating a transition (consider
>>>>> the case of a young company with a few thousand start-up-ish things out
>>>>> there that loses a suit over its name). Please discuss whether or not
>>>>> suddenly losing the MUD assisted network configuration is expected to
>>>>> leave the devices effectively cut-off.
>>>
>>> The example you are talking about is a subset of what happens if the 
>>> file simply doesn't exist.  At worst, one is left in a situation no 
>>> worse than we are today: that is, someone will have to manually 
>>> decide policy, or apply a default policy. This particular text is 
>>> the subject of separate piece of work that Thorsten Dahm and Steve 
>>> Rich are considering, and it is also the subject of some ongoing 
>>> research.  That is to say: we might be able to do better in the 
>>> future when we have some operational experience.
>> OK. I suppose the detail I was hoping to see was some insight into 
>> recovery (how my hypothetical company above could start providing new 
>> MUD files that the existing devices would be convinced to use). I'll 
>> accept that is "future work".
>
> Ok,
>>>
>>>
>>>>   
>>>>> Right now, you leave the DHCP server (when it's used) responsible for
>>>>> clearing state in the MUD controller. Please discuss what happens when
>>>>> those are distinct elements (as you have in the end of section 9.2) and
>>>>> the DHCP server reboots. Perhaps it would make sense for the DHCP server
>>>>> to hand the length of the lease it has granted to the MUD controller and
>>>>> let the MUD controller clean up on its own?
>>>
>>> Ok, two issues:
>>>
>>>  1. There was some text that should have been removed, referring to
>>>     the DHCP server returning the MUD-URL as part of state.  With
>>>     everyone's permission, I propose to remove that text.  No
>>>     additional DHCP server state should be required to implement
>>>     this option.
>>>  2. I agree that we could be a bit more descriptive about what would
>>>     happen if a reboot of the DHCP server.  I also like your idea
>>>     about mentioning the lease time to the MUD controller.  With
>>>     that in mind, how about the following text:
>>>
>>>
>>> With that in mind, I propose the following edit:
>>>
>>> DHCP servers may implement MUD functionality themselves or they may
>>> pass along appropriate information to a network management system or
>>> MUD controller.  A DHCP server that does process the MUD URL MUST adhere
>>> to the process specified in {{RFC2818}} and {{RFC5280}} to validate
>>> the TLS certificate of the web server hosting the MUD file. Those
>>> servers will retrieve the file, process it, create and install the
>>> necessary configuration on the relevant network element. Servers
>>> SHOULD monitor the gateway for state changes on a given interface.  A
>>> DHCP server that does not provide MUD functionality and has forwarded
>>> a MUD URL to a MUD controller MUST notify the MUD controller
>>> of any corresponding change to the DHCP state of the client
>>> (such as expiration or explicit release of a network address lease).
>>>
>>> Should the DHCP server fail, in the case when it implements the MUD
>>> controller functionality, any backup mechanisms SHOULD include the MUD
>>> state, and the server SHOULD resolve the status of clients upon its
>>> restart, similar to what it would do, absent MUD controller
>>> functionality.  In the case where the DHCP server forwards information
>>> to the MUD controller, the MUD controller will either make use of
>>> redundant DHCP servers for information, or otherwise clear state based
>>> on other network information, such as monitoring port status on a
>>> switch via SNMP, Radius accounting, or similar mechanisms.
>>>
>>>
>> wfm - thanks
>>>>   
>>>> Nits:
>>>>
>>>> There is tension between the paragraph in the introduction that characterizes
>>>> the manufacturer as the entity that provides the mud file and the third bullet
>>>> in the intent list about speeding vulnerability resolution for devices that
>>>> are no longer supported by the manufacturer (you intend here that someone other
>>>> than the original manufacturer or integrator is providing a new mud file).
>>>
>>> Perhaps this is best fixed by dropping the phrase "by the manufacturer"?
>> ok
>>>
>>>> Instead of "A light bulb is intended to light a room.", I suggest
>>>> "A light bulb is intended to light a given space." (There are lightbulbs
>>>> meant for outdoor use, and others for only inside cabinets or appliances.)
>>>
>>> Ok.
>>>
>>>> Instead of "We make use of YANG because of the time and effort spent to develop
>>>> accurate..." I suggest "We make use of YANG because it provides accurate..."
>>>
>>> Ok.
>>>> At the end of section 1.7, instead of "For these reasons only a limited subset
>>>> YANG-based configuration is permitted in a MUD file.", I suggest "For these
>>>> reasons, the YANG-based configuration in a MUD file is limited to the YANG
>>>> modules defined in this document." or something similar.
>>> s/defined/specified/ but otherwise ok.
>
> Just one clarification- this text needed to be wordsmithed a little 
> bit more.  Keep in mind that the ACL model is supported as discussed 
> in the draft.
ack
>
>>>
>>>> In section 3.6, the parenthesized clause does not belong in the sentence in
>>>> which it currently appears. I suggest it belongs somewhere in the previous
>>>> sentence.
>>>
>>> I've removed it and rewritten as follows:
>>>
>>> The intent is for administrators to be able to see a
>>> brief displayable description of the Thing.
>> ok
>>>
>>>> In section 3.13 you talk about classes that are standardized. Where does
>>>> someone find out about standardized classes?
>>>
>>> They're described in the document
>> Ah. maybe in 3.13 you could say "classes standardized by this 
>> document or future RFCs"?
>
> Ahh!  ok.  I see the confusion.  I think an example may be appropriate 
> here (we are literally getting a lot of operational experience with 
> this day by day now).
>
> Suppose you have a manufacturer X who has products P, D, and Q. They 
> each want to talk to the same controller or group of controllers.  Use 
> of "my-controller" may invoke a process on a MUD controller that 
> requires that the administrator populate the class for each device P, 
> D, and Q.  Whereas with use of a controller class, the administrator 
> only has to populate the class once.
>
> Similarly, the use of the word standardized naked like that is 
> probably unhelpful.
Can I infer you plan to edit it out or dress it more?
> One could imagine, for instance, Fairhair or some other consortium 
> deciding to create standard classes.
>
> What I propose is two changes to facilitate better understanding:
>
>  1. To include the simple example described above.
>  2. To add an optional "documentation"  element in the "mud" container
>     that consists of a URL that points to documents for each class,
>     when so used.
>
Sure.
>
> Thoughts?
>
With this, I'm puzzled about the use of the word standardized at all. I 
think I'm hearing that you expect MUD controllers to know about some 
well-known classes by convention and that groups like fairhair or 
someone else might make a list of classes that MUD controllers might 
collectively decide to build in knowledge of. Am I getting closer to the 
right picture? (This is opposed to a set of classes that are created by 
a standards action and listed in a registry somewhere).

> Eliot
>


--------------87FFFB5EAC24100EA92FF58C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 4/11/18 1:35 AM, Eliot Lear wrote:

    

    

      
      
Hi Robert,

      
A few additional comments below:

      

      

      
On 10.04.18 16:22, Robert Sparks
        wrote:

      

      

        
        


        

        

        
On 4/10/18 5:43 AM, Eliot Lear
          wrote:

        

        

          
Hi Robert and thanks again for the review.  Please see
            below for responses.  These are my personal views.  The WG
            chairs / shepherds may have different opinions.

          

        

        Thank you for the very quick response!

        

          
 

          

          
On 09.04.18 19:57, Robert Sparks
            wrote:

          

          

            
Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-20
Reviewer: Robert Sparks
Review Date: 2018-04-09
IETF LC End Date: 2017-11-07
IESG Telechat date: 2018-04-19

Summary: Almost ready but with minor issues to address before publication as a
standards track RFC 

Minor issues:

Section 3.15 is confused, and I don't think you'll get the implementation you
intend with the MUST in the current language. direction-indicated is not a
flag. The text about dropping should talk about matching the direction that was
indicated.

          

          

          Having reread this section (and perhaps I am a bit too close
          to the text), perhaps it is a bit confused.  How about
          something along the following lines:

          

          3.15.  direction-initiated

          

             When applied this matches the direction in which a TCP
          connection is

             initiated.  When direction initiated is "from-device",
          packets that are

             transmitted in the direction of a thing MUST be dropped
          unless the thing

             has first initiated a TCP connection.  This node may be
          implemented in

             its simplest form by looking at naked SYN bits, but may
          also be implemented

             through more stateful mechanisms.

            

            [RFC6092] specifies IPv6 guidance best

             practices.  While that document is scoped specifically to
          IPv6, its

             contents are applicable for IPv4 as well.  

          

          

          Better?

        

        wfm

        
 

          

            
The quoted issues below are from my early review of -08. I don't think they've
been addressed or responded to. Apologies if I missed a response.



            

              
The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.


            

            

              
I think there needs to be more discussion of the PKI used for signing MUD
files.


            

            
 

          

          

          While this section is admittedly a bit vague, we need some
          operational experience to develop the appropriate use of PKI
          as an anchor for reputations.  This having been said, if you
          have a specific proposal for text, I'd be interested in what
          you have to say.

        

        Do you envision enterprises or manufacturers creating a new set
        of anchors of trust, or are you hoping to reuse the web PKI or
        something else? If you don't know and all of these are on the
        table, mentioning it would help implementers avoid assumptions
        that could hinder deployment.

      

      

      Thanks for the guidance.   In fact I think we need to more clearly
      specify the signature in terms of the purpose.  The tools
      (openssl) support S/MIME signing easily enough for CMS.  I think
      this is what we want, and it implies that we are not using
      the webpki, but instead just getting an S/MIME certificate.  This
      implies that the signers will have to be "admitted" on first
      sight.  Would that work for you?

    

    Sure

    
 

      Also see below.

      

      

      

        
 

          

            

              
Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being 
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

            

          

          

          We did indeed add some text about this, almost verbatim to
          what you have above (I think at your suggestion).  This can be
          found in the introduction toward the bottom of page 9.

        

        I'm not seeing it in -20. Maybe its in your working copy but not
        issued yet, or 9 above isn't where you meant to point? I did a
        quick search for DHCP through the document and didn't spot the
        discussion. Apologies if I'm just missing it.

      

      

      Actually it's in two places.  See where we say in Section 1.5:

      

         It is possible that there may be other means for a MUD URL to
      be

         learned by a network.  For instance, some devices may already
      be

         fielded or have very limited ability to communicate a MUD URL,
      and

         yet can be identified through some means, such as a serial
      number or

         a public key.  In these cases, manufacturers may be able to map
      those

         identifiers to particular MUD URLs (or even the files
      themselves).

         Similarly, there may be alternative resolution mechanisms
      available

         for situations where Internet connectivity is limited or does
      not

         exist.  Such mechanisms are not described in this memo, but are

         possible.  Implementors should allow for this sort of
      flexibility of

         how MUD URLs may be learned.

      

      Elsewhere we say:

      

         If a MUD controller is not able to fetch a MUD URL, other means
      MAY

         be used to import MUD files and associated signature files.  So
      long

         as the signature of the file can be validated, the file can be
      used.

         In such environments, controllers SHOULD warn administrators
      when

         cache-validity expiry is approaching so that they may check for
      new

         files.

      

      So I'm hoping between the two we have you covered ;-).

    

    Yes, I'll let this point go. You have well covered discussing
    controllers being able to map things to MUD URLs. You still don't
    explicitly discuss whether existing libraries would let things
    provide the URL in DHCP - that's what I was scanning for. But again,
    I'll let it go.

    
 

      More below.

      

      
 

        

          

            
 

            
 


            

              
You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.

            

          

          

          I propose to delete that paragraph to match that we do not
          wish DHCP servers to modify their state.  This would address
          your concern (also see below).

        

        ack

        
 

          

            
 

            
 


            

              
The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration
of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off. 

            

          

          

          The example you are talking about is a subset of what happens
          if the file simply doesn't exist.  At worst, one is left in a
          situation no worse than we are today: that is, someone will
          have to manually decide policy, or apply a default policy. 
          This particular text is the subject of separate piece of work
          that Thorsten Dahm and Steve Rich are considering, and it is
          also the subject of some ongoing research.  That is to say: we
          might be able to do better in the future when we have some
          operational experience.

        

        OK. I suppose the detail I was hoping to see was some insight
        into recovery (how my hypothetical company above could start
        providing new MUD files that the existing devices would be
        convinced to use). I'll accept that is "future work".

      

      

      Ok,

      

        
 

          

          

            
 

            
 


            

              
Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

            

          

          

          Ok, two issues:

          
    
            
  1. There was some text that should have been removed,
              referring to the DHCP server returning the MUD-URL as part
              of state.  With everyone's permission, I propose to remove
              that text.  No additional DHCP server state should be
              required to implement this option.
    2. 
            
  2. I agree that we could be a bit more descriptive about
              what would happen if a reboot of the DHCP server.  I also
              like your idea about mentioning the lease time to the MUD
              controller.  With that in mind, how about the following
              text:
    3. 
          

          


          

          
With that in mind, I propose the following edit:

          
DHCP servers may implement MUD functionality themselves or
            they may

            pass along appropriate information to a network management
            system or

            MUD controller.  A DHCP server that does process the MUD URL
            MUST adhere

            to the process specified in {{RFC2818}} and {{RFC5280}} to
            validate

            the TLS certificate of the web server hosting the MUD file. 
            Those

            servers will retrieve the file, process it, create and
            install the

            necessary configuration on the relevant network element. 
            Servers

            SHOULD monitor the gateway for state changes on a given
            interface.  A

            DHCP server that does not provide MUD functionality and has
            forwarded

            a MUD URL to a MUD controller MUST notify the MUD controller

            of any corresponding change to the DHCP state of the client

            (such as expiration or explicit release of a network address
            lease).

            

            Should the DHCP server fail, in the case when it implements
            the MUD

            controller functionality, any backup mechanisms SHOULD
            include the MUD

            state, and the server SHOULD resolve the status of clients
            upon its

            restart, similar to what it would do, absent MUD controller

            functionality.  In the case where the DHCP server forwards
            information

            to the MUD controller, the MUD controller will either make
            use of

            redundant DHCP servers for information, or otherwise clear
            state based

            on other network information, such as monitoring port status
            on a

            switch via SNMP, Radius accounting, or similar mechanisms.

          

          

        

        wfm - thanks

        

          

            
 

            
 
Nits:

There is tension between the paragraph in the introduction that characterizes
the manufacturer as the entity that provides the mud file and the third bullet
in the intent list about speeding vulnerability resolution for devices that
are no longer supported by the manufacturer (you intend here that someone other
than the original manufacturer or integrator is providing a new mud file).

          

          

          Perhaps this is best fixed by dropping the phrase "by the
          manufacturer"?

        

        ok

        
 

          

            
Instead of "A light bulb is intended to light a room.", I suggest 
"A light bulb is intended to light a given space." (There are lightbulbs
meant for outdoor use, and others for only inside cabinets or appliances.)

          

          

          Ok.

          

          

            
Instead of "We make use of YANG because of the time and effort spent to develop
accurate..." I suggest "We make use of YANG because it provides accurate..."

          

          

          Ok.

          

            
At the end of section 1.7, instead of "For these reasons only a limited subset
YANG-based configuration is permitted in a MUD file.", I suggest "For these
reasons, the YANG-based configuration in a MUD file is limited to the YANG
modules defined in this document." or something similar.

          

          s/defined/specified/ but otherwise ok.

        

      

      

      Just one clarification- this text needed to be wordsmithed a
      little bit more.  Keep in mind that the ACL model is supported as
      discussed in the draft.

    

    ack

    
 

      

        
 

          

            
In section 3.6, the parenthesized clause does not belong in the sentence in 
which it currently appears. I suggest it belongs somewhere in the previous
sentence.

          

          

          I've removed it and rewritten as follows:

          

          The intent is for administrators to be able to see a

          brief displayable description of the Thing. 

        

        ok

        
 

          

            
In section 3.13 you talk about classes that are standardized. Where does 
someone find out about standardized classes?

          

          

          They're described in the document

        

        Ah. maybe in 3.13 you could say "classes standardized by this
        document or future RFCs"?

      

      

      Ahh!  ok.  I see the confusion.  I think an example may be
      appropriate here (we are literally getting a lot of operational
      experience with this day by day now).

      

      Suppose you have a manufacturer X who has products P, D, and Q. 
      They each want to talk to the same controller or group of
      controllers.  Use of "my-controller" may invoke a process on a MUD
      controller that requires that the administrator populate the class
      for each device P, D, and Q.  Whereas with use of a controller
      class, the administrator only has to populate the class once.

      

      Similarly, the use of the word standardized naked like that is
      probably unhelpful. 

    

    Can I infer you plan to edit it out or dress it more? 

    
 One
      could imagine, for instance, Fairhair or some other consortium
      deciding to create standard classes.

      

      What I propose is two changes to facilitate better understanding:

      
    
        
  1. To include the simple example described above.
    2. 
        
  2. To add an optional "documentation"  element in the "mud"
          container that consists of a URL that points to documents for
          each class, when so used.
    3. 
      

    

    Sure.

    

      
    
      

      
Thoughts?

      

    

    With this, I'm puzzled about the use of the word standardized at
    all. I think I'm hearing that you expect MUD controllers to know
    about some well-known classes by convention and that groups like
    fairhair or someone else might make a list of classes that MUD
    controllers might collectively decide to build in knowledge of. Am I
    getting closer to the right picture? (This is opposed to a set of
    classes that are created by a standards action and listed in a
    registry somewhere).

    

    

      
 

      
Eliot

      

    

    

  


--------------87FFFB5EAC24100EA92FF58C--


From nobody Wed Apr 11 09:58:46 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0C126C25; Wed, 11 Apr 2018 09:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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
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 T4ySsQ947Jg1; Wed, 11 Apr 2018 09:58:26 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431C3127241; Wed, 11 Apr 2018 09:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4493; q=dns/txt; s=iport; t=1523465905; x=1524675505; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=tjVPw1SPDk4iWD+WgHbkU8Fj10agXC8OkDVXW21vD3U=; b=MZMEZ4MalxBB4x6ndKhn58qiGXQdZvQuDkyVgFHWsZvaVhgTw47QPquD s2ZgMh/5zgZsS8Qcf6Ark08dedCDDDTzGbvJ2JMXlz6sY9PaLCmwiaxPc CLG/PPL9tKk43F+t6uRWffjDN6XLcYZ/bIkyjfXjnalehr2Ytxht5HGkt 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAQA3Ps5a/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgxOBf4QKiAFejX8IIYEPjXqEZ4F6C4UDAoJxNBgBAgE?= =?us-ascii?q?BAQEBAQJsL4UiAQEBAQIBI1YQCwQKCioCAlcGAQwIAQGFAQiKYpxoghwfiCa?= =?us-ascii?q?CH4oDgS4MglaHb4JUAowChFyGfgiOMQaHRIUAkA+BJRw4gVIzGggbFTqCRJB?= =?us-ascii?q?PPY8xAQE?=
X-IronPort-AV: E=Sophos;i="5.48,437,1517875200"; d="scan'208,217";a="3086842"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2018 16:58:06 +0000
Received: from [10.61.76.70] (ams3-vpn-dhcp3142.cisco.com [10.61.76.70]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3BGw5IW012490; Wed, 11 Apr 2018 16:58:06 GMT
To: Robert Sparks , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>   <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <217a3f98-5c2e-0ade-1765-eb226fa5cd72@cisco.com>
Date: Wed, 11 Apr 2018 18:58:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com>
Content-Type: multipart/alternative; boundary="------------735B8FF4C6558ED42DC60CFE"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 16:58:28 -0000

This is a multi-part message in MIME format.
--------------735B8FF4C6558ED42DC60CFE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

All the way down...


On 11.04.18 18:15, Robert Sparks wrote:
>
>>
>> Similarly, the use of the word standardized naked like that is
>> probably unhelpful.
> Can I infer you plan to edit it out or dress it more?

Yes.

>> One could imagine, for instance, Fairhair or some other consortium
>> deciding to create standard classes.
>>
>> What I propose is two changes to facilitate better understanding:
>>
>>  1. To include the simple example described above.
>>  2. To add an optional "documentation"  element in the "mud"
>>     container that consists of a URL that points to documents for
>>     each class, when so used.
>>
> Sure.
>>
>> Thoughts?
>>
> With this, I'm puzzled about the use of the word standardized at all.
> I think I'm hearing that you expect MUD controllers to know about some
> well-known classes by convention and that groups like fairhair or
> someone else might make a list of classes that MUD controllers might
> collectively decide to build in knowledge of. Am I getting closer to
> the right picture? (This is opposed to a set of classes that are
> created by a standards action and listed in a registry somewhere).

The class is just a name that expands out to a bunch of IP addresses. 
It happens to take the form of a URI, but it's really just a name. 
There could be well known NAMES, and indeed we create a URN registry
just for that purpose.  Maybe I need to be a bit more clearer on that point?

Eliot

--------------735B8FF4C6558ED42DC60CFE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
All the way down...

    

    

    
On 11.04.18 18:15, Robert Sparks wrote:

    

    

      
      

      
 

        Similarly, the use of the word standardized naked like that is
        probably unhelpful. 

      

      Can I infer you plan to edit it out or dress it more? 

    

    

    Yes.

    

    

      
 One
        could imagine, for instance, Fairhair or some other consortium
        deciding to create standard classes.

        

        What I propose is two changes to facilitate better
        understanding:

        
    
          
  1. To include the simple example described above.
    2. 
          
  2. To add an optional "documentation"  element in the "mud"
            container that consists of a URL that points to documents
            for each class, when so used.
    3. 
        

      

      Sure.

      

        
    
        

        
Thoughts?

        

      

      With this, I'm puzzled about the use of the word standardized at
      all. I think I'm hearing that you expect MUD controllers to know
      about some well-known classes by convention and that groups like
      fairhair or someone else might make a list of classes that MUD
      controllers might collectively decide to build in knowledge of. Am
      I getting closer to the right picture? (This is opposed to a set
      of classes that are created by a standards action and listed in a
      registry somewhere).

    

    

    The class is just a name that expands out to a bunch of IP
    addresses.  It happens to take the form of a URI, but it's really
    just a name.  There could be well known NAMES, and indeed we create
    a URN registry just for that purpose.  Maybe I need to be a bit more
    clearer on that point?

    

    Eliot

  


--------------735B8FF4C6558ED42DC60CFE--


From nobody Wed Apr 11 11:21:57 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43640126CD8; Wed, 11 Apr 2018 11:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 ESYQ0-UJDBkL; Wed, 11 Apr 2018 11:21:47 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F7D126C89; Wed, 11 Apr 2018 11:21:47 -0700 (PDT)
Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BILi5P005403 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 13:21:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local
To: Eliot Lear , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>   <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com> <217a3f98-5c2e-0ade-1765-eb226fa5cd72@cisco.com>
From: Robert Sparks 
Message-ID: 
Date: Wed, 11 Apr 2018 13:21:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <217a3f98-5c2e-0ade-1765-eb226fa5cd72@cisco.com>
Content-Type: multipart/alternative; boundary="------------18C9CE2CB4E0657B76C4FE5F"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 18:21:49 -0000

This is a multi-part message in MIME format.
--------------18C9CE2CB4E0657B76C4FE5F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 4/11/18 11:58 AM, Eliot Lear wrote:
>
> All the way down...
>
>
> On 11.04.18 18:15, Robert Sparks wrote:
>>
>>>
>>> Similarly, the use of the word standardized naked like that is 
>>> probably unhelpful.
>> Can I infer you plan to edit it out or dress it more?
>
> Yes.
>
>>> One could imagine, for instance, Fairhair or some other consortium 
>>> deciding to create standard classes.
>>>
>>> What I propose is two changes to facilitate better understanding:
>>>
>>>  1. To include the simple example described above.
>>>  2. To add an optional "documentation"  element in the "mud"
>>>     container that consists of a URL that points to documents for
>>>     each class, when so used.
>>>
>> Sure.
>>>
>>> Thoughts?
>>>
>> With this, I'm puzzled about the use of the word standardized at all. 
>> I think I'm hearing that you expect MUD controllers to know about 
>> some well-known classes by convention and that groups like fairhair 
>> or someone else might make a list of classes that MUD controllers 
>> might collectively decide to build in knowledge of. Am I getting 
>> closer to the right picture? (This is opposed to a set of classes 
>> that are created by a standards action and listed in a registry 
>> somewhere).
>
> The class is just a name that expands out to a bunch of IP addresses.  
> It happens to take the form of a URI, but it's really just a name.  
> There could be well known NAMES, and indeed we create a URN registry 
> just for that purpose.  Maybe I need to be a bit more clearer on that 
> point?
Probably good to do? I hope I'm not just being too thick-headed here.
>
> Eliot


--------------18C9CE2CB4E0657B76C4FE5F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 4/11/18 11:58 AM, Eliot Lear wrote:

    

    

      
      
All the way down...

      

      

      
On 11.04.18 18:15, Robert Sparks
        wrote:

      

      

        
        

        
 

          Similarly, the use of the word standardized naked like that is
          probably unhelpful. 

        

        Can I infer you plan to edit it out or dress it more? 

      

      

      Yes.

      

      

        
 One
          could imagine, for instance, Fairhair or some other consortium
          deciding to create standard classes.

          

          What I propose is two changes to facilitate better
          understanding:

          
    
            
  1. To include the simple example described above.
    2. 
            
  2. To add an optional "documentation"  element in the "mud"
              container that consists of a URL that points to documents
              for each class, when so used.
    3. 
          

        

        Sure.

        

          
    
          

          
Thoughts?

          

        

        With this, I'm puzzled about the use of the word standardized at
        all. I think I'm hearing that you expect MUD controllers to know
        about some well-known classes by convention and that groups like
        fairhair or someone else might make a list of classes that MUD
        controllers might collectively decide to build in knowledge of.
        Am I getting closer to the right picture? (This is opposed to a
        set of classes that are created by a standards action and listed
        in a registry somewhere).

      

      

      The class is just a name that expands out to a bunch of IP
      addresses.  It happens to take the form of a URI, but it's really
      just a name.  There could be well known NAMES, and indeed we
      create a URN registry just for that purpose.  Maybe I need to be a
      bit more clearer on that point?

    

    Probably good to do? I hope I'm not just being too thick-headed
    here.

    
 

      Eliot

    

    

  


--------------18C9CE2CB4E0657B76C4FE5F--


From nobody Thu Apr 12 05:17:37 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC10126E01; Thu, 12 Apr 2018 05:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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
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 XuQpaId8hnZ2; Thu, 12 Apr 2018 05:17:19 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80D9126C19; Thu, 12 Apr 2018 05:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1523535439; x=1524745039; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=qZgl7We38J+4DwMxKha60NWxRgXj28TQB2TsUo5cOwA=; b=USMdnC/pykgCQrgQ2UyUsZJTlD+SZWVPdDQQ008iz/UQwWUsrNXLoVlc USb/x2Dm/4l+HaLgpog1n7a6iabTsirHjsHNq1+5LtV+7AOJyHYYdgNA/ qhnEvum3WNB0YwUTSHs+lqhh8wDfX6XzGSIeoFriPlofVWU6OzPpWl+LI Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATBAA7Tc9a/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgxOBf4QLiGCOBCGBD418hmILhQMCgkA3FQECAQEBAQE?= =?us-ascii?q?BAmwohSMBBSNWEAsECgoqAgJXBgEMCAEBhQmKdJxnghwfiCGCL4oQgTIMgly?= =?us-ascii?q?Hc4JUApddCI4xBodEhQCQEoElMiKBUjMaCBsVOoJEghqONT2PMQEB?=
X-IronPort-AV: E=Sophos;i="5.48,441,1517875200"; d="scan'208,217";a="3149444"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 12:17:17 +0000
Received: from [10.61.232.123] ([10.61.232.123]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3CCHGSc015597; Thu, 12 Apr 2018 12:17:16 GMT
To: Robert Sparks , gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>   <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <0ddeece0-f47a-9582-c875-da09d9762d5d@cisco.com>
Date: Thu, 12 Apr 2018 14:17:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com>
Content-Type: multipart/alternative; boundary="------------597152BDA236C7FC6C5628D2"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 12:17:21 -0000

This is a multi-part message in MIME format.
--------------597152BDA236C7FC6C5628D2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi Robert and everyone else,

Circling for a landing here...


On 11.04.18 18:15, Robert Sparks wrote:
> With this, I'm puzzled about the use of the word standardized at all.
> I think I'm hearing that you expect MUD controllers to know about some
> well-known classes by convention and that groups like fairhair or
> someone else might make a list of classes that MUD controllers might
> collectively decide to build in knowledge of. Am I getting closer to
> the right picture? (This is opposed to a set of classes that are
> created by a standards action and listed in a registry somewhere).

I've attempted to clarify this language as we discussed.  On the point
of standardization, I've made a clean separation:

  * URNs: standardized (and therefore hopefully well documented)
    behaviors, such as DNS and NTP.
  * URIs that take the form of URLs.  These are just class names that
    the administrator has to fill out, or are otherwise somehow
    pre-populated.

I hope that this resolves any lingering confusion.

Thanks again for working to improve this document.  I really appreciate it!

Eliot


--------------597152BDA236C7FC6C5628D2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Robert and everyone else,

    
Circling for a landing here...

    

    

    
On 11.04.18 18:15, Robert Sparks wrote:

    

    

      
      With this, I'm puzzled about the use of the word standardized at
      all. I think I'm hearing that you expect MUD controllers to know
      about some well-known classes by convention and that groups like
      fairhair or someone else might make a list of classes that MUD
      controllers might collectively decide to build in knowledge of. Am
      I getting closer to the right picture? (This is opposed to a set
      of classes that are created by a standards action and listed in a
      registry somewhere).

    

    

    I've attempted to clarify this language as we discussed.  On the
    point of standardization, I've made a clean separation:

    
    
      
  • URNs: standardized (and therefore hopefully well documented)
        behaviors, such as DNS and NTP.
    • 
      
  • URIs that take the form of URLs.  These are just class names
        that the administrator has to fill out, or are otherwise somehow
        pre-populated.
    • 
    

    
I hope that this resolves any lingering confusion.

    
Thanks again for working to improve this document.  I really
      appreciate it!

    
Eliot

    

  


--------------597152BDA236C7FC6C5628D2--


From nobody Fri Apr 13 07:44:45 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB25126CC7; Fri, 13 Apr 2018 07:44:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern 
To: 
Cc: draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org, ietf@ietf.org, opsawg@ietf.org, gen-art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
Date: Fri, 13 Apr 2018 07:44:28 -0700
Archived-At: 
Subject: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2018 14:44:29 -0000

Reviewer: Joel Halpern
Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still
have serious problems with this work.

The primary problem is that this seems to violate the designed work
distribution in the IPFIX architecture.  The draft itself notes that the
correlation requested could be done in the collector.  Which is where
correlation is designed to be done.  Instead, it puts a significant new
processing load on the router that is delivering the IPFIX information.  For
example, if one delivers IPFIX from the router data plane, one either has to
modify the router architecture to include additional complex computed
information in the data plane architecture (a bad place to add complexity) or
one has to give up and move all the information through the control plane.  And
even the control plane likely has to add complexity to its RIB logic, as it has
to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the router
by the claim that the unusual usage of applying community tags for geographical
location of customers is a common practice.  It is a legal practice.  And I
presume it is done somewhere or the authors would not be asking for it.   But
it is not common.

In short, since even the draft admits that this is not needed, I recommend
against publishing this document as an RFC.


From nobody Sat Apr 14 22:58:48 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0F1241F8; Sat, 14 Apr 2018 22:58:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152377192081.19876.1408016458351314486@ietfa.amsl.com>
Date: Sat, 14 Apr 2018 22:58:40 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 05:58:41 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : The TACACS+ Protocol
        Authors         : Thorsten Dahm
                          Andrej Ota
                          Douglas C. Medway Gash
                          David Carrel
                          Lol Grant
	Filename        : draft-ietf-opsawg-tacacs-10.txt
	Pages           : 43
	Date            : 2018-04-14

Abstract:
   TACACS+ provides Device Administration for routers, network access
   servers and other networked computing devices via one or more
   centralized servers.  This document describes the protocol that is
   used by TACACS+.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-10
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Apr 14 23:28:01 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C21241F8; Sat, 14 Apr 2018 23:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 wSlEDeXqCj7d; Sat, 14 Apr 2018 23:27:57 -0700 (PDT)
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 518FE124239; Sat, 14 Apr 2018 23:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15132; q=dns/txt; s=iport; t=1523773677; x=1524983277; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lVIQPqtMPnnIDI7qto6XJglEadtAMcVxo2pb9SOmjxw=; b=Y5Y/6DPjsPXBK1GfKqCgwjAPGHWertFPyN8Gc8MYwZMsKLSlcnX0EtrK 7SjcxJTjxdIazm5nSuwuUvdRRH0ntFSNoUh5AVUeTYTZWgICnQKgtnZmt 5aVaUOF8TGXmGsJHXmTZqJfL3kLPi6esKrGRqAJgyw8yLTg0lACOOSJA+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AwD279Ja/5tdJa1TAwYcAQEBBAE?= =?us-ascii?q?BCgEBgxMvgVsyg1yIAo0RgVOBFhqSaBSBZwuFAwIaghMhNBgBAgEBAQEBAQJ?= =?us-ascii?q?sHQuFIwMDIxETJQoBAhACAQgaAhQSAgICMBUQAgQOIIRypQuCHIMihRmCL4E?= =?us-ascii?q?JhFWBBYEGHYITgQ8jDIFdSjWENxIEEAgOToIyMIIkAocQiVGHAwgCjjmMS49?= =?us-ascii?q?4AhETAYEkARw4gVJwFTsqAYIZghoFARaOFgGNJyOBCoEXAQE?=
X-IronPort-AV: E=Sophos;i="5.48,453,1517875200"; d="scan'208";a="381177627"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2018 06:27:56 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3F6RuRj020871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Apr 2018 06:27:56 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 15 Apr 2018 01:27:55 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Sun, 15 Apr 2018 01:27:55 -0500
From: "Douglas Gash (dcmgash)" 
To: "opsawg@ietf.org" 
CC: Andrej Ota , Thorsten Dahm , "internet-drafts@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-opsawg-tacacs-10.txt
Thread-Index: AQHT1H7Q2+J+Xp+Us0+DREWATIPIOqQBsJiA
Date: Sun, 15 Apr 2018 06:27:55 +0000
Message-ID: <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com>
In-Reply-To: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.229.132.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 06:28:00 -0000

SGVsbG8gT3BzYXdnLA0KDQpXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIFRB
Q0FDUysgaW5mb3JtYXRpb25hbCBkcmFmdCB3aGljaCBpbmNsdWRlcyBjb3JyZWN0aW9ucyBmb3Ig
dHlwb3Mgb3ZlciB0aGUgZG9jdW1lbnQgYXMgYSB3aG9sZSwgYnV0IGFsc28gcmV2aXNlZCB0aGUg
c2VjdXJpdHkgc2VjdGlvbi4gV2UgYW50aWNpcGF0ZSB0aGlzIHNlY3VyaXR5IHNlY3Rpb24gd2ls
bCBnZXQgbW9zdCBjb21tZW50cywgc28gaXQgaXMgcmVwcm9kdWNlZCBiZWxvdy4NCg0KV2Ugd2ls
bCBlbmRlYXZvciB0byBiZSBtdWNoIG1vcmUgcmVhY3RpdmUgdG8gY29tbWVudHMsIHdoZXRoZXIg
b24gc2VjdGlvbiBiZWxvdywgb3IgYW55IG90aGVyIGluIHJlc3Qgb2YgdXBsb2FkZWQgZG9jdW1l
bnQuDQoNCk1hbnkgdGhhbmtzLA0KDQpUaGUgYXV0aG9ycy4NCg0KDQoNCjkuICBUQUNBQ1MrIFNl
Y3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBvcmlnaW5hbCBUQUNBQ1MrIERyYWZ0WzFd
IGZyb20gMTk5OCBkaWQgbm90IGFkZHJlc3MgYWxsIG9mIHRoZQ0KICAga2V5IHNlY3VyaXR5IGNv
bmNlcm5zIHdoaWNoIGFyZSBjb25zaWRlcmVkIHdoZW4gZGVzaWduaW5nIG1vZGVybg0KICAgc3Rh
bmRhcmRzLiAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBrbm93biBsaW1pdGF0aW9ucyBhbmQgY29u
Y2VybnMNCiAgIHdoaWNoIHdpbGwgaW1wYWN0IG92ZXJhbGwgc2VjdXJpdHkgb2YgdGhlIHByb3Rv
Y29sIGFuZCBzeXN0ZW1zIHdoZXJlDQogICB0aGlzIHByb3RvY29sIGlzIGRlcGxveWVkIHRvIG1h
bmFnZSBjZW50cmFsIGF1dGhlbnRpY2F0aW9uLA0KICAgYXV0aG9yaXphdGlvbiBvciBhY2NvdW50
aW5nIGZvciBuZXR3b3JrIGRldmljZSBhZG1pbmlzdHJhdGlvbi4NCg0KICAgTXVsdGlwbGUgaW1w
bGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbCBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0WzFdDQog
ICBoYXZlIGJlZW4gZGVwbG95ZWQuICBBcyB0aGUgcHJvdG9jb2wgd2FzIG5ldmVyIHN0YW5kYXJk
aXplZCwgY3VycmVudA0KICAgaW1wbGVtZW50YXRpb25zIG1heSBiZSBpbmNvbXBhdGlibGUgaW4g
bm9uLW9idmlvdXMgd2F5cywgZ2l2aW5nIHJpc2UNCiAgIHRvIGFkZGl0aW9uYWwgc2VjdXJpdHkg
cmlza3MuICBUaGlzIHNlY3Rpb24gZG9lcyBub3QgY2xhaW0gdG8NCiAgIGVudW1lcmF0ZSBhbGwg
cG9zc2libGUgc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVzLg0KDQo5LjEuICBHZW5lcmFsIFNlY3Vy
aXR5IG9mIFRoZSBQcm90b2NvbA0KDQogICBUQUNBQ1MrIHByb3RvY29sIGRvZXMgbm90IGluY2x1
ZGUgYSBzZWN1cml0eSBtZWNoYW5pc20gdGhhdCB3b3VsZA0KICAgbWVldCBtb2Rlcm4tZGF5IHJl
cXVpcmVtZW50cy4gIFN1cHBvcnQgZm9yIE1ENS1iYXNlZCBjcnlwdG8gcGFkDQogICBlbmNyeXB0
aW9uIGZhaWxzIHRvIHByb3ZpZGUgYW55IGtpbmQgb2YgdHJhbnNwb3J0IGludGVncml0eSwgd2hp
Y2gNCiAgIHByZXNlbnRzIGF0IGxlYXN0IHRoZSBmb2xsb3dpbmcgcmlza3M6DQoNCiAgICAgIEFj
Y291bnRpbmcgaW5mb3JtYXRpb24gbWF5IGJlIG1vZGlmaWVkIGJ5IHRoZSBtYW4taW4tdGhlLW1p
ZGRsZQ0KICAgICAgYXR0YWNrZXIsIG1ha2luZyBzdWNoIGxvZ3MgdW5zdWl0YWJsZSBhbmQgdW50
cnVzdGFibGUgZm9yIGF1ZGl0aW5nDQogICAgICBwdXJwb3Nlcy4NCg0KICAgICAgT25seSB0aGUg
Ym9keSBvZiB0aGUgcmVxdWVzdCBpcyBlbmNyeXB0ZWQgd2hpY2ggbGVhdmVzIGFsbCBoZWFkZXIN
CiAgICAgIGZpZWxkcyBvcGVuIHRvIHRyaXZpYWwgbW9kaWZpY2F0aW9uIGJ5IHRoZSBtYW4taW4t
dGhlLW1pZGRsZQ0KICAgICAgYXR0YWNrZXIuICBGb3IgdGhpcyByZWFzb24sIGNvbm5lY3Rpb25z
IHdpdGgNCiAgICAgIFRBQ19QTFVTX1VORU5DUllQVEVEX0ZMQUcgYXJlIGRpc2FsbG93ZWQsIGFz
IG1lbnRpb25lZCBpbiB0aGUNCiAgICAgIHJlY29tbWVuZGF0aW9ucyBzZWN0aW9uLg0KDQogICAg
ICBJbnZhbGlkIG9yIG1pc2xlYWRpbmcgdmFsdWVzIG1heSBiZSBpbnNlcnRlZCBieSB0aGUgbWFu
LWluLXRoZS0NCiAgICAgIG1pZGRsZSBhdHRhY2tlciBpbiB2YXJpb3VzIGZpZWxkcyBhdCBrbm93
biBvZmZzZXRzIHRvIHRyeSBhbmQNCiAgICAgIGNpcmN1bXZlbnQgdGhlIGF1dGhlbnRpY2F0aW9u
IG9yIGF1dGhvcml6YXRpb24gY2hlY2tzIGV2ZW4gaW5zaWRlDQogICAgICB0aGUgZW5jcnlwdGVk
IGJvZHkuDQoNCiAgIFdoaWxlIHRoZSBwcm90b2NvbCBwcm92aWRlcyBzb21lIG1lYXN1cmUgb2Yg
dHJhbnNwb3J0IHByaXZhY3ksIGl0IGlzDQogICB2dWxuZXJhYmxlIHRvIGF0IGxlYXN0IHRoZSBm
b2xsb3dpbmcgYXR0YWNrczoNCg0KICAgICAgQnJ1dGUgZm9yY2UgYXR0YWNrcyBleHBsb2l0aW5n
IGluY3JlYXNlZCBlZmZpY2llbmN5IG9mIE1ENSBkaWdlc3QNCiAgICAgIGNvbXB1dGF0aW9uLg0K
DQogICAgICBLbm93biBwbGFpbnRleHQgYXR0YWNrcyB3aGljaCBtYXkgZGVjcmVhc2UgdGhlIGNv
c3Qgb2YgYnJ1dGUgZm9yY2UNCiAgICAgIGF0dGFjay4NCg0KICAgICAgQ2hvc2VuIHBsYWludGV4
dCBhdHRhY2tzIHdoaWNoIG1heSBkZWNyZWFzZSB0aGUgY29zdCBvZiBhIGJydXRlDQogICAgICBm
b3JjZSBhdHRhY2suDQoNCiAgICAgIE5vIGZvcndhcmQgc2VjcmVjeS4NCg0KICAgRXZlbiB0aG91
Z2gsIHRvIHRoZSBiZXN0IGtub3dsZWRnZSBvZiBhdXRob3JzLCB0aGlzIG1ldGhvZCBvZg0KICAg
ZW5jcnlwdGlvbiB3YXNuJ3Qgcmlnb3JvdXNseSB0ZXN0ZWQsIGVub3VnaCBpbmZvcm1hdGlvbiBp
cyBhdmFpbGFibGUNCiAgIHRoYXQgaXQgaXMgYmVzdCByZWZlcnJlZCB0byBhcyAib2JmdXNjYXRp
b24iIGFuZCBub3QgImVuY3J5cHRpb24iLg0KDQogICBGb3IgdGhlc2UgcmVhc29ucywgdXNlcnMg
ZGVwbG95aW5nIFRBQ0FDUysgcHJvdG9jb2wgaW4gdGhlaXINCiAgIGVudmlyb25tZW50cyBNVVNU
IGxpbWl0IGFjY2VzcyB0byBrbm93biBjbGllbnRzIGFuZCBNVVNUIGNvbnRyb2wgdGhlDQogICBz
ZWN1cml0eSBvZiB0aGUgZW50aXJlIHRyYW5zbWlzc2lvbiBwYXRoLiAgQXR0YWNrcyB3aG8gY2Fu
IGd1ZXNzIHRoZQ0KICAga2V5IG9yIG90aGVyd2lzZSBicmVhayB0aGUgb2JmdXNjYXRpb24gd2ls
bCBnYWluIHVucmVzdHJpY3RlZCBhbmQNCiAgIHVuZGV0ZWN0ZWQgYWNjZXNzIHRvIGFsbCBUQUNB
Q1MrIHRyYWZmaWMuICBFbnN1cmluZyB0aGF0IGENCiAgIGNlbnRyYWxpemVkIEFBQSBzeXN0ZW0g
bGlrZSBUQUNBQ1MrIGlzIGRlcGxveWVkIG9uIGEgc2VjdXJlZA0KICAgdHJhbnNwb3J0IGlzIGVz
c2VudGlhbCB0byBtYW5hZ2luZyBzZWN1cml0eSByaXNrIG9mIHN1Y2ggYW4gYXR0YWNrLg0KDQog
ICBUaGUgZm9sbG93aW5nIHBhcnRzIG9mIHRoaXMgc2VjdGlvbiBlbnVtZXJhdGUgb25seSB0aGUg
c2Vzc2lvbi0NCiAgIHNwZWNpZmljIHJpc2tzIHdoaWNoIGFyZSBpbiBhZGRpdGlvbiB0byBnZW5l
cmFsIHJpc2sgYXNzb2NpYXRlZCB3aXRoDQogICBiYXJlIG9iZnVzY2F0aW9uIGFuZCBsYWNrIG9m
IGludGVncml0eSBjaGVja2luZy4NCg0KOS4yLiAgU2VjdXJpdHkgb2YgQXV0aGVudGljYXRpb24g
U2Vzc2lvbnMNCg0KICAgQXV0aGVudGljYXRpb24gc2Vzc2lvbnMgU0hPVUxEIE5PVCBiZSB1c2Vk
IHZpYSBpbnNlY3VyZSB0cmFuc3BvcnQgYXMNCiAgIHRoZSBtYW4taW4tdGhlLW1pZGRsZSBhdHRh
Y2sgbWF5IGNvbXBsZXRlbHkgc3VidmVydCB0aGVtLiAgRXZlbiBDSEFQLA0KICAgd2hpY2ggbWF5
IGJlIGNvbnNpZGVyZWQgcmVzaXN0YW50IHRvIHBhc3N3b3JkIGludGVyY2VwdGlvbiwgaXMgdW5z
YWZlDQogICBhcyBpdCBkb2VzIG5vdCBwcm90ZWN0IHRoZSB1c2VybmFtZSBmcm9tIGEgdHJpdmlh
bCBtYW4taW4tdGhlLW1pZGRsZQ0KICAgYXR0YWNrLg0KDQogICBUaGlzIGRvY3VtZW50IGRlcHJl
Y2F0ZXMgdGhlIHJlZGlyZWN0aW9uIG1lY2hhbmlzbSB1c2luZyB0aGUNCiAgIFRBQ19QTFVTX0FV
VEhFTl9TVEFUVVNfRk9MTE9XIG9wdGlvbiB3aGljaCB3YXMgaW5jbHVkZWQgaW4gdGhlDQogICBv
cmlnaW5hbCBkcmFmdC4gIEFzIHBhcnQgb2YgdGhpcyBwcm9jZXNzLCB0aGUgc2VjcmV0IGtleSBm
b3IgYSBuZXcNCiAgIHNlcnZlciB3YXMgc2VudCB0byB0aGUgY2xpZW50LiAgVGhpcyBwdWJsaWMg
ZXhjaGFuZ2Ugb2Ygc2VjcmV0IGtleXMNCiAgIG1lYW5zIHRoYXQgb25jZSBvbmUgc2Vzc2lvbiBp
cyBicm9rZW4sIGl0IG1heSBiZSBwb3NzaWJsZSB0byBsZXZlcmFnZQ0KICAgdGhhdCBrZXkgdG8g
YXR0YWNraW5nIGNvbm5lY3Rpb25zIHRvIG90aGVyIHNlcnZlcnMuICBUaGlzIG1lY2hhbmlzbQ0K
ICAgU0hPVUxEIE5PVCBiZSB1c2VkIGluIG1vZGVybiBkZXBsb3ltZW50cy4gIEl0IE1VU1QgTk9U
IGJlIHVzZWQNCiAgIG91dHNpZGUgYSBzZWN1cmVkIGRlcGxveW1lbnQuDQoNCjkuMy4gIFNlY3Vy
aXR5IG9mIEF1dGhvcml6YXRpb24gU2Vzc2lvbnMNCg0KICAgQXV0aG9yaXphdGlvbiBzZXNzaW9u
cyBNVVNUIGJlIHVzZWQgdmlhIHNlY3VyZSB0cmFuc3BvcnQgb25seSBhcyBpdCdzDQogICB0cml2
aWFsIHRvIGV4ZWN1dGUgYSBzdWNjZXNzZnVsIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MgdGhh
dA0KICAgY2hhbmdlcyB3ZWxsLWtub3duIHBsYWludGV4dCBpbiBlaXRoZXIgcmVxdWVzdHMgb3Ig
cmVzcG9uc2VzLg0KDQogICBBcyBhbiBleGFtcGxlLCB0YWtlIHRoZSBmaWVsZCAiYXV0aGVuX21l
dGhvZCIuICBJdCdzIG5vdCB1bnVzdWFsIGluDQogICBhY3R1YWwgZGVwbG95bWVudHMgdG8gYXV0
aG9yaXplIGFsbCBjb21tYW5kcyByZWNlaXZlZCB2aWEgdGhlIGRldmljZQ0KICAgbG9jYWwgc2Vy
aWFsIHBvcnQgKGEgY29uc29sZSBwb3J0KSBhcyB0aGF0IG9uZSBpcyB1c3VhbGx5IGNvbnNpZGVy
ZWQNCiAgIHNlY3VyZSBieSB2aXJ0dWUgb2YgdGhlIGRldmljZSBsb2NhdGVkIGluIGEgcGh5c2lj
YWxseSBzZWN1cmUNCiAgIGxvY2F0aW9uLiAgSWYgYW4gYWRtaW5pc3RyYXRvciB3b3VsZCBjb25m
aWd1cmUgdGhlIGF1dGhvcml6YXRpb24NCiAgIHN5c3RlbSB0byBhbGxvdyBhbGwgY29tbWFuZHMg
ZW50ZXJlZCBieSB0aGUgdXNlciBvbiBhIGxvY2FsIGNvbnNvbGUNCiAgIHRvIGFpZCBpbiB0cm91
Ymxlc2hvb3RpbmcsIHRoYXQgd291bGQgZ2l2ZSBhbGwgYWNjZXNzIHRvIGFsbCBjb21tYW5kcw0K
ICAgdG8gYW55IGF0dGFja2VyIHRoYXQgd291bGQgYmUgYWJsZSB0byBjaGFuZ2UgdGhlICJhdXRo
ZW5fbWV0aG9kIiBmcm9tDQogICBUQUNfUExVU19BVVRIRU5fTUVUSF9UQUNBQ1NQTFVTIHRvIFRB
Q19QTFVTX0FVVEhFTl9NRVRIX0xJTkUuICBJbg0KICAgdGhpcyByZWdhcmQsIHRoZSBvYmZ1c2Nh
dGlvbiBwcm92aWRlZCBieSB0aGUgcHJvdG9jb2wgaXRzZWxmIHdvdWxkbid0DQogICBoZWxwIG11
Y2gsIGJlY2F1c2U6DQoNCiAgICAgIExhY2sgb2YgaW50ZWdyaXR5IG1lYW5zIHRoYXQgYW55IGJ5
dGUgaW4gdGhlIHBheWxvYWQgbWF5IGJlDQogICAgICBjaGFuZ2VkIHdpdGhvdXQgZWl0aGVyIHNp
ZGUgZGV0ZWN0aW5nIHRoZSBjaGFuZ2UuDQoNCiAgICAgIEtub3duIHBsYWludGV4dCBtZWFucyB0
aGF0IGFuIGF0dGFja2VyIHdvdWxkIGtub3cgd2l0aCBjZXJ0YWludHkNCiAgICAgIHdoaWNoIG9j
dGV0IGlzIHRoZSB0YXJnZXQgb2YgdGhlIGF0dGFjayAoaW4gdGhpcyBjYXNlLCAxc3Qgb2N0ZXQN
CiAgICAgIGFmdGVyIHRoZSBoZWFkZXIpLg0KDQogICAgICBJbiBjb21iaW5hdGlvbiB3aXRoIGtu
b3duIHBsYWludGV4dCwgdGhlIGF0dGFja2VyIGNhbiBkZXRlcm1pbmUNCiAgICAgIHdpdGggY2Vy
dGFpbnR5IHRoZSB2YWx1ZSBvZiB0aGUgY3J5cHRvLXBhZCBvY3RldCB1c2VkIHRvIG9iZnVzY2F0
ZQ0KICAgICAgdGhlIG9yaWdpbmFsIG9jdGV0Lg0KDQo5LjQuICBTZWN1cml0eSBvZiBBY2NvdW50
aW5nIFNlc3Npb25zDQoNCiAgIEFjY291bnRpbmcgc2Vzc2lvbnMgYXJlIG5vdCBkaXJlY3RseSBp
bnZvbHZlZCBpbiBhdXRoZW50aWNhdGlvbiBvcg0KICAgYXV0aG9yaXppbmcgb3BlcmF0aW9ucyBv
biB0aGUgZGV2aWNlLiAgSG93ZXZlciwgbWFuLWluLXRoZS1taWRkbGUNCiAgIGF0dGFja2VyIG1h
eSBkbyBhbnkgb2YgdGhlIGZvbGxvd2luZzoNCg0KICAgICAgUmVwbGFjZSBhY2NvdW50aW5nIGRh
dGEgd2l0aCBuZXcgdmFsaWQgb3IgZ2FyYmFnZSB3aGljaCBwcmV2ZW50cw0KICAgICAgdG8gcHJv
dmlkZSBkaXN0cmFjdGlvbiBvciBoaWRlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlaXINCiAg
ICAgIGF1dGhlbnRpY2F0aW9uIGFuZC9vciBhdXRob3JpemF0aW9uIGF0dGFjayBhdHRlbXB0cy4N
Cg0KICAgICAgVHJ5IGFuZCBwb2lzb24gYWNjb3VudGluZyBsb2cgd2l0aCBlbnRyaWVzIGRlc2ln
bmVkIHRvIG1ha2UNCiAgICAgIHN5c3RlbXMgYmVoYXZlIGluIHVuaW50ZW5kZWQgd2F5cyAod2hp
Y2ggaW5jbHVkZXMgVEFDQUNTKyBzZXJ2ZXINCiAgICAgIGFuZCBhbnkgb3RoZXIgc3lzdGVtcyB0
aGF0IHdvdWxkIG1hbmFnZSBhY2NvdW50aW5nIGVudHJpZXMpLg0KDQogICBJbiBhZGRpdGlvbiB0
byB0aGVzZSBkaXJlY3QgbWFuaXB1bGF0aW9ucywgZGlmZmVyZW50IGNsaWVudA0KICAgaW1wbGVt
ZW50YXRpb25zIHBhc3MgZGlmZmVyZW50IGZpZGVsaXR5IG9mIGFjY291bnRpbmcgZGF0YS4gIFNv
bWUNCiAgIHZlbmRvcnMgaGF2ZSBiZWVuIG9ic2VydmVkIGluIHRoZSB3aWxkIHRoYXQgcGFzcyBz
ZW5zaXRpdmUgZGF0YSBsaWtlDQogICBwYXNzd29yZHMsIGVuY3J5cHRpb24ga2V5cyBhbmQgc2lt
aWxhciBhcyBwYXJ0IG9mIHRoZSBhY2NvdW50aW5nIGxvZy4NCiAgIER1ZSB0byBsYWNrIG9mIHN0
cm9uZyBlbmNyeXB0aW9uIHdpdGggcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3ksIHRoaXMNCiAgIGRh
dGEgbWF5IGJlIHJldmVhbGVkIGluIGZ1dHVyZSwgbGVhZGluZyB0byBhIHNlY3VyaXR5IGluY2lk
ZW50Lg0KDQo5LjUuICBUQUNBQ1MrIENsaWVudCBJbXBsZW1lbnRhdGlvbiBSZWNvbW1lbmRhdGlv
bnMNCg0KICAgVGhlIGZvbGxvd2luZyByZWNvbW1lbmRhdGlvbnMgYXJlIG1hZGUgd2hlbiBpbXBs
ZW1lbnRpbmcgYSBUQUNBQ1MrDQogICBjbGllbnQ6DQoNCiAgICAgIENsaWVudHMgU0hPVUxEIG5v
dCB1c2UgVEFDX1BMVVNfVU5FTkNSWVBURURfRkxBRywgZXZlbiBvbiBuZXR3b3Jrcw0KICAgICAg
dGhhdCBhcmUgY29uc2lkZXJlZCBzZWN1cmUuDQoNCiAgICAgIFRyZWF0IFRBQ19QTFVTX0FVVEhF
Tl9TVEFUVVNfRk9MTE9XIGFzDQogICAgICBUQUNfUExVU19BVVRIRU5fU1RBVFVTX0ZBSUwuDQoN
CiAgICAgIElmIHJlY2VpdmluZyBhbiB1bmtub3duIG1hbmRhdG9yeSBhdXRob3JpemF0aW9uIGF0
dHJpYnV0ZSwgYmVoYXZlDQogICAgICBhcyBpZiBpdCBoYWQgcmVjZWl2ZWQgVEFDX1BMVVNfQVVU
SE9SX1NUQVRVU19GQUlMLg0KDQo5LjYuICBUQUNBQ1MrIFNlcnZlciBJbXBsZW1lbnRhdGlvbiBS
ZWNvbW1lbmRhdGlvbnMNCg0KICAgVGhlIGZvbGxvd2luZyByZWNvbW1lbmRhdGlvbnMgYXJlIG1h
ZGUgd2hlbiBpbXBsZW1lbnRpbmcgYSBUQUNBQ1MrDQogICBzZXJ2ZXI6DQoNCiAgIFRoZSBTZXJ2
ZXIgU0hPVUxEIE5PVCBhY2NlcHQgYW55IGNvbm5lY3Rpb25zIHdoaWNoIGhhdmUgdGhlDQogICBU
QUNfUExVU19VTkVOQ1JZUFRFRF9GTEFHIHNldCBhbmQgU0hPVUxEIHJlamVjdCB0aG9zZSBwYWNr
ZXRzIHdpdGgNCiAgIGFwcGxpY2FibGUgRVJST1IgcmVzcG9uc2UgZm9yIHR5cGUgb2YgcGFja2V0
Lg0KDQogICBUaGUgY29uZmlndXJhdGlvbiBvZiBkZWRpY2F0ZWQgc2VjcmV0IGtleXMgcGVyIGlu
ZGl2aWR1YWwgY2xpZW50IE1VU1QNCiAgIGJlIHN1cHBvcnRlZCBieSB0aGUgU2VydmVyIGltcGxl
bWVudGF0aW9uLiAgSXQgaXMgYWxzbyByZWNvbW1lbmRlZA0KICAgdGhhdCBTZXJ2ZXJzIFNIT1VM
RCB3YXJuIGFkbWluaXN0cmF0b3JzIGlmIHNlY3JldCBrZXlzIGFyZSBub3QgdW5pcXVlDQogICBw
ZXIgY2xpZW50Lg0KDQogICBJZiBhbiBpbnZhbGlkIHNoYXJlZCBzZWNyZXQgaXMgZGV0ZWN0ZWQs
IFNlcnZlcnMgTVVTVCBOT1QgYWNjZXB0IGFueQ0KICAgbmV3IHNlc3Npb25zIG9uIGEgY29ubmVj
dGlvbiwgYW5kIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBvbg0KICAgY29tcGxldGlvbiBvZiBh
bnkgc2Vzc2lvbnMgcHJldmlvdXNseSBlc3RhYmxpc2hlZCB3aXRoIGEgdmFsaWQgc2hhcmVkDQog
ICBzZWNyZXQuDQoNCiAgIFRoZSBTZXJ2ZXIgaW1wbGVtZW50YXRpb24gbXVzdCBhbGxvdyB0aGUg
YWRtaW5pc3RyYXRvciB0byBtYW5kYXRlOg0KDQogICBUQUNfUExVU19BVVRIRU5fVFlQRV9DSEFQ
IGZvciBhdXRoZW5fdHlwZQ0KDQogICBUQUNfUExVU19BVVRIRU5fTUVUSF9UQUNBQ1NQTFVTIGZv
ciBhdXRoZW5fbWV0aG9kIGluIGF1dGhvcml6YXRpb24NCg0KICAgTWluaW11bSBsZW5ndGggZm9y
IHNoYXJlZCBzZWNyZXRzLg0KDQo5LjcuICBUQUNBQ1MrIERlcGxveW1lbnQgQmVzdCBQcmFjdGlj
ZXMNCg0KICAgRHVlIHRvIGFib3ZlIG9ic2VydmF0aW9ucyBhYm91dCB0aGUgVEFDQUNTKyBwcm90
b2NvbCwgaXQgaXMgY3JpdGljYWwNCiAgIHRvIG9ubHkgZGVwbG95IGl0IHVzaW5nIHNlY3VyZSB0
cmFuc3BvcnQuICBBIHNlY3VyZSB0cmFuc3BvcnQgZm9yDQogICBUQUNBQ1MrIGlzIGRlZmluZWQg
YXMgYW55IG1lYW5zIHRoYXQgZW5zdXJlIHByaXZhY3kgYW5kIGludGVncml0eSBvZg0KICAgYWxs
IGRhdGEgcGFzc2VkIGJldHdlZW4gY2xpZW50cyBhbmQgc2VydmVycy4gIFRoZXJlIGFyZSBtdWx0
aXBsZQ0KICAgbWVhbnMgb2YgYWNoaWV2aW5nIHRoaXMsIGFsbCBvZiB0aGVtIGJleW9uZCB0aGUg
c2NvcGUgb2YgdGhpcw0KICAgZG9jdW1lbnQuDQoNCiAgIFN5bW1ldHJpYyBlbmNyeXB0aW9uIGtl
eSByZXByZXNlbnRzIGEgcG9zc2libGUgYXR0YWNrIHZlY3RvciBhdCB0aGUNCiAgIHByb3RvY29s
IGl0c2VsZi4gIEZvciB0aGlzIHJlYXNvbiwgc2VydmVycyBTSE9VTEQgYWNjZXB0IG9ubHkgdGhv
c2UNCiAgIG5ldHdvcmsgY29ubmVjdGlvbiBhdHRlbXB0cyB0aGF0IGFycml2ZSBmcm9tIGtub3du
IGNsaWVudHMuICBUaGlzDQogICBsaW1pdHMgdGhlIGV4cG9zdXJlIGFuZCBwcmV2ZW50cyByZW1v
dGUgYnJ1dGUgZm9yY2UgYXR0YWNrcyBmcm9tDQogICB1bmtub3duIGNsaWVudHMuDQoNCiAgIER1
ZSB0byB0aGUgc2VjdXJpdHkgZGVmaWNpZW5jaWVzIG9mIHRoZSBwcm90b2NvbCwgaXQgaXMgY3Jp
dGljYWwgdGhhdA0KICAgaXQgYmUgZGVwbG95ZWQgaW4gYSBzZWN1cmUgbWFubmVyLiAgVGhlIGZv
bGxvd2luZyByZWNvbW1lbmRhdGlvbnMgYXJlDQogICBtYWRlIGZvciB0aG9zZSBkZXBsb3lpbmcg
YW5kIGNvbmZpZ3VyaW5nIFRBQ0FDUysgYXMgYSBzb2x1dGlvbiBmb3INCiAgIGRldmljZSBhZG1p
bmlzdHJhdGlvbjoNCg0KICAgICAgU2VjdXJlIHRoZSBEZXBsb3ltZW50OiBUQUNBQ1MrIE1VU1Qg
QkUgZGVwbG95ZWQgb3ZlciBuZXR3b3Jrcw0KICAgICAgd2hpY2ggZW5zdXJlIGFuIGFwcHJvcHJp
YXRlIHByaXZhY3kgYW5kIGludGVncml0eSBvZiB0aGUNCiAgICAgIGNvbW11bmljYXRpb24uICBU
aGUgd2F5IHRoaXMgaXMgZW5zdXJlZCB3aWxsIGRlcGVuZCB1cG9uIHRoZQ0KICAgICAgb3JnYW5p
emF0aW9uYWwgbWVhbnM6IGEgZGVkaWNhdGVkIGFuZCBzZWN1cmUgbWFuYWdlbWVudCBuZXR3b3Jr
DQogICAgICB3aGVyZSBhdmFpbGFibGUgaW4gZW50ZXJwcmlzZSBkZXBsb3ltZW50cywgb3IgSVBz
ZWMgd2hlcmUNCiAgICAgIGRlZGljYXRlZCBuZXR3b3JrcyBhcmUgbm90IGF2YWlsYWJsZS4NCg0K
ICAgICAgRG8gbm90IHVzZSB0aGUgVEFDX1BMVVNfVU5FTkNSWVBURURfRkxBRyBvcHRpb24uDQoN
CiAgICAgIEFsd2F5cyBjb25maWd1cmUgYSBzZWNyZXQga2V5IChyZWNvbW1lbmRlZCBtaW5pbXVt
IDE2IGNoYXJhY3RlcnMpDQogICAgICBvbiB0aGUgc2VydmVyIGZvciBlYWNoIGNsaWVudC4NCg0K
ICAgICAgQ29uc2lkZXIgc2hhcmVkIHNlY3JldHMgdG8gYmUgc2Vuc2l0aXZlIGRhdGEsIGFuZCBt
YW5hZ2Ugc2VjdXJlbHkNCiAgICAgIG9uIHNlcnZlciBhbmQgY2xpZW50Lg0KDQogICAgICBDaGFu
Z2Ugc2VjcmV0IGtleXMgYXQgcmVndWxhciBpbnRlcnZhbHMuDQoNCiAgICAgIERvIG5vdCB1c2Ug
VEFDX1BMVVNfQVVUSEVOX1NFTkRBVVRIIG9yIFRBQ19QTFVTX0FVVEhFTl9TRU5EUEFTUw0KICAg
ICAgb3B0aW9ucy4NCg0KICAgICAgVXNlIFRBQ19QTFVTX0FVVEhFTl9UWVBFX0NIQVAgb3IgTVNf
Q0hBUCBvcHRpb25zIGZvciBhdXRoZW5fdHlwZQ0KICAgICAgd2hlcmUgcG9zc2libGUuICBVc2Ug
b3RoZXIgb3B0aW9ucyBvbmx5IHdoZW4gdW5hdm9pZGFibGUgZHVlIHRvDQogICAgICByZXF1aXJl
bWVudHMgb2YgaWRlbnRpdHkvcGFzc3dvcmQgc3lzdGVtcy4NCg0KICAgICAgUmVxdWlyZSBUQUNB
Q1MrIGF1dGhlbnRpY2F0aW9uIGZvciBhdXRob3JpemF0aW9uIHJlcXVlc3RzIChpLmUuDQogICAg
ICBUQUNfUExVU19BVVRIRU5fTUVUSF9UQUNBQ1NQTFVTIGlzIHVzZWQpLg0KDQogICAgICBEbyBu
b3QgdXNlIHRoZSByZWRpcmVjdGlvbiBtZWNoYW5pc20NCiAgICAgIChUQUNfUExVU19BVVRIRU5f
U1RBVFVTX0ZPTExPVykuICBTcGVjaWZpY2FsbHkgYXZvaWQgdGhlIG9wdGlvbiB0bw0KICAgICAg
c2VuZCBzZWNyZXQga2V5cyBpbiB0aGUgc2VydmVyIGxpc3QuDQoNCiAgICAgIFRha2UgY2FzZSB3
aGVuIGFwcGx5aW5nIGV4dGVuc2lvbnMgdG8gdGhlIGRpY3Rpb25hcnkgb2YNCiAgICAgIGF1dGhv
cml6YXRpb24vYWNjb3VudGluZyBhcmd1bWVudHMuICBFbnN1cmUgdGhhdCB0aGUgY2xpZW50IGFu
ZA0KICAgICAgc2VydmVyIHVzZSBvZiBuZXcgYXJndW1lbnQgbmFtZXMgYXJlIGNvbnNpc3RlbnQu
DQoNCiAgIEluIHN1bW1hcnk6IEl0IGlzIHN0cm9uZ2x5IGFkdmlzZWQgdGhhdCBUQUNBQ1MrIE1V
U1QgYmUgdXNlZCB3aXRoaW4gYQ0KICAgc2VjdXJlIGRlcGxveW1lbnQuICBGYWlsdXJlIHRvIGRv
IHNvIG1heSBpbXBhY3Qgb3ZlcmFsbCBuZXR3b3JrDQogICBzZWN1cml0eS4NCg0KICAgIA0KDQo=


From nobody Sun Apr 15 04:31:41 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E3120227; Sun, 15 Apr 2018 04:31:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152379189276.19660.3733372501515431277.idtracker@ietfa.amsl.com>
Date: Sun, 15 Apr 2018 04:31:32 -0700
Archived-At: 
Subject: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 11:31:33 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>      The certificate extension is described below.
>
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as an access control mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>        https://example.com/lightbulbs/colour/v1
>
>      The MUD URL identifies a Thing with a specificity according to the
>      manufacturer's wishes.  It could include a brand name, model number,
>      or something more specific.  It also could provide a means to
>      indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>                    -in mudfile -binary -outform DER - \
>                    -certfile intermediatecert -out mudfile.p7s
>
>      Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


>
>   Abstract
>
>      This memo specifies a component-based architecture for manufacturer
>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>      Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>      it continues to make sense for general purpose computing devices
>      today, including laptops, smart phones, and tablets.
>
>      [RFC7452] discusses design patterns for, and poses questions about,
>      smart objects.  Let us then posit a group of objects that are
>      specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>      specifically not general purpose computers.  These devices, which
>      this memo refers to as Things, have a specific purpose.  By
>      definition, therefore, all other uses are not intended.  The
>      combination of these two statements can be restated as a manufacturer
>      usage description (MUD) that can be applied at various points within
>      a network.

I would make the point here that the purpose of the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.


>      can say about that light bulb, then, is that all other network access
>      is unwanted.  It will not contact a news service, nor speak to the
>      refrigerator, and it has no need of a printer or other devices.  It
>      has no social networking friends.  Therefore, an access list applied
>      to it that states that it will only connect to the single rendezvous
>      service will not impede the light bulb in performing its function,

This *might* be true, but imagine that I wanted to control my light
bulbs over Tor and then I would want it to act as a Tor hidden
service.


>      a public key.  In these cases, manufacturers may be able to map those
>      identifiers to particular MUD URLs (or even the files themselves).
>      Similarly, there may be alternative resolution mechanisms available
>      for situations where Internet connectivity is limited or does not
>      exist.  Such mechanisms are not described in this memo, but are
>      possible.  Implementors should allow for this sort of flexibility of

Do you mean SHOULD?


>   1.6.  Processing of the MUD URL
>
>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>      signature files as per [RFC7230], using the GET method [RFC7231].
>      They MUST validate the certificate using the rules in [RFC2618],
>      Section 3.1.

ITYM 2818.


>
>      The files that are retrieved are intended to be closely aligned to
>      existing network architectures so that they are easy to deploy.  We
>      make use of YANG [RFC7950] because of the time and effort spent to
>      develop accurate and adequate models for use by network devices.
>      JSON is used as a serialization for compactness and readability,

Nit: "serialization format"


>      The certificate extension is described below.
>
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

Updated: s/intended as an access control mechanism/intended as a post-
compromise mechanism/


>          domain reputation service, and it may test any hosts within the
>          file against those reputation services, as it deems fit.
>
>      4.  The MUD controller may query the administrator for permission to
>          add the Thing and associated policy.  If the Thing is known or
>          the Thing type is known, it may skip this step.

What is a "Thing type"?


>
>   2.1.  The IETF-MUD YANG Module
>
>      This module is structured into three parts:
>
>      o  The first container "mud" holds information that is relevant to

This appears to be the only container.


>
>      o  The third component augments the tcp-acl container of the ACL
>         model to add the ability to match on the direction of initiation
>         of a TCP connection.
>
>      A valid MUD file will contain two root objects, a "mud" container and

MUST contain?


>      extension example can be found in Appendix C.
>
>   3.9.  manufacturer
>
>      This node consists of a hostname that would be matched against the
>      authority component of another Thing's MUD URL.  In its simplest form

In what encoding?


>      the expression as is appropriate in their deployments.
>
>   3.13.  controller
>
>      This URI specifies a value that a controller will register with the
>      MUD controller.  The node then is expanded to the set of hosts that

The use of "controller" and "MUD controller" is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agent"?


>      corresponding direction.  [RFC6092] specifies IPv6 guidance best
>      practices.  While that document is scoped specifically to IPv6, its
>      contents are applicable for IPv4 as well.  When this flag is set, and
>      the system has no reason to believe a flow has been initiated it MUST
>      drop the packet.  This node may be implemented in its simplest form
>      by looking at naked SYN bits, but may also be implemented through

SYN seems over-specific here, as it doesn't apply to UDP-based
protocols.


>       reserved = 1*( CHAR ) ; from [RFC5234]
>
>      The entire option MUST NOT exceed 255 octets.  If a space follows the
>      MUD URL, a reserved string that will be defined in future
>      specifications follows.  MUD controllers that do not understand this
>      field MUST ignore it.

This is a matter of taste I suppose, but why not just have two chunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.


>   9.2.  Server Behavior
>
>      A DHCP server may ignore these options or take action based on
>      receipt of these options.  If a server successfully parses the option
>      and the URL, it MUST return the option with length field set to zero
>      and a corresponding null URL field as an acknowledgment.  Even in

What this means here is "no URL field"? Generally, the use of "null"
is confusing in the context of string processing because of C
semantics.


>
>      Because MUD files contain information that may be used to configure
>      network access lists, they are sensitive.  To insure that they have
>      not been tampered with, it is important that they be signed.  We make
>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>      this purpose.

It's very odd to be using CMS here when you are serializing in JSON.
This is a decision for the WG, but why aren't you using JWS?



From nobody Sun Apr 15 04:32:45 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAB11205F0; Sun, 15 Apr 2018 04:32:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
Date: Sun, 15 Apr 2018 04:32:44 -0700
Archived-At: 
Subject: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 11:32:44 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>      The certificate extension is described below.
>
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>        https://example.com/lightbulbs/colour/v1
>
>      The MUD URL identifies a Thing with a specificity according to the
>      manufacturer's wishes.  It could include a brand name, model number,
>      or something more specific.  It also could provide a means to
>      indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>                    -in mudfile -binary -outform DER - \
>                    -certfile intermediatecert -out mudfile.p7s
>
>      Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


>
>   Abstract
>
>      This memo specifies a component-based architecture for manufacturer
>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>      Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>      it continues to make sense for general purpose computing devices
>      today, including laptops, smart phones, and tablets.
>
>      [RFC7452] discusses design patterns for, and poses questions about,
>      smart objects.  Let us then posit a group of objects that are
>      specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>      specifically not general purpose computers.  These devices, which
>      this memo refers to as Things, have a specific purpose.  By
>      definition, therefore, all other uses are not intended.  The
>      combination of these two statements can be restated as a manufacturer
>      usage description (MUD) that can be applied at various points within
>      a network.

I would make the point here that the purpose of the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.


>      can say about that light bulb, then, is that all other network access
>      is unwanted.  It will not contact a news service, nor speak to the
>      refrigerator, and it has no need of a printer or other devices.  It
>      has no social networking friends.  Therefore, an access list applied
>      to it that states that it will only connect to the single rendezvous
>      service will not impede the light bulb in performing its function,

This *might* be true, but imagine that I wanted to control my light
bulbs over Tor and then I would want it to act as a Tor hidden
service.


>      a public key.  In these cases, manufacturers may be able to map those
>      identifiers to particular MUD URLs (or even the files themselves).
>      Similarly, there may be alternative resolution mechanisms available
>      for situations where Internet connectivity is limited or does not
>      exist.  Such mechanisms are not described in this memo, but are
>      possible.  Implementors should allow for this sort of flexibility of

Do you mean SHOULD?


>   1.6.  Processing of the MUD URL
>
>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>      signature files as per [RFC7230], using the GET method [RFC7231].
>      They MUST validate the certificate using the rules in [RFC2618],
>      Section 3.1.

ITYM 2818.


>
>      The files that are retrieved are intended to be closely aligned to
>      existing network architectures so that they are easy to deploy.  We
>      make use of YANG [RFC7950] because of the time and effort spent to
>      develop accurate and adequate models for use by network devices.
>      JSON is used as a serialization for compactness and readability,

Nit: "serialization format"


>          domain reputation service, and it may test any hosts within the
>          file against those reputation services, as it deems fit.
>
>      4.  The MUD controller may query the administrator for permission to
>          add the Thing and associated policy.  If the Thing is known or
>          the Thing type is known, it may skip this step.

What is a "Thing type"?


>
>   2.1.  The IETF-MUD YANG Module
>
>      This module is structured into three parts:
>
>      o  The first container "mud" holds information that is relevant to

This appears to be the only container.


>
>      o  The third component augments the tcp-acl container of the ACL
>         model to add the ability to match on the direction of initiation
>         of a TCP connection.
>
>      A valid MUD file will contain two root objects, a "mud" container and

MUST contain?


>      extension example can be found in Appendix C.
>
>   3.9.  manufacturer
>
>      This node consists of a hostname that would be matched against the
>      authority component of another Thing's MUD URL.  In its simplest form

In what encoding?


>      the expression as is appropriate in their deployments.
>
>   3.13.  controller
>
>      This URI specifies a value that a controller will register with the
>      MUD controller.  The node then is expanded to the set of hosts that

The use of "controller" and "MUD controller" is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agent"?


>      corresponding direction.  [RFC6092] specifies IPv6 guidance best
>      practices.  While that document is scoped specifically to IPv6, its
>      contents are applicable for IPv4 as well.  When this flag is set, and
>      the system has no reason to believe a flow has been initiated it MUST
>      drop the packet.  This node may be implemented in its simplest form
>      by looking at naked SYN bits, but may also be implemented through

SYN seems over-specific here, as it doesn't apply to UDP-based
protocols.


>       reserved = 1*( CHAR ) ; from [RFC5234]
>
>      The entire option MUST NOT exceed 255 octets.  If a space follows the
>      MUD URL, a reserved string that will be defined in future
>      specifications follows.  MUD controllers that do not understand this
>      field MUST ignore it.

This is a matter of taste I suppose, but why not just have two chunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.


>   9.2.  Server Behavior
>
>      A DHCP server may ignore these options or take action based on
>      receipt of these options.  If a server successfully parses the option
>      and the URL, it MUST return the option with length field set to zero
>      and a corresponding null URL field as an acknowledgment.  Even in

What this means here is "no URL field"? Generally, the use of "null"
is confusing in the context of string processing because of C
semantics.


>
>      Because MUD files contain information that may be used to configure
>      network access lists, they are sensitive.  To insure that they have
>      not been tampered with, it is important that they be signed.  We make
>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>      this purpose.

It's very odd to be using CMS here when you are serializing in JSON.
This is a decision for the WG, but why aren't you using JWS?



From nobody Sun Apr 15 07:38:50 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E531242F5; Sun, 15 Apr 2018 07:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level: 
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 lsR9gn-_imvQ; Sun, 15 Apr 2018 07:38:34 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530C71200F1; Sun, 15 Apr 2018 07:38:31 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f7inU-0002Me-VS; Sun, 15 Apr 2018 14:38:29 +0000
Date: Sun, 15 Apr 2018 07:38:28 -0700
Message-ID: 
From: Randy Bush 
To: Joel Halpern 
Cc: , gen-art@ietf.org, draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org, ietf@ietf.org, opsawg@ietf.org
In-Reply-To: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 14:38:36 -0000

hi joel,

> The secondary problem is that this additional work is justified for
> the router by the claim that the unusual usage of applying community
> tags for geographical location of customers is a common practice.  It
> is a legal practice.  And I presume it is done somewhere or the
> authors would not be asking for it.  But it is not common.

actually, it is used.  not in the "this prefix originted in new
hampshire," sense, but for global isps, to tag the routing region of
origin, e.g. se asia, europe, noam, ...

randy


From nobody Sun Apr 15 07:53:13 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356DC1270B4; Sun, 15 Apr 2018 07:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.585
X-Spam-Level: *
X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 aaHhztl_oDgW; Sun, 15 Apr 2018 07:52:48 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253022.outbound.protection.outlook.com [40.92.253.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A945126CD8; Sun, 15 Apr 2018 07:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yEkTyxA7saZd6RayvsOCWemVduNZQmPIYzkrh++lZiw=; b=NLnCW66g6kCyZ6uWiQKLL2w3p0QWFViFKA3UQZY+SEYlR8e3GMiNbNRIguiYfSsYvwjwdkJ2YjQPbpAjSjY/O1jviIf+ID4k0FIQRTmit8RGQ3jEJIw84SkfwyaKlX3UgQiCP1MfLwlY/IDyFkqz3VwRNPmxO123ZFAY3z+/8txD2RSkR78Vlst/F5EFSAyFHsm9ciZ4YpK8Xd08YfnDW0oZHDHc88uszjVWeYwEVfpAjA1uyx9y5lwARiBZtB1sxAF2YOnga+KkVi1Y4ifLXXJWHVkKT9V9BfVp5kWUp9IB50z7GxkbmPqYPCVKUM1YqxlcY21bmZIoJa9uBqRrvw==
Received: from SG2APC01FT008.eop-APC01.prod.protection.outlook.com (10.152.250.56) by SG2APC01HT179.eop-APC01.prod.protection.outlook.com (10.152.251.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8; Sun, 15 Apr 2018 14:52:43 +0000
Received: from HKXPR0601MB1799.apcprd06.prod.outlook.com (10.152.250.51) by SG2APC01FT008.mail.protection.outlook.com (10.152.250.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.675.14 via Frontend Transport; Sun, 15 Apr 2018 14:52:43 +0000
Received: from HKXPR0601MB1799.apcprd06.prod.outlook.com ([fe80::1c96:d34d:5d69:ae92]) by HKXPR0601MB1799.apcprd06.prod.outlook.com ([fe80::1c96:d34d:5d69:ae92%15]) with mapi id 15.20.0675.015; Sun, 15 Apr 2018 14:52:43 +0000
From: li zhenqiang 
To: "Joel M. Halpern" , "rtg-dir@ietf.org" 
CC: "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , "ietf@ietf.org" , opsawg , "gen-art@ietf.org" 
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT1MloTciQIhK0/ESu+vkwx6HGlQ==
Date: Sun, 15 Apr 2018 14:52:43 +0000
Message-ID: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:00C70E009A0877B6D6A78614931A0F036D2E977AD230D003541DF2DDD59DA28B; UpperCasedChecksum:579CA5CA730035F1B73C4027570DEBC3AAC78CF45423E9A0C03DB1900D3DDF7D; SizeAsReceived:7320; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [r74pA0mi3DRM5G+bCKdQEPQ9NRxQF1j0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT179; 7:YaCmfUxkXkzNM3DCnrM19Si3gRCHpo+IT1oguKOP4XV9K657OXb/kitVSNTll22QY+85bFsEhsgWAJgBOql4l5Q/z7DIaQUD296PJ30uMhfd5kpJR8jF8kwIQbHyjXc9QMB+gohFMc0/l2nafkE6RktBVnvVRrPffy0VEkXJgV6Y7j13QF/E50UvfleWwsBs8FhHDz7t8al8Eqel8i/rq+4T914S+0Oo+T5nBkAzmrViHbydBnmnXlhF9zGRya5T
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SG2APC01HT179; 
x-ms-traffictypediagnostic: SG2APC01HT179:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT179; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT179; 
x-forefront-prvs: 0643BDA83C
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT179; H:HKXPR0601MB1799.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; 
x-microsoft-antispam-message-info: sFt9XYNrYzBT6B6l3HVgllwRmhykTCwheARqZpN1BjCOUxe5J7MbyqMf47j8a7/b1rxygTYOpsK5ctdhGQrXbAHLihWHqup5CazfO1RC8pXkGEQMMyzsUpG3DewJ7vNfiuvHicckqCrsb0zC2wmIKsHSIkK8qE9f9glqUpm36fj8vGWpE/7GxzN5qF79iNvw
Content-Type: multipart/alternative; boundary="_000_HKXPR0601MB1799868866AF89F9699EAF28FCB10HKXPR0601MB1799_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 2c7efdc0-9a86-4069-e5c2-08d5a2e08aa4
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c7efdc0-9a86-4069-e5c2-08d5a2e08aa4
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2018 14:52:43.3823 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT179
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 14:52:50 -0000

--_000_HKXPR0601MB1799868866AF89F9699EAF28FCB10HKXPR0601MB1799_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBKb2VsIEhhbHBlcm4sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3
LiBQbGVhc2Ugc2VlIG15IHByZWxpbWluYXJ5IHJlcGx5IGJlbG93Lg0KDQpGb3IgeW91ciBmaXJz
dCBjb25jZXJuLCB0aGUgaWRlYSBpcyB3aGVuIHRoZSByb3V0ZXJzIG9idGFpbiB0aGUgaW5mb3Jt
YXRpb24gZm9yIHRoZSBhbHJlYWR5IGRlZmluZWQgQkdQIHJlbGF0ZWQgSUVzLCBzdWNoIGFzIGJn
cFNvdXJjZUFzTnVtYmVyLCBiZ3BEZXN0aW5hdGlvbkFzTnVtYmVyLCBhbmQgYmdwTmV4dEhvcElQ
djRBZGRyZXNzLCBldGMsIHRoZSBpbmZvcm1hdGlvbiBmb3IgdGhlIElFcyBkZWZpbmVkIGluIHRo
aXMgZG9jIGNhbiBiZSBvYnRhaW5lZCBhdCB0aGUgc2FtZSB0aW1lIHNpbmNlIGFsbCB0aGUgQkdQ
IHJlbGF0ZWQgaW5mb3JtYXRpb24gb2YgYSBmbG93IGlzIG9idGFpbmVkIGZyb20gdGhlIG1hdGNo
aW5nIEJHUCByb3V0aW5nIGVudHJ5IHdoZW4gdGhlIHJvdXRlciByZWNlaXZlcyB0aGUgZmlyc3Qg
cGFja2V0IG9mIHRoZSBmbG93LiBXZSBleHBsYWluIHRoaXMgcG9pbnQgaW4gdGhlIGZvcnRoIHBh
cmFncmFwaCBvZiB0aGUgSW50cm9kdWN0aW9uIHBhcnQuIE91ciBjby1hdXRob3IgSmllIERvbmcs
IHdobyBpcyBmcm9tIHByb2R1Y3QgdmVuZG9yIEh1YXdlaSwgd2lsbCBleHBsYWluIHRoaXMgaW4g
bW9yZSBkZXRhaWwgbGF0ZXIuDQoNCkkgZG8gTk9UIHRoaW5rIHRoZSByb3V0ZXJzIGhhdmUgdG8g
Y2hhbmdlIHRoZWlyIGFyY2hpdGVjdHVyZXMgdG8gcmVwb3J0IHRoZSBCR1AgcmVsYXRlZCBpbmZv
cm1hdGlvbiBmb3IgdGhlIHRyYWZmaWMgZmxvdy4gU3VwcG9zaW5nIHRoZSByb3V0ZXJzIGhhdmUg
dG8gZG8gdGhpcywgdGhleSBoYXZlIGFscmVhZHkgZG9uZSBzbyB3aGVuIGltcGxlbWVudGluZyB0
aGUgYWxyZWFkeSBkZWZpbmVkIEJHUCByZWxhdGVkIElFcyBiZ3BTb3VyY2VBc051bWJlciwgYmdw
RGVzdGluYXRpb25Bc051bWJlciwgYW5kIGJncE5leHRIb3BJUHY0QWRkcmVzcywgZXRjLiBUaGUg
Zmlyc3QgQkdQIHJlbGF0ZWQgaW5mb3JtYXRpb24gZWxlbWVudCBpcyBub3QgZGVmaW5lZCBieSBv
dXIgZHJhZnQuDQoNCldlIGFkbWl0IHRoYXQgdGhlIGNvcnJlbGF0aW9uIGNvdWxkIGJlIGRvbmUg
YXQgdGhlIGNvbGxlY3RvcnMuIEJ1dCB3ZSBpbnNpc3QgdGhhdCB0aGUgcmlnaHQgcGxhY2UgdG8g
ZG8gdGhlIEJHUCByZWxhdGVkIGNvcnJlbGF0aW9uIGlzIHRoZSBleHBvcnRlcnMgaW4gdGhlIHJv
dXRlcnMsIGJlY2F1c2UgdGhlIGNvcnJlbGF0aW9uIGZvciB0aGUgQkdQIHJlbGF0ZWQgaW5mb3Jt
YXRpb24gaXMgdmVyeSBoZWF2eSBmb3IgdGhlIGNvbGxlY3RvcnMuIFRvIGRvIHNvLCB0aGUgY29s
bGVjdG9ycyBoYXZlIHRvIHJ1biBCR1Agb3IgQk1QIHdoaWNoIGlzIGFscmVhZHkgcnVubmluZyBp
biB0aGUgcm91dGVycyBhbmQgdG8gZG8gQkdQIHRhYmxlIGxvbmdlc3QgcHJlZml4IG1hdGNoaW5n
IGxvb2t1cCB0byBmaW5kIHRoZSBjb3JyZWN0IHRhYmxlIGVudHJ5LiBXZSBleHBsYWluIHRoaXMg
cG9pbnQgaW4gdGhlIDR0aCBhbmQgNXRoIHBhcmFncmFwaHMgb2YgdGhlIEludHJvZHVjdGlvbiBw
YXJ0Lg0KDQpGb3IgeW91ciBzZWNvbmQgY29uY2VybiwgeW91IGFkbWl0IHVzaW5nIEJHUCBjb21t
dW5pdHkgYXR0cmlidXRlIHRvIHJlcHJlc2VudCB0aGUgZ2VvZ3JhcGhpY2FsIHJlZ2lvbnMgYW5k
IGRpZmZlcmVudCBraW5kcyBvZiBjdXN0b21lcnMgaXMgYSBsZWdhbCBwcmFjdGljZSwgc28gc2Fp
ZCBpbiBSRkM0MzgzIGFuZCBSRkM4MTk1LiAgV2h5IGRvIHlvdSB0aGluayB0aGlzIGlzIHVudXN1
YWwgYW5kIG5vdCBjb21tb24/IENoaW5hIE1vYmlsZSB1c2VzIHRoZSBzdGFuZGFyZCBCR1AgY29t
bXVuaXR5IHRvIHJlcHJlc2VudCB0aGUgZGlmZmVyZW50IHByb3ZpbmNlcyBhbmQgZGlmZmVyZW50
IGtpbmRzIG9mIGN1c3RvbWVycyBpbiBvdXIgZmllbGQgbmV0d29yay4gU3dpc3Njb20gYW5kIEFU
JlQgYWxzbyBzYWlkIHRoaXMgZG9jIHdhcyB1c2VmdWwgZm9yIHRoZWlyIG5ldHdvcmsgb3BlcmF0
aW9uIGluIHRoZSBtYWlsIGxpc3QgYW5kIGZhY2UgdG8gZmFjZSBtZWV0aW5nLiBBbnl3YXksIEkg
d2lsbCBhc2sgZm9yIG1vcmUgY29tbWVudHMgZnJvbSB0aGUgb3BlcmF0b3JzLg0KDQpGb3IgeW91
ciBjb2NsdXNpb24sIEknbSB2ZXJ5IGNvbmZ1c2VkLiBGcm9tIHdoZXJlIGRvIHlvdSBzYXkgdGhh
dCB0aGUgZHJhZnQgYWRtaXRzIHRoYXQgdGhpcyBpcyBub3QgbmVlZGVkPyBJZiB3ZSB0aGluayB3
aGF0IHdlIHdhbnQgaXMgbm90IG5lZWRlZCwgd2h5IHdlIHN1Ym1pdCB0aGlzIGRvYy4gSWYgc29t
ZSB3b3JkcyBpbiB0aGUgZG9jIG1pc2xlYWQgeW91LCBJIGFwb2xvZ2l6ZSBhbmQgd2lsbCBwb2xp
c2ggdGhlbS4NCg0KVGhhbmsgeW91IGFnYWluIGZvciB5b3VyIHJldmlldy4NCg0KQmVzdCBSZWdh
cmRzLA0KWmhlbnFpYW5nIExpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlf
emhlbnFpYW5nQGhvdG1haWwuY29tDQoNCkZyb206IEpvZWwgSGFscGVybjxtYWlsdG86am1oQGpv
ZWxoYWxwZXJuLmNvbT4NCkRhdGU6IDIwMTgtMDQtMTMgMjI6NDQNClRvOiBydGctZGlyQGlldGYu
b3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPg0KQ0M6IGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4
LWJncC1jb21tdW5pdHkuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2F3Zy1pcGZp
eC1iZ3AtY29tbXVuaXR5LmFsbEBpZXRmLm9yZz47IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZA
aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IGdlbi1h
cnRAaWV0Zi5vcmc8bWFpbHRvOmdlbi1hcnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSdGdkaXIgZWFy
bHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDYNClJl
dmlld2VyOiBKb2VsIEhhbHBlcm4NClJldmlldyByZXN1bHQ6IE5vdCBSZWFkeQ0KDQpUaGlzIGlz
IGJvdGggYSBnZW4tYXJ0IHJlLXJldmlldyBhbmQgYSByb3V0aW5nIGRpcmVjdG9yYXRlIHJlcXVl
c3RlZCByZXZpZXcuDQoNClRoZSByZXZpc2lvbnMgZnJvbSBkcmFmdC0wNCB0byAtMDYgc2hvdyBz
b21lIGltcHJvdmVtZW50LiAgSG93ZXZlciwgSSBzdGlsbA0KaGF2ZSBzZXJpb3VzIHByb2JsZW1z
IHdpdGggdGhpcyB3b3JrLg0KDQpUaGUgcHJpbWFyeSBwcm9ibGVtIGlzIHRoYXQgdGhpcyBzZWVt
cyB0byB2aW9sYXRlIHRoZSBkZXNpZ25lZCB3b3JrDQpkaXN0cmlidXRpb24gaW4gdGhlIElQRklY
IGFyY2hpdGVjdHVyZS4gIFRoZSBkcmFmdCBpdHNlbGYgbm90ZXMgdGhhdCB0aGUNCmNvcnJlbGF0
aW9uIHJlcXVlc3RlZCBjb3VsZCBiZSBkb25lIGluIHRoZSBjb2xsZWN0b3IuICBXaGljaCBpcyB3
aGVyZQ0KY29ycmVsYXRpb24gaXMgZGVzaWduZWQgdG8gYmUgZG9uZS4gIEluc3RlYWQsIGl0IHB1
dHMgYSBzaWduaWZpY2FudCBuZXcNCnByb2Nlc3NpbmcgbG9hZCBvbiB0aGUgcm91dGVyIHRoYXQg
aXMgZGVsaXZlcmluZyB0aGUgSVBGSVggaW5mb3JtYXRpb24uICBGb3INCmV4YW1wbGUsIGlmIG9u
ZSBkZWxpdmVycyBJUEZJWCBmcm9tIHRoZSByb3V0ZXIgZGF0YSBwbGFuZSwgb25lIGVpdGhlciBo
YXMgdG8NCm1vZGlmeSB0aGUgcm91dGVyIGFyY2hpdGVjdHVyZSB0byBpbmNsdWRlIGFkZGl0aW9u
YWwgY29tcGxleCBjb21wdXRlZA0KaW5mb3JtYXRpb24gaW4gdGhlIGRhdGEgcGxhbmUgYXJjaGl0
ZWN0dXJlIChhIGJhZCBwbGFjZSB0byBhZGQgY29tcGxleGl0eSkgb3INCm9uZSBoYXMgdG8gZ2l2
ZSB1cCBhbmQgbW92ZSBhbGwgdGhlIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxh
bmUuICBBbmQNCmV2ZW4gdGhlIGNvbnRyb2wgcGxhbmUgbGlrZWx5IGhhcyB0byBhZGQgY29tcGxl
eGl0eSB0byBpdHMgUklCIGxvZ2ljLCBhcyBpdCBoYXMNCnRvIG1vdmUgYWRkaXRpb25hbCBpbmZv
cm1hdGlvbiBmcm9tIEJHUCB0byB0aGUgY29tbW9uIHN0cnVjdHVyZXMuDQoNClRoZSBzZWNvbmRh
cnkgcHJvYmxlbSBpcyB0aGF0IHRoaXMgYWRkaXRpb25hbCB3b3JrIGlzIGp1c3RpZmllZCBmb3Ig
dGhlIHJvdXRlcg0KYnkgdGhlIGNsYWltIHRoYXQgdGhlIHVudXN1YWwgdXNhZ2Ugb2YgYXBwbHlp
bmcgY29tbXVuaXR5IHRhZ3MgZm9yIGdlb2dyYXBoaWNhbA0KbG9jYXRpb24gb2YgY3VzdG9tZXJz
IGlzIGEgY29tbW9uIHByYWN0aWNlLiAgSXQgaXMgYSBsZWdhbCBwcmFjdGljZS4gIEFuZCBJDQpw
cmVzdW1lIGl0IGlzIGRvbmUgc29tZXdoZXJlIG9yIHRoZSBhdXRob3JzIHdvdWxkIG5vdCBiZSBh
c2tpbmcgZm9yIGl0LiAgIEJ1dA0KaXQgaXMgbm90IGNvbW1vbi4NCg0KSW4gc2hvcnQsIHNpbmNl
IGV2ZW4gdGhlIGRyYWZ0IGFkbWl0cyB0aGF0IHRoaXMgaXMgbm90IG5lZWRlZCwgSSByZWNvbW1l
bmQNCmFnYWluc3QgcHVibGlzaGluZyB0aGlzIGRvY3VtZW50IGFzIGFuIFJGQy4NCg0K

--_000_HKXPR0601MB1799868866AF89F9699EAF28FCB10HKXPR0601MB1799_
Content-Type: text/html; charset="utf-8"
Content-ID: <4F2FABBF627A3E4FA56A55A927C900EC@apcprd06.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu
NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy
Z2luLWxlZnQ6IDAuNWVtOyB9Ym9keSB7IGZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog
5b6u6L2v6ZuF6buROyBjb2xvcjogcmdiKDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9Ym9k
eSB7IGZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog5b6u6L2v6ZuF6buROyBjb2xvcjog
cmdiKDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5
Pg0KPGRpdj48c3Bhbj48L3NwYW4+RGVhciBKb2VsIEhhbHBlcm4sPC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4mbmJzcDtQ
bGVhc2Ugc2VlIG15IHByZWxpbWluYXJ5IHJlcGx5IGJlbG93LjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+Rm9yIHlvdXIgZmlyc3QgY29uY2VybiwgdGhlIGlkZWEgaXMgd2hlbiB0aGUg
cm91dGVycyBvYnRhaW4gdGhlIGluZm9ybWF0aW9uIGZvciB0aGUgYWxyZWFkeSBkZWZpbmVkIEJH
UCByZWxhdGVkIElFcywgc3VjaCBhcyZuYnNwO2JncFNvdXJjZUFzTnVtYmVyLCBiZ3BEZXN0aW5h
dGlvbkFzTnVtYmVyLCBhbmQgYmdwTmV4dEhvcElQdjRBZGRyZXNzLCBldGMsIHRoZSBpbmZvcm1h
dGlvbiBmb3IgdGhlIElFcyBkZWZpbmVkIGluIHRoaXMgZG9jIGNhbg0KIGJlIG9idGFpbmVkIGF0
IHRoZSBzYW1lIHRpbWUgc2luY2UgYWxsIHRoZSBCR1AgcmVsYXRlZCBpbmZvcm1hdGlvbiBvZiBh
IGZsb3cgaXMgb2J0YWluZWQgZnJvbSB0aGUgbWF0Y2hpbmcgQkdQIHJvdXRpbmcgZW50cnkgd2hl
biB0aGUgcm91dGVyIHJlY2VpdmVzIHRoZSBmaXJzdCBwYWNrZXQgb2YgdGhlIGZsb3cuIFdlIGV4
cGxhaW4gdGhpcyBwb2ludCBpbiB0aGUgZm9ydGggcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rp
b24gcGFydC4gT3VyIGNvLWF1dGhvcg0KIEppZSBEb25nLCB3aG8gaXMgZnJvbSBwcm9kdWN0IHZl
bmRvciBIdWF3ZWksIHdpbGwgZXhwbGFpbiB0aGlzIGluIG1vcmUgZGV0YWlsIGxhdGVyLiZuYnNw
OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBOT1QgdGhpbmsgdGhlIHJvdXRl
cnMgaGF2ZSB0byBjaGFuZ2UgdGhlaXIgYXI8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7
IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+Y2hpdGVj
dHVyZXMgdG8gcmVwb3J0IHRoZSBCR1AgcmVsYXRlZCBpbmZvcm1hdGlvbiBmb3IgdGhlIHRyYWZm
aWMgZmxvdy4gU3VwcG9zaW5nIHRoZSByb3V0ZXJzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJi
YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiPmhhdmUNCiB0byBkbyB0aGlzLCB0aGV5IGhh
dmUgYWxyZWFkeSBkb25lIHNvIHdoZW4gaW1wbGVtZW50aW5nIHRoZSBhbHJlYWR5IGRlZmluZWQg
QkdQIHJlbGF0ZWQgSUVzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw
dDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7Ij5iZ3BT
b3VyY2VBc051bWJlciwgYmdwRGVzdGluYXRpb25Bc051bWJlciwgYW5kIGJncE5leHRIb3BJUHY0
QWRkcmVzcywgZXRjPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1o
ZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7Ij4uDQogVGhlIGZpcnN0
IEJHUCByZWxhdGVkIGluZm9ybWF0aW9uIGVsZW1lbnQgaXMgbm90IGRlZmluZWQgYnkgb3VyIGRy
YWZ0Ljwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGFkbWl0IHRoYXQg
dGhlIGNvcnJlbGF0aW9uIGNvdWxkIGJlIGRvbmUgYXQgdGhlIGNvbGxlY3RvcnMuIEJ1dCB3ZSBp
bnNpc3QgdGhhdCB0aGUgcmlnaHQgcGxhY2UgdG8gZG8gdGhlIEJHUCByZWxhdGVkIGNvcnJlbGF0
aW9uIGlzIHRoZSBleHBvcnRlcnMgaW4gdGhlIHJvdXRlcnMsIGJlY2F1c2UgdGhlIGNvcnJlbGF0
aW9uIGZvciB0aGUgQkdQIHJlbGF0ZWQgaW5mb3JtYXRpb24gaXMgdmVyeSBoZWF2eSBmb3IgdGhl
IGNvbGxlY3RvcnMuDQogVG8gZG8gc28sIHRoZSBjb2xsZWN0b3JzIGhhdmUgdG8gcnVuIEJHUCBv
ciBCTVAgd2hpY2ggaXMgYWxyZWFkeSBydW5uaW5nIGluIHRoZSByb3V0ZXJzIGFuZCB0byBkbyBC
R1AgdGFibGUgbG9uZ2VzdCBwcmVmaXggbWF0Y2hpbmcgbG9va3VwIHRvIGZpbmQgdGhlIGNvcnJl
Y3QgdGFibGUgZW50cnkuIFdlIGV4cGxhaW4gdGhpcyBwb2ludCBpbiB0aGUgNHRoIGFuZCA1dGgg
cGFyYWdyYXBocyBvZiB0aGUgSW50cm9kdWN0aW9uIHBhcnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5Gb3IgeW91ciBzZWNvbmQgY29uY2VybiwgeW91IGFkbWl0IHVzaW5nIEJHUCBj
b21tdW5pdHkgYXR0cmlidXRlIHRvIHJlcHJlc2VudCB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOiAxMC41cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHRyYW5z
cGFyZW50OyI+Z2VvZ3JhcGhpY2FsIHJlZ2lvbnMgYW5kIGRpZmZlcmVudCBraW5kcyBvZiBjdXN0
b21lcnMgaXMmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5l
LWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiPmENCiBsZWdhbCBw
cmFjdGljZSwgc28gc2FpZCBpbiBSRkM0MzgzIGFuZCBSRkM4MTk1LiAmbmJzcDtXaHkgZG8geW91
IHRoaW5rIHRoaXMgaXMgdW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBs
aW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiPnVzdWFsIGFu
ZCBub3QgY29tbW9uPyBDaGluYSBNb2JpbGUgdXNlcyB0aGUgc3RhbmRhcmQgQkdQIGNvbW11bml0
eSB0byZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVp
Z2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+cmVwcmVzZW50DQogdGhl
Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6
IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7Ij5kaWZmZXJlbnQgcHJvdmluY2Vz
IGFuZCBkaWZmZXJlbnQga2luZHMgb2YgY3VzdG9tZXJzIGluIG91ciBmaWVsZCBuZXR3b3JrLiBT
d2lzc2NvbSBhbmQgQVQmYW1wO1QgYWxzbyBzYWlkIHRoaXMgZG9jIHdhcyB1c2VmdWwgZm9yIHRo
ZWlyIG5ldHdvcmsgb3BlcmF0aW9uIGluIHRoZSBtYWlsDQogbGlzdCBhbmQgZmFjZSB0byBmYWNl
IG1lZXRpbmcuIEFueXdheSwgSSB3aWxsIGFzayBmb3IgbW9yZSBjb21tZW50cyBmcm9tIHRoZSBv
cGVyYXRvcnMuPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41
cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+PGJy
Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxp
bmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+Rm9yIHlvdXIg
Y29jbHVzaW9uLCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJh
bnNwYXJlbnQ7Ij5JJ20gdmVyeSBjb25mdXNlZC4gRnJvbSB3aGVyZSBkbyB5b3Ugc2F5IHRoYXQm
bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDog
MS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiPnRoZQ0KIGRyYWZ0IGFkbWl0cyB0
aGF0IHRoaXMgaXMgbm90IG5lZWRlZD8gSWYgd2UgdGhpbmsgd2hhdCB3ZSB3YW50IGlzIG5vdCBu
ZWVkZWQsIHdoeSB3ZSBzdWJtaXQgdGhpcyBkb2MuIElmIHNvbWUgd29yZHMgaW4gdGhlIGRvYyBt
aXNsZWFkIHlvdSwgSSBhcG9sb2dpemUgYW5kIHdpbGwgcG9saXNoIHRoZW0uPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1j
b2xvcjogdHJhbnNwYXJlbnQ7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjog
dHJhbnNwYXJlbnQ7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw
YXJlbnQ7Ij5UaGFuayB5b3UgYWdhaW4gZm9yIHlvdXIgcmV2aWV3Ljwvc3Bhbj48L2Rpdj4NCjxk
aXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNr
Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5k
LWNvbG9yOiB0cmFuc3BhcmVudDsiPkJlc3QgUmVnYXJkcyw8L3NwYW4+PC9kaXY+DQo8ZGl2Plpo
ZW5xaWFuZyBMaTwvZGl2Pg0KPGhyIHN0eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIg
Y29sb3I9IiNiNWM0ZGYiIHNpemU9IjEiIGFsaWduPSJsZWZ0Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2
IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw
cHQiPg0KPGRpdj5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu
PjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRv
bTogMHB4OyBtYXJnaW4tTGVmdDogMC41ZW0iPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxkaXYgc3R5bGU9IlBBRERJTkctUklHSFQ6IDhweDsgUEFERElO
Ry1MRUZUOiA4cHg7IEZPTlQtU0laRTogMTJweDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAw
MDAwMDsgQkFDS0dST1VORDogI2VmZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1U
T1A6IDhweCI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpqbWhAam9l
bGhhbHBlcm4uY29tIj5Kb2VsIEhhbHBlcm48L2E+PC9kaXY+DQo8ZGl2PjxiPkRhdGU6PC9iPiZu
YnNwOzIwMTgtMDQtMTMmbmJzcDsyMjo0NDwvZGl2Pg0KPGRpdj48Yj5Ubzo8L2I+Jm5ic3A7PGEg
aHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+PC9kaXY+
DQo8ZGl2PjxiPkNDOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vcHNhd2ct
aXBmaXgtYmdwLWNvbW11bml0eS5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3BzYXdnLWlwZml4
LWJncC1jb21tdW5pdHkuYWxsQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppZXRmQGll
dGYub3JnIj5pZXRmQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9y
ZyI+DQpvcHNhd2dAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Z2VuLWFydEBpZXRmLm9y
ZyI+Z2VuLWFydEBpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+PGI+U3ViamVjdDo8L2I+Jm5ic3A7
UnRnZGlyIGVhcmx5IHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVu
aXR5LTA2PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+UmV2aWV3ZXI6IEpvZWwg
SGFscGVybjwvZGl2Pg0KPGRpdj5SZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHk8L2Rpdj4NCjxkaXY+
Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoaXMgaXMgYm90aCBhIGdlbi1hcnQgcmUtcmV2aWV3IGFuZCBh
IHJvdXRpbmcgZGlyZWN0b3JhdGUgcmVxdWVzdGVkIHJldmlldy48L2Rpdj4NCjxkaXY+Jm5ic3A7
PC9kaXY+DQo8ZGl2PlRoZSByZXZpc2lvbnMgZnJvbSBkcmFmdC0wNCB0byAtMDYgc2hvdyBzb21l
IGltcHJvdmVtZW50LiZuYnNwOyBIb3dldmVyLCBJIHN0aWxsPC9kaXY+DQo8ZGl2PmhhdmUgc2Vy
aW91cyBwcm9ibGVtcyB3aXRoIHRoaXMgd29yay48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8
ZGl2PlRoZSBwcmltYXJ5IHByb2JsZW0gaXMgdGhhdCB0aGlzIHNlZW1zIHRvIHZpb2xhdGUgdGhl
IGRlc2lnbmVkIHdvcms8L2Rpdj4NCjxkaXY+ZGlzdHJpYnV0aW9uIGluIHRoZSBJUEZJWCBhcmNo
aXRlY3R1cmUuJm5ic3A7IFRoZSBkcmFmdCBpdHNlbGYgbm90ZXMgdGhhdCB0aGU8L2Rpdj4NCjxk
aXY+Y29ycmVsYXRpb24gcmVxdWVzdGVkIGNvdWxkIGJlIGRvbmUgaW4gdGhlIGNvbGxlY3Rvci4m
bmJzcDsgV2hpY2ggaXMgd2hlcmU8L2Rpdj4NCjxkaXY+Y29ycmVsYXRpb24gaXMgZGVzaWduZWQg
dG8gYmUgZG9uZS4mbmJzcDsgSW5zdGVhZCwgaXQgcHV0cyBhIHNpZ25pZmljYW50IG5ldzwvZGl2
Pg0KPGRpdj5wcm9jZXNzaW5nIGxvYWQgb24gdGhlIHJvdXRlciB0aGF0IGlzIGRlbGl2ZXJpbmcg
dGhlIElQRklYIGluZm9ybWF0aW9uLiZuYnNwOyBGb3I8L2Rpdj4NCjxkaXY+ZXhhbXBsZSwgaWYg
b25lIGRlbGl2ZXJzIElQRklYIGZyb20gdGhlIHJvdXRlciBkYXRhIHBsYW5lLCBvbmUgZWl0aGVy
IGhhcyB0bzwvZGl2Pg0KPGRpdj5tb2RpZnkgdGhlIHJvdXRlciBhcmNoaXRlY3R1cmUgdG8gaW5j
bHVkZSBhZGRpdGlvbmFsIGNvbXBsZXggY29tcHV0ZWQ8L2Rpdj4NCjxkaXY+aW5mb3JtYXRpb24g
aW4gdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlIChhIGJhZCBwbGFjZSB0byBhZGQgY29tcGxl
eGl0eSkgb3I8L2Rpdj4NCjxkaXY+b25lIGhhcyB0byBnaXZlIHVwIGFuZCBtb3ZlIGFsbCB0aGUg
aW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDsgQW5kPC9kaXY+DQo8
ZGl2PmV2ZW4gdGhlIGNvbnRyb2wgcGxhbmUgbGlrZWx5IGhhcyB0byBhZGQgY29tcGxleGl0eSB0
byBpdHMgUklCIGxvZ2ljLCBhcyBpdCBoYXM8L2Rpdj4NCjxkaXY+dG8gbW92ZSBhZGRpdGlvbmFs
IGluZm9ybWF0aW9uIGZyb20gQkdQIHRvIHRoZSBjb21tb24gc3RydWN0dXJlcy48L2Rpdj4NCjxk
aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBzZWNvbmRhcnkgcHJvYmxlbSBpcyB0aGF0IHRoaXMg
YWRkaXRpb25hbCB3b3JrIGlzIGp1c3RpZmllZCBmb3IgdGhlIHJvdXRlcjwvZGl2Pg0KPGRpdj5i
eSB0aGUgY2xhaW0gdGhhdCB0aGUgdW51c3VhbCB1c2FnZSBvZiBhcHBseWluZyBjb21tdW5pdHkg
dGFncyBmb3IgZ2VvZ3JhcGhpY2FsPC9kaXY+DQo8ZGl2PmxvY2F0aW9uIG9mIGN1c3RvbWVycyBp
cyBhIGNvbW1vbiBwcmFjdGljZS4mbmJzcDsgSXQgaXMgYSBsZWdhbCBwcmFjdGljZS4mbmJzcDsg
QW5kIEk8L2Rpdj4NCjxkaXY+cHJlc3VtZSBpdCBpcyBkb25lIHNvbWV3aGVyZSBvciB0aGUgYXV0
aG9ycyB3b3VsZCBub3QgYmUgYXNraW5nIGZvciBpdC4mbmJzcDsmbmJzcDsgQnV0PC9kaXY+DQo8
ZGl2Pml0IGlzIG5vdCBjb21tb24uPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiBz
aG9ydCwgc2luY2UgZXZlbiB0aGUgZHJhZnQgYWRtaXRzIHRoYXQgdGhpcyBpcyBub3QgbmVlZGVk
LCBJIHJlY29tbWVuZDwvZGl2Pg0KPGRpdj5hZ2FpbnN0IHB1Ymxpc2hpbmcgdGhpcyBkb2N1bWVu
dCBhcyBhbiBSRkMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_HKXPR0601MB1799868866AF89F9699EAF28FCB10HKXPR0601MB1799_--


From nobody Sun Apr 15 09:10:15 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE4120721; Sun, 15 Apr 2018 09:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 xJs-bf62JzAY; Sun, 15 Apr 2018 09:09:57 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A701201F2; Sun, 15 Apr 2018 09:09:57 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 7FA163AA5A; Sun, 15 Apr 2018 16:09:56 +0000 (UTC)
Date: Sun, 15 Apr 2018 16:09:56 +0000
From: heasley 
To: li zhenqiang 
Cc: "Joel M. Halpern" , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" ,  "ietf@ietf.org" , opsawg 
Message-ID: <20180415160956.GC66082@shrubbery.net>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 16:09:59 -0000

Sun, Apr 15, 2018 at 02:52:43PM +0000, li zhenqiang:
> Why do you think this is unusual and not common? 

Possibly, with due respect, because he is not an operator?  While ASes often
do so internally, not all reveal it externally or not ubiquitously.  Browse
https://onestep.net/communities/ to find the geo tag values of various ASes.


From nobody Sun Apr 15 09:33:01 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B79126BF6; Sun, 15 Apr 2018 09:32:54 -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 aPfeUWDiCdfr; Sun, 15 Apr 2018 09:32:51 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (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 9ABB61252BA; Sun, 15 Apr 2018 09:32:51 -0700 (PDT)
Received: from [50.225.209.67] (helo=Joels-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1f7kaA-000AUk-8Z; Sun, 15 Apr 2018 12:32:50 -0400
To: heasley , li zhenqiang 
Cc: "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , "ietf@ietf.org" , opsawg 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>
From: "Joel M. Halpern" 
Message-ID: 
Date: Sun, 15 Apr 2018 12:32:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180415160956.GC66082@shrubbery.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120734a4ffe2a0ea2592dc3f293bed07b4457819198b14afb1e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 50.225.209.67
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 16:32:54 -0000

Thank you for that pointer.  It is informative.
I looked at a number of the entries (trying to pick larger ISPs as more 
likely to need more information.)
What i see is some ISPs doing what Randy Bush mentioned, marking 
regions.  I see a few ISPs that explicitly mark country (or in one case 
city).  I see some that mix several pieces of information including 
country in the same community, making it hard to perform what this I-D 
calls for (not impossible, just harder).  I do not see any indication of 
wide-spread consistency.

It appears that this is of use to a few ISPs.  I have never argued that 
no one wants this (the authors would not have written it if no one 
wanted it.)

 From what I can tell reading this, the value requires significantly 
more precision than "region".

Also, one of the arguments for doing this in the router is that you can 
get more timely and precise correlation.  Except that for geolocation of 
address blocks, upstream correlation seems to be quite sufficiently 
stable and precise.  NLRI may come and go.  I fone has geo-information, 
it is unlikely to change.

Yours,
Joel


On 4/15/18 12:09 PM, heasley wrote:
> Sun, Apr 15, 2018 at 02:52:43PM +0000, li zhenqiang:
>> Why do you think this is unusual and not common?
> 
> Possibly, with due respect, because he is not an operator?  While ASes often
> do so internally, not all reveal it externally or not ubiquitously.  Browse
> https://onestep.net/communities/ to find the geo tag values of various ASes.
> 


From nobody Sun Apr 15 10:28:24 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA9612420B; Sun, 15 Apr 2018 10:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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
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 LakDxe9q2pFe; Sun, 15 Apr 2018 10:28:14 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5014A1241F5; Sun, 15 Apr 2018 10:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42231; q=dns/txt; s=iport; t=1523813293; x=1525022893; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Xc52T348b83s5JSPQiJ7+GEpqUk4v9trjncxOsi5xYg=; b=VJu/pppnnPo6fbaLy4+Jqa6VvwVSXrgO+Dm5FYspvHH4EhG1H55yUN7H //83zcXhC9I43r9UAs8mqLYRD2sOQxucErTbXWoymDVon0Qavu3CJvTN1 vl+UXbe01RQlR6aIg/kpXgU3nbvFRWiZ/PaZX+7a0Q+IVloaiM0jzX6qn c=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,455,1517875200";  d="asc'?scan'208,217";a="3207587"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2018 17:28:11 +0000
Received: from [10.61.83.172] (ams3-vpn-dhcp5037.cisco.com [10.61.83.172]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3FHSAMv022359; Sun, 15 Apr 2018 17:28:10 GMT
To: Eric Rescorla , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
Date: Sun, 15 Apr 2018 19:28:09 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vas16KGCjegoZY9fmPYqpLYvw2UM2Ymhw"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 17:28:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Vas16KGCjegoZY9fmPYqpLYvw2UM2Ymhw
Content-Type: multipart/mixed; boundary="5GtRe0Fgfot4aHivpJWWFcMGPbdSSTYUJ";
 protected-headers="v1"
From: Eliot Lear 
To: Eric Rescorla , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with
 DISCUSS and COMMENT)
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
In-Reply-To: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>

--5GtRe0Fgfot4aHivpJWWFcMGPbdSSTYUJ
Content-Type: multipart/alternative;
 boundary="------------F5BE84E708B588F182420AB8"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F5BE84E708B588F182420AB8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Eric,


On 15.04.18 13:32, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Re-posted due to pilot error.
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the=

> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.

MUD is primarily intended to address the former, but provides some
benefit against the latter in some cases.=C2=A0 In particular, MUD is
intended to keep devices from getting infected in the first place.=C2=A0 =
As a
side-effect, if a device *is* broken into, it may be possible to either
prevent additional access, or otherwise detect the break-in based on a
change in profile.=C2=A0 I propose to state this more clearly in the
introduction, as follows:

NEW:

MUD primarily addresses threats to the device rather than the device as
a threat.=C2=A0 In some circumstances, however, MUD may offer some protec=
tion
in the latter case, depending on the MUD-URL is communicated, and how
devices and their communications are authenticated.

**
>
>
>
>
>
> IMPORTANT
>>      The certificate extension is described below.
>>
>>      The information returned by the MUD file server (a web server) is=

>>      valid for the duration of the Thing's connection, or as specified=
 in
>>      the description.  Thus if the Thing is disconnected, any associat=
ed
>>      configuration in the switch can be removed.  Similarly, from time=
 to
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).

Yes, configuration is intended to be removed when a device disconnects
or a session terminates.=C2=A0 This would be considered normal garbage
collection.=C2=A0 But whether or not you can simply replace the firmware =
and
gain the same access will depend on how the MUD-URL is learned.=C2=A0 If =
it
is in a manufacturer certificate, for instance, that's not something an
attacker will easily replace.=C2=A0 If the assertion is coming via LLDP, =
or
DHCP, then one has to apply the mitigations discussed in the security
considerations section (and they are numerous).


>
>
>>        https://example.com/lightbulbs/colour/v1
>>
>>      The MUD URL identifies a Thing with a specificity according to th=
e
>>      manufacturer's wishes.  It could include a brand name, model numb=
er,
>>      or something more specific.  It also could provide a means to
>>      indicate what version the product is.
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
> doesn't seem like the MUD controller can infer any of those
> characteristics from the URL.

This is a bit of an artifact from some changes in earlier versions,
which did indeed have a schema.=C2=A0 I propose to replace that paragraph=
 as
follows:

A manufacturer may construct a MUD URL in any way, so long as it makes
use of the "https" schema.

=C2=A0
>
>>                    -in mudfile -binary -outform DER - \
>>                    -certfile intermediatecert -out mudfile.p7s
>>
>>      Note: A MUD file may need to be re-signed if the signature expire=
s.
>>
>>   12.2.  Verifying a MUD file signature
> IMPORTANT: This seem underspecified. Is the intention that these
> certificates will be rooted in the WebPKI? Something else? I realize
> that IETF tends to be kind of vague about where trust anchors come
> from, but at the end of the day its hard to see how to implement this
> interoperably without some more guidance.

Indeed.=C2=A0 I've proposed some additional text to Robert in his genart
review along the following lines:

NEW:

> =C2=A0=C2=A0 It is expected that the Key Usage extension would contain =
"Digital
> =C2=A0=C2=A0 Signature" and that the extended key usage would include e=
ither "code
> =C2=A0=C2=A0 signing" or "email protection".=C2=A0 What is important is=
 simply that the
> =C2=A0=C2=A0 verification step match the purpose of the signing certifi=
cate to its
> =C2=A0=C2=A0 use.=C2=A0 It is not expected that the normal Web PKI will=
 be used.=C2=A0 For
> =C2=A0=C2=A0 one thing, typically key usage does not allow signatures.

I would expect future versions of MUD to refine this, as we're just
getting started.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>>   Abstract
>>
>>      This memo specifies a component-based architecture for manufactur=
er
>>      usage descriptions (MUD).  The goal of MUD is to provide a means =
for
>>      Things to signal to the network what sort of access and network
> I realize that "Things" has become a marketing term, but it's opaque
> and unnecessary here. "elements" would be the conventional term.

How about "end devices"?=C2=A0 That makes it clear in the abstract.=C2=A0=
 I don't
propose to do a global substitute, because we scope the term well in the
introduction, as you note directly below.

>
>
>>      it continues to make sense for general purpose computing devices
>>      today, including laptops, smart phones, and tablets.
>>
>>      [RFC7452] discusses design patterns for, and poses questions abou=
t,
>>      smart objects.  Let us then posit a group of objects that are
>>      specifically not general purpose computers.  These devices, which=

> I don't think this makes sense. These devices usually *are* general
> purpose computers (turing complete, etc.)

That these objects might happen to use a general purpose CPU or
operations system doesn't in and of itself make them general purpose
devices.=C2=A0 As a complete SKU they are sold with a single or small num=
ber
of uses in mind.=C2=A0 That is what is posited.=C2=A0 Is there a way to m=
ake that
clearer?


>
>
>>      specifically not general purpose computers.  These devices, which=

>>      this memo refers to as Things, have a specific purpose.  By
>>      definition, therefore, all other uses are not intended.  The
>>      combination of these two statements can be restated as a manufact=
urer
>>      usage description (MUD) that can be applied at various points wit=
hin
>>      a network.
> I would make the point here that the purpose of the MUD is to describe
> the communications pattern. You only really get that by the statement
> in S 1.1 that the communication pattern of other devices is too
> complicated to profile.

I think this statement is predicated on your previous comment, and would
prefer not to change text at this time.

>
>
>>      can say about that light bulb, then, is that all other network ac=
cess
>>      is unwanted.  It will not contact a news service, nor speak to th=
e
>>      refrigerator, and it has no need of a printer or other devices.  =
It
>>      has no social networking friends.  Therefore, an access list appl=
ied
>>      to it that states that it will only connect to the single rendezv=
ous
>>      service will not impede the light bulb in performing its function=
,
> This *might* be true, but imagine that I wanted to control my light
> bulbs over Tor and then I would want it to act as a Tor hidden
> service.

I would be happy to add a statement that MUD works best where both
endpoints can be identified in some fashion.

>
>
>>      a public key.  In these cases, manufacturers may be able to map t=
hose
>>      identifiers to particular MUD URLs (or even the files themselves)=
=2E
>>      Similarly, there may be alternative resolution mechanisms availab=
le
>>      for situations where Internet connectivity is limited or does not=

>>      exist.  Such mechanisms are not described in this memo, but are
>>      possible.  Implementors should allow for this sort of flexibility=
 of
> Do you mean SHOULD?

No I didn't.=C2=A0 While I don't feel that strongly,=C2=A0 I do believe i=
n the
advice we are giving here, it is not required for interoperability or
security, and so I tend to shy away from normative language in such
cases.=C2=A0 To avoid confusion, how about: =E2=80=9CImplementors are enc=
ouraged to
allow...=E2=80=9D, and as a bonus I propose to unscramble the rest of tha=
t
sentence which reads a little funny, editorially.

>
>
>>   1.6.  Processing of the MUD URL
>>
>>      MUD controllers that are able to do so SHOULD retrieve MUD URLs a=
nd
>>      signature files as per [RFC7230], using the GET method [RFC7231].=

>>      They MUST validate the certificate using the rules in [RFC2618],
>>      Section 3.1.
> ITYM 2818.

Yes I do, thank you.

>
>
>>      The files that are retrieved are intended to be closely aligned t=
o
>>      existing network architectures so that they are easy to deploy.  =
We
>>      make use of YANG [RFC7950] because of the time and effort spent t=
o
>>      develop accurate and adequate models for use by network devices.
>>      JSON is used as a serialization for compactness and readability,
> Nit: "serialization format"
>
>
Ok by me.

>>          domain reputation service, and it may test any hosts within t=
he
>>          file against those reputation services, as it deems fit.
>>
>>      4.  The MUD controller may query the administrator for permission=
 to
>>          add the Thing and associated policy.  If the Thing is known o=
r
>>          the Thing type is known, it may skip this step.
> What is a "Thing type"?

Propose: =E2=80=9Cor the administrator has established a policy for thing=
s
matching this URL=E2=80=9D (noting security considerations below).

>
>
>>   2.1.  The IETF-MUD YANG Module
>>
>>      This module is structured into three parts:
>>
>>      o  The first container "mud" holds information that is relevant t=
o
> This appears to be the only container.

Propose s/container/component/ as the next two state.
>
>
>>      o  The third component augments the tcp-acl container of the ACL
>>         model to add the ability to match on the direction of initiati=
on
>>         of a TCP connection.
>>
>>      A valid MUD file will contain two root objects, a "mud" container=
 and
> MUST contain
I could envision a manufacturer not wanting to specify access controls,
but still wanting to indicate perhaps the meta-information.=C2=A0 I can
clarify this as follows:

A valid MUD file MUST contain a "mud" container and MAY contain an
optional access-lists container that will be present whenever access
controls are to be requested.


>
>
>>      extension example can be found in Appendix C.
>>
>>   3.9.  manufacturer
>>
>>      This node consists of a hostname that would be matched against th=
e
>>      authority component of another Thing's MUD URL.  In its simplest =
form
> In what encoding?

This is stated in the YANG.
>
>
>>      the expression as is appropriate in their deployments.
>>
>>   3.13.  controller
>>
>>      This URI specifies a value that a controller will register with t=
he
>>      MUD controller.  The node then is expanded to the set of hosts th=
at
> The use of "controller" and "MUD controller" is very unfortunate
> terminology. Could you perhaps rename one of these? Given that
> "controller" is encoded in the YANG model, perhaps "MUD agent"?


Ok.=C2=A0 You're the last person who's going to complain about this ;-).
"Agent" is probably isn't what we're looking for because it is generally
used a term for a process that runs on a managED device.=C2=A0 How about =
MUD
manager?
>
>
>>      corresponding direction.  [RFC6092] specifies IPv6 guidance best
>>      practices.  While that document is scoped specifically to IPv6, i=
ts
>>      contents are applicable for IPv4 as well.  When this flag is set,=
 and
>>      the system has no reason to believe a flow has been initiated it =
MUST
>>      drop the packet.  This node may be implemented in its simplest fo=
rm
>>      by looking at naked SYN bits, but may also be implemented through=

> SYN seems over-specific here, as it doesn't apply to UDP-based
> protocols.

The mechanism is only appropriate for TCP and SYN is merely intended as
an example. Will make this more clear in the text.

>
>
>>       reserved =3D 1*( CHAR ) ; from [RFC5234]
>>
>>      The entire option MUST NOT exceed 255 octets.  If a space follows=
 the
>>      MUD URL, a reserved string that will be defined in future
>>      specifications follows.  MUD controllers that do not understand t=
his
>>      field MUST ignore it.
> This is a matter of taste I suppose, but why not just have two chunks
> in the option. The cost would be one byte in the non-extension case
> but then you would be able to handle extensions that brought the total
> length above 255.

This came as part of a late discussion with mnot and Adam, and it would
require a lot of recoding for one byte.=C2=A0 If you were to look in prev=
ious
versions you would have found this to be part of the URL, causing us
some issues with BCP 190.=C2=A0 We should have the discussion about BCP 1=
90,
but want to move forward in the meantime without a big implementation
impact.

>
>
>>   9.2.  Server Behavior
>>
>>      A DHCP server may ignore these options or take action based on
>>      receipt of these options.  If a server successfully parses the op=
tion
>>      and the URL, it MUST return the option with length field set to z=
ero
>>      and a corresponding null URL field as an acknowledgment.  Even in=

> What this means here is "no URL field"? Generally, the use of "null"
> is confusing in the context of string processing because of C
> semantics.

This text is rewritten based on the GENART review.=C2=A0 The requirement =
for
an acknowledgment is proposed to be removed.=C2=A0 Please see the thread =
with
Robert for the text.
>
>
>>      Because MUD files contain information that may be used to configu=
re
>>      network access lists, they are sensitive.  To insure that they ha=
ve
>>      not been tampered with, it is important that they be signed.  We =
make
>>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] f=
or
>>      this purpose.
> It's very odd to be using CMS here when you are serializing in JSON.
> This is a decision for the WG, but why aren't you using JWS?

For our purposes we are talking about a file, and its format isn't
really at issue (which is good because it has changed in the life of
this document, and could change again at some point).=C2=A0 The file just=

needs signing, and the goal was to integrate with commonly used and
available tool sets.=C2=A0 This having been said, I could easily envision=

this evolving in future versions.

Eliot


--------------F5BE84E708B588F182420AB8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Eric,

    

    

    
On 15.04.18 13:32, Eric Rescorla wrote=
:

    

    

      
Eric Rescorla has entered the following ballot posit=
ion for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/st=
atement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-mud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope?  If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.
    

    

    MUD is primarily intended to address the former, but provides some
    benefit against the latter in some cases.=C2=A0 In particular, MUD is=

    intended to keep devices from getting infected in the first place.=C2=
=A0
    As a side-effect, if a device *is* broken into, it may be possible
    to either prevent additional access, or otherwise detect the
    break-in based on a change in profile.=C2=A0 I propose to state this =
more
    clearly in the introduction, as follows:

    

    NEW:

    

    MUD primarily addresses threats to the device rather than the device
    as a threat.=C2=A0 In some circumstances, however, MUD may offer some=

    protection in the latter case, depending on the MUD-URL is
    communicated, and how devices and their communications are
    authenticated.

    

    
    

      





IMPORTANT


      

        
     The certificate extension is described below.=


     The information returned by the MUD file server (a web server) is
     valid for the duration of the Thing's connection, or as specified in=

     the description.  Thus if the Thing is disconnected, any associated
     configuration in the switch can be removed.  Similarly, from time to=



      

      
IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).

    

    

    Yes, configuration is intended to be removed when a device
    disconnects or a session terminates.=C2=A0 This would be considered
    normal garbage collection.=C2=A0 But whether or not you can simply
    replace the firmware and gain the same access will depend on how the
    MUD-URL is learned.=C2=A0 If it is in a manufacturer certificate, for=

    instance, that's not something an attacker will easily replace.=C2=A0=
 If
    the assertion is coming via LLDP, or DHCP, then one has to apply the
    mitigations discussed in the security considerations section (and
    they are numerous). 

    

    

    

      




      

        
       https://example.com/lightbulbs/=
colour/v1

     The MUD URL identifies a Thing with a specificity according to the
     manufacturer's wishes.  It could include a brand name, model number,=

     or something more specific.  It also could provide a means to
     indicate what version the product is.


      

      
IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


    

    

    This is a bit of an artifact from some changes in earlier versions,
    which did indeed have a schema.=C2=A0 I propose to replace that parag=
raph
    as follows:

    

    A manufacturer may construct a MUD URL in any way, so long as it
    makes use of the "https" schema.

    

    =C2=A0

    

      



      

        
                   -in mudfile -binary -outform DE=
R - \
                   -certfile intermediatecert -out mudfile.p7s

     Note: A MUD file may need to be re-signed if the signature expires.

  12.2.  Verifying a MUD file signature


      

      
IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.

    

    

    Indeed.=C2=A0 I've proposed some additional text to Robert in his gen=
art
    review along the following lines:

    
NEW:


    

      
=C2=A0=C2=A0 It is expected that the Key Usage exten=
sion would contain "Digital
=C2=A0=C2=A0 Signature" and that the extended key usage would include eit=
her "code
=C2=A0=C2=A0 signing" or "email protection".=C2=A0 What is important is s=
imply that the
=C2=A0=C2=A0 verification step match the purpose of the signing certifica=
te to its
=C2=A0=C2=A0 use.=C2=A0 It is not expected that the normal Web PKI will b=
e used.=C2=A0 For
=C2=A0=C2=A0 one thing, typically key usage does not allow signatures.


      

    

    

    I would expect future versions of MUD to refine this, as we're just
    getting started.

    

    

      

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------




      

        
  Abstract

     This memo specifies a component-based architecture for manufacturer
     usage descriptions (MUD).  The goal of MUD is to provide a means for=

     Things to signal to the network what sort of access and network


      

      
I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.

    

    

    How about "end devices"?=C2=A0 That makes it clear in the abstract.=C2=
=A0 I
    don't propose to do a global substitute, because we scope the term
    well in the introduction, as you note directly below.

    

    

      




      

        
     it continues to make sense for general purpos=
e computing devices
     today, including laptops, smart phones, and tablets.

     [RFC7452] discusses design patterns for, and poses questions about,
     smart objects.  Let us then posit a group of objects that are
     specifically not general purpose computers.  These devices, which


      

      
I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.)

    

    

    That these objects might happen to use a general purpose CPU or
    operations system doesn't in and of itself make them general purpose
    devices.=C2=A0 As a complete SKU they are sold with a single or small=

    number of uses in mind.=C2=A0 That is what is posited.=C2=A0 Is there=
 a way to
    make that clearer?

    

    

    

      




      

        
     specifically not general purpose computers.  =
These devices, which
     this memo refers to as Things, have a specific purpose.  By
     definition, therefore, all other uses are not intended.  The
     combination of these two statements can be restated as a manufacture=
r
     usage description (MUD) that can be applied at various points within=

     a network.


      

      
I would make the point here that the purpose of the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.

    

    

    I think this statement is predicated on your previous comment, and
    would prefer not to change text at this time.

    

    

      




      

        
     can say about that light bulb, then, is that =
all other network access
     is unwanted.  It will not contact a news service, nor speak to the
     refrigerator, and it has no need of a printer or other devices.  It
     has no social networking friends.  Therefore, an access list applied=

     to it that states that it will only connect to the single rendezvous=

     service will not impede the light bulb in performing its function,


      

      
This *might* be true, but imagine that I wanted to control my light
bulbs over Tor and then I would want it to act as a Tor hidden
service.

    

    

    I would be happy to add a statement that MUD works best where both
    endpoints can be identified in some fashion.

    

    

      




      

        
     a public key.  In these cases, manufacturers =
may be able to map those
     identifiers to particular MUD URLs (or even the files themselves).
     Similarly, there may be alternative resolution mechanisms available
     for situations where Internet connectivity is limited or does not
     exist.  Such mechanisms are not described in this memo, but are
     possible.  Implementors should allow for this sort of flexibility of=



      

      
Do you mean SHOULD?

    

    

    No I didn't.=C2=A0 While I don't feel that strongly,=C2=A0 I do belie=
ve in the
    advice we are giving here, it is not required for interoperability
    or security, and so I tend to shy away from normative language in
    such cases.=C2=A0 To avoid confusion, how about: =E2=80=9CImplementor=
s are
    encouraged to allow...=E2=80=9D, and as a bonus I propose to unscramb=
le the
    rest of that sentence which reads a little funny, editorially.

    

    

      




      

        
  1.6.  Processing of the MUD URL

     MUD controllers that are able to do so SHOULD retrieve MUD URLs and
     signature files as per [RFC7230], using the GET method [RFC7231].
     They MUST validate the certificate using the rules in [RFC2618],
     Section 3.1.


      

      
ITYM 2818.

    

    

    Yes I do, thank you.

    

    

      




      

        
     The files that are retrieved are intended to be closely aligned to
     existing network architectures so that they are easy to deploy.  We
     make use of YANG [RFC7950] because of the time and effort spent to
     develop accurate and adequate models for use by network devices.
     JSON is used as a serialization for compactness and readability,


      

      
Nit: "serialization format"




    

    Ok by me.

    

    

      

        
         domain reputation service, and it may tes=
t any hosts within the
         file against those reputation services, as it deems fit.

     4.  The MUD controller may query the administrator for permission to=

         add the Thing and associated policy.  If the Thing is known or
         the Thing type is known, it may skip this step.


      

      
What is a "Thing type"?

    

    

    Propose: =E2=80=9Cor the administrator has established a policy for t=
hings
    matching this URL=E2=80=9D (noting security considerations below).
    

    

      




      

        
  2.1.  The IETF-MUD YANG Module

     This module is structured into three parts:

     o  The first container "mud" holds information that is relevant to


      

      
This appears to be the only container.

    

    

    Propose s/container/component/ as the next two state.

    

      




      

        
     o  The third component augments the tcp-acl container of the ACL
        model to add the ability to match on the direction of initiation
        of a TCP connection.

     A valid MUD file will contain two root objects, a "mud" container an=
d


      

      
MUST contain

    

    I could envision a manufacturer not wanting to specify access
    controls, but still wanting to indicate perhaps the
    meta-information.=C2=A0 I can clarify this as follows:

    

    A valid MUD file MUST contain a "mud" container and MAY contain an
    optional access-lists container that will be present whenever access
    controls are to be requested.

    

    

    

      




      

        
     extension example can be found in Appendix C.=


  3.9.  manufacturer

     This node consists of a hostname that would be matched against the
     authority component of another Thing's MUD URL.  In its simplest for=
m


      

      
In what encoding?

    

    

    This is stated in the YANG.

    

      




      

        
     the expression as is appropriate in their dep=
loyments.

  3.13.  controller

     This URI specifies a value that a controller will register with the
     MUD controller.  The node then is expanded to the set of hosts that


      

      
The use of "controller" and "MUD controller" is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agent"?

    

    

    

    Ok.=C2=A0 You're the last person who's going to complain about this ;=
-).
    "Agent" is probably isn't what we're looking for because it is
    generally used a term for a process that runs on a managED device.=C2=
=A0
    How about MUD manager?

    

      




      

        
     corresponding direction.  [RFC6092] specifies=
 IPv6 guidance best
     practices.  While that document is scoped specifically to IPv6, its
     contents are applicable for IPv4 as well.  When this flag is set, an=
d
     the system has no reason to believe a flow has been initiated it MUS=
T
     drop the packet.  This node may be implemented in its simplest form
     by looking at naked SYN bits, but may also be implemented through


      

      
SYN seems over-specific here, as it doesn't apply to UDP-based
protocols.

    

    

    The mechanism is only appropriate for TCP and SYN is merely intended
    as an example. Will make this more clear in the text.

    

    

      




      

        
      reserved =3D 1*( CHAR ) ; from [RFC5234]

     The entire option MUST NOT exceed 255 octets.  If a space follows th=
e
     MUD URL, a reserved string that will be defined in future
     specifications follows.  MUD controllers that do not understand this=

     field MUST ignore it.


      

      
This is a matter of taste I suppose, but why not just have two chunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.

    

    

    This came as part of a late discussion with mnot and Adam, and it
    would require a lot of recoding for one byte.=C2=A0 If you were to lo=
ok
    in previous versions you would have found this to be part of the
    URL, causing us some issues with BCP 190.=C2=A0 We should have the
    discussion about BCP 190, but want to move forward in the meantime
    without a big implementation impact.

    

    

      




      

        
  9.2.  Server Behavior

     A DHCP server may ignore these options or take action based on
     receipt of these options.  If a server successfully parses the optio=
n
     and the URL, it MUST return the option with length field set to zero=

     and a corresponding null URL field as an acknowledgment.  Even in


      

      
What this means here is "no URL field"? Generally, the use of "null"
is confusing in the context of string processing because of C
semantics.

    

    

    This text is rewritten based on the GENART review.=C2=A0 The requirem=
ent
    for an acknowledgment is proposed to be removed.=C2=A0 Please see the=

    thread with Robert for the text.

    

      




      

        
     Because MUD files contain information that may be used to configure
     network access lists, they are sensitive.  To insure that they have
     not been tampered with, it is important that they be signed.  We mak=
e
     use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
     this purpose.


      

      
It's very odd to be using CMS here when you are serializing in JSON.
This is a decision for the WG, but why aren't you using JWS?

    

    

    For our purposes we are talking about a file, and its format isn't
    really at issue (which is good because it has changed in the life of
    this document, and could change again at some point).=C2=A0 The file =
just
    needs signing, and the goal was to integrate with commonly used and
    available tool sets.=C2=A0 This having been said, I could easily envi=
sion
    this evolving in future versions.

    

    Eliot

    

    

  


--------------F5BE84E708B588F182420AB8--

--5GtRe0Fgfot4aHivpJWWFcMGPbdSSTYUJ--

--Vas16KGCjegoZY9fmPYqpLYvw2UM2Ymhw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrTi6kACgkQh7ZrRtnS
ejNKQwgA0YjfQjzZQLXiXzfoNMrcFcgKv6Ers7nTiDW4hjyfvAriicP7cT8PFeIV
9HQNwltqEmrkCfVkR9QVX/nsArwi6nwfVcIVCCh1fJZctP2CGqsVM0MGRJOnzMWm
G8b3ZrSdv/zgK0PLU6Cf0UbHk0T4+mtDL6L8Ltpdprael9j6WzMYgaDAncktaqyd
JdA7WyYHLl77wyqlBWfzSEPBrl4/tG3/RMAPAGlA8ewdhXItq5vyQW+N9IwTMP+q
BObSx5BGdEpYu/QSN4gkjKAQaEHCXBaGFHqRrBIKscEy/gwiWBYmzK9iRgOiwLkT
1ER1EB/lyRkK93vx3vwlFRwq5jMIdw==
=pXyi
-----END PGP SIGNATURE-----

--Vas16KGCjegoZY9fmPYqpLYvw2UM2Ymhw--


From nobody Sun Apr 15 11:10:06 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F63126CC4; Sun, 15 Apr 2018 11:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 trJsOSdQougF; Sun, 15 Apr 2018 11:09:52 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AB51201FA; Sun, 15 Apr 2018 11:09:52 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f7m5y-00039L-MH; Sun, 15 Apr 2018 18:09:46 +0000
Date: Sun, 15 Apr 2018 11:09:45 -0700
Message-ID: 
From: Randy Bush 
To: "Joel M. Halpern" 
Cc: heasley , li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , opsawg , "ietf@ietf.org" 
In-Reply-To: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 18:09:53 -0000

> I do not see any indication of wide-spread consistency.

the point is that there is widespread use.  the page heas pointed out is
what is documented by large ops, the tip of the iceberg.  how about stop
speaking for operators?

randy


From nobody Sun Apr 15 12:23:31 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616321270A0 for ; Sun, 15 Apr 2018 12:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 a1T_YQGtpUK0 for ; Sun, 15 Apr 2018 12:23:23 -0700 (PDT)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F79126CE8 for ; Sun, 15 Apr 2018 12:23:23 -0700 (PDT)
Received: by mail-ot0-x229.google.com with SMTP id 23-v6so15117907otj.0 for ; Sun, 15 Apr 2018 12:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3mBtzBydddWE5TLXsv4pJ//6xyEIyh2/GWTZ+FEoA1k=; b=vL92X8TR6YcpwPw/N8ZXzJo6DDhzBGW3jezYOccKbaHNBCejCeIjMr9xHOolc6R9jL O2yn339WkS6tNcrLjRJmZw/um+caJoLWkBzsyUEoH3cnqyxWNRkB719Js/0q5YwifI7C A7zeRZpEhe6m+0JLAj+pUrHR9pUXqEwzeqjSMf8PsEbMX89ep1YiOE8QlPbCGrLPnOJ/ JEpUQeM4ohRrFzsz6pz3Qxi4ChVc7V6EiOYHzE6vDA/Ct/2x/Fyui/xlViVpDOp49z/W mJeEqC96wMKOTjIIjGUH3nY2jslRQ7X4TfZTbYdZQlQfw1/n9WDJ45ec6y0AtMPcrsEz yBwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3mBtzBydddWE5TLXsv4pJ//6xyEIyh2/GWTZ+FEoA1k=; b=n468/zz7dc7Pz7wJbFaiynzm/wvuzmaT3h8w1S01c2CjzQho+5j8BbsdgGDHmoGqZd o6uKxpWwQk3d2hflJPV9r41OVJYbDYyHCfY7qwi1M3nTPfNXvwX9lloIg3rLIedg0MMZ 4OVs/R1dhMDNviblfDt8S3aobThQ7jQozUJc2y0qBi2zN/Y3hwddqsNSeJNL6ayIGAZF VPkTnbQa7T7sicCDwxM/UV1YczeXIDrY0wFn2ttUKhHEBqFjgliqX5YK68esNW15BOlH dCy7ufiZYgStIIOuDLiblwEtukbkWXHsJTbOu3CsbKtvNV1QcJmWzILNLtyZ/he4mHRM lSOQ==
X-Gm-Message-State: ALQs6tAWN8ur3vzNkydIrplQRw/aJVjdioJw0BtnIvDRid4CCLyLsSsS xEFXMM+8b7vMXX2BYdOjXLQZlyJLrFIqxIJWzQQaFg==
X-Google-Smtp-Source: AIpwx48DsTg9qKRYXV7Sd1fhiZZqM9miAeRoQai+YYIN55HsI7DKT/hB3WYAJQQaW0dJJemj8drLAdIt+FZezIfQBho=
X-Received: by 2002:a9d:36dc:: with SMTP id s28-v6mr4500905otd.214.1523820202727;  Sun, 15 Apr 2018 12:23:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.218 with HTTP; Sun, 15 Apr 2018 12:22:42 -0700 (PDT)
In-Reply-To: <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
From: Eric Rescorla 
Date: Sun, 15 Apr 2018 12:22:42 -0700
Message-ID: 
To: Eliot Lear 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,  Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e2b0060569e80950"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 19:23:28 -0000

--000000000000e2b0060569e80950
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear  wrote:

> Hi Eric,
>
> On 15.04.18 13:32, Eric Rescorla wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:https:=
//datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Re-posted due to pilot error.
>
> Rich version of this review at:https://mozphab-ietf.devsvcdev.mozaws.net/=
D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the
> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.
>
>
> MUD is primarily intended to address the former, but provides some benefi=
t
> against the latter in some cases.  In particular, MUD is intended to keep
> devices from getting infected in the first place.  As a side-effect, if a
> device *is* broken into, it may be possible to either prevent additional
> access, or otherwise detect the break-in based on a change in profile.  I
> propose to state this more clearly in the introduction, as follows:
>
> NEW:
>
> MUD primarily addresses threats to the device rather than the device as a
> threat.  In some circumstances, however, MUD may offer some protection in
> the latter case, depending on the MUD-URL is communicated, and how device=
s
> and their communications are authenticated.
>

LGTM


>
>
> IMPORTANT
>
>      The certificate extension is described below.
>
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to
>
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).
>
>
> Yes, configuration is intended to be removed when a device disconnects or
> a session terminates.  This would be considered normal garbage collection=
.
> But whether or not you can simply replace the firmware and gain the same
> access will depend on how the MUD-URL is learned.  If it is in a
> manufacturer certificate, for instance, that's not something an attacker
> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
> one has to apply the mitigations discussed in the security considerations
> section (and they are numerous).
>

I'm not following you here. Say it's in a manufacturer certificate, what
stops me from getting my own certificate for Attacker LLC and then serving
a wide open policy? The mitigations don't really seem to do much to
counteract this.


>      The MUD URL identifies a Thing with a specificity according to the
>      manufacturer's wishes.  It could include a brand name, model number,
>      or something more specific.  It also could provide a means to
>      indicate what version the product is.
>
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
> doesn't seem like the MUD controller can infer any of those
> characteristics from the URL.
>
>
> This is a bit of an artifact from some changes in earlier versions, which
> did indeed have a schema.  I propose to replace that paragraph as follows=
:
>
> A manufacturer may construct a MUD URL in any way, so long as it makes us=
e
> of the "https" schema.
>

LGTM.

>
>
>
>                    -in mudfile -binary -outform DER - \
>                    -certfile intermediatecert -out mudfile.p7s
>
>      Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature
>
> IMPORTANT: This seem underspecified. Is the intention that these
> certificates will be rooted in the WebPKI? Something else? I realize
> that IETF tends to be kind of vague about where trust anchors come
> from, but at the end of the day its hard to see how to implement this
> interoperably without some more guidance.
>
>
> Indeed.  I've proposed some additional text to Robert in his genart revie=
w
> along the following lines:
>
> NEW:
>
>    It is expected that the Key Usage extension would contain "Digital
>    Signature" and that the extended key usage would include either "code
>    signing" or "email protection".  What is important is simply that the
>    verification step match the purpose of the signing certificate to its
>    use.  It is not expected that the normal Web PKI will be used.  For
>    one thing, typically key usage does not allow signatures.
>
>
> I would expect future versions of MUD to refine this, as we're just
> getting started.
>

This doesn't seem to address my concern, which is that there's no realistic
way of knowing
what trust anchors apply. If it's not WebPKI, then what? There's also a
factual error here:
WebPKI certificates generally do do assert digitalSignature, because
otherwise you
can't do (EC)DHE.




> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>
>   Abstract
>
>      This memo specifies a component-based architecture for manufacturer
>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>      Things to signal to the network what sort of access and network
>
> I realize that "Things" has become a marketing term, but it's opaque
> and unnecessary here. "elements" would be the conventional term.
>
>
> How about "end devices"?  That makes it clear in the abstract.  I don't
> propose to do a global substitute, because we scope the term well in the
> introduction, as you note directly below.
>

To be honest, I would do a search and replace, but I agree that theis would
resolve the ambiguity here.

>
>      it continues to make sense for general purpose computing devices
>      today, including laptops, smart phones, and tablets.
>
>      [RFC7452] discusses design patterns for, and poses questions about,
>      smart objects.  Let us then posit a group of objects that are
>      specifically not general purpose computers.  These devices, which
>
> I don't think this makes sense. These devices usually *are* general
> purpose computers (turing complete, etc.)
>
>
> That these objects might happen to use a general purpose CPU or operation=
s
> system doesn't in and of itself make them general purpose devices.  As a
> complete SKU they are sold with a single or small number of uses in mind.
> That is what is posited.  Is there a way to make that clearer?
>

Perhaps "not intended to be used for general purpose computing tasks"

>
>
>      specifically not general purpose computers.  These devices, which
>      this memo refers to as Things, have a specific purpose.  By
>      definition, therefore, all other uses are not intended.  The
>      combination of these two statements can be restated as a manufacture=
r
>      usage description (MUD) that can be applied at various points within
>      a network.
>
> I would make the point here that the purpose of the MUD is to describe
> the communications pattern. You only really get that by the statement
> in S 1.1 that the communication pattern of other devices is too
> complicated to profile.
>
>
> I think this statement is predicated on your previous comment, and would
> prefer not to change text at this time.
>

Hmmm.... No, I don't think you're reading me right here. I'm just saying
that it would be useful upfront to say that MUD
is about saying "this is what communications pattern these devices are
expected to have"

>
>      can say about that light bulb, then, is that all other network acces=
s
>      is unwanted.  It will not contact a news service, nor speak to the
>      refrigerator, and it has no need of a printer or other devices.  It
>      has no social networking friends.  Therefore, an access list applied
>      to it that states that it will only connect to the single rendezvous
>      service will not impede the light bulb in performing its function,
>
> This *might* be true, but imagine that I wanted to control my light
> bulbs over Tor and then I would want it to act as a Tor hidden
> service.
>
>
> I would be happy to add a statement that MUD works best where both
> endpoints can be identified in some fashion.
>

Sure. I was just objecting to the implication that that's the only way one
might want to run one's system.

>
>      a public key.  In these cases, manufacturers may be able to map thos=
e
>      identifiers to particular MUD URLs (or even the files themselves).
>      Similarly, there may be alternative resolution mechanisms available
>      for situations where Internet connectivity is limited or does not
>      exist.  Such mechanisms are not described in this memo, but are
>      possible.  Implementors should allow for this sort of flexibility of
>
> Do you mean SHOULD?
>
>
> No I didn't.  While I don't feel that strongly,  I do believe in the
> advice we are giving here, it is not required for interoperability or
> security, and so I tend to shy away from normative language in such cases=
.
> To avoid confusion, how about: =E2=80=9CImplementors are encouraged to al=
low...=E2=80=9D,
> and as a bonus I propose to unscramble the rest of that sentence which
> reads a little funny, editorially.
>

SGTM.




>   1.6.  Processing of the MUD URL
>
>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>      signature files as per [RFC7230], using the GET method [RFC7231].
>      They MUST validate the certificate using the rules in [RFC2618],
>      Section 3.1.
>
> ITYM 2818.
>
>
> Yes I do, thank you.
>
>      The files that are retrieved are intended to be closely aligned to
>      existing network architectures so that they are easy to deploy.  We
>      make use of YANG [RFC7950] because of the time and effort spent to
>      develop accurate and adequate models for use by network devices.
>      JSON is used as a serialization for compactness and readability,
>
> Nit: "serialization format"
>
>
>
> Ok by me.
>
>          domain reputation service, and it may test any hosts within the
>          file against those reputation services, as it deems fit.
>
>      4.  The MUD controller may query the administrator for permission to
>          add the Thing and associated policy.  If the Thing is known or
>          the Thing type is known, it may skip this step.
>
> What is a "Thing type"?
>
>
> Propose: =E2=80=9Cor the administrator has established a policy for thing=
s
> matching this URL=E2=80=9D (noting security considerations below).
>

SGTM.

>
>   2.1.  The IETF-MUD YANG Module
>
>      This module is structured into three parts:
>
>      o  The first container "mud" holds information that is relevant to
>
> This appears to be the only container.
>
>
> Propose s/container/component/ as the next two state.
>

SGTM.

     o  The third component augments the tcp-acl container of the ACL
>         model to add the ability to match on the direction of initiation
>         of a TCP connection.
>
>      A valid MUD file will contain two root objects, a "mud" container an=
d
>
> MUST contain
>
> I could envision a manufacturer not wanting to specify access controls,
> but still wanting to indicate perhaps the meta-information.  I can clarif=
y
> this as follows:
>
> A valid MUD file MUST contain a "mud" container and MAY contain an
> optional access-lists container that will be present whenever access
> controls are to be requested.
>

SGTM.


>      extension example can be found in Appendix C.
>
>   3.9.  manufacturer
>
>      This node consists of a hostname that would be matched against the
>      authority component of another Thing's MUD URL.  In its simplest for=
m
>
> In what encoding?
>
>
> This is stated in the YANG.
>

OK.

     the expression as is appropriate in their deployments.
>
>   3.13.  controller
>
>      This URI specifies a value that a controller will register with the
>      MUD controller.  The node then is expanded to the set of hosts that
>
> The use of "controller" and "MUD controller" is very unfortunate
> terminology. Could you perhaps rename one of these? Given that
> "controller" is encoded in the YANG model, perhaps "MUD agent"?
>
>
>
> Ok.  You're the last person who's going to complain about this ;-).
> "Agent" is probably isn't what we're looking for because it is generally
> used a term for a process that runs on a managED device.  How about MUD
> manager?
>

OK.

     corresponding direction.  [RFC6092] specifies IPv6 guidance best
>      practices.  While that document is scoped specifically to IPv6, its
>      contents are applicable for IPv4 as well.  When this flag is set, an=
d
>      the system has no reason to believe a flow has been initiated it MUS=
T
>      drop the packet.  This node may be implemented in its simplest form
>      by looking at naked SYN bits, but may also be implemented through
>
> SYN seems over-specific here, as it doesn't apply to UDP-based
> protocols.
>
>
> The mechanism is only appropriate for TCP and SYN is merely intended as a=
n
> example. Will make this more clear in the text.
>

OK.

>
>       reserved =3D 1*( CHAR ) ; from [RFC5234]
>
>      The entire option MUST NOT exceed 255 octets.  If a space follows th=
e
>      MUD URL, a reserved string that will be defined in future
>      specifications follows.  MUD controllers that do not understand this
>      field MUST ignore it.
>
> This is a matter of taste I suppose, but why not just have two chunks
> in the option. The cost would be one byte in the non-extension case
> but then you would be able to handle extensions that brought the total
> length above 255.
>
>
> This came as part of a late discussion with mnot and Adam, and it would
> require a lot of recoding for one byte.  If you were to look in previous
> versions you would have found this to be part of the URL, causing us some
> issues with BCP 190.  We should have the discussion about BCP 190, but wa=
nt
> to move forward in the meantime without a big implementation impact.
>

To be clear, it's not about saving a byte, but about having a more legible
and extensible encoding. However, it's a matter of taste, I agree.

>
>   9.2.  Server Behavior
>
>      A DHCP server may ignore these options or take action based on
>      receipt of these options.  If a server successfully parses the optio=
n
>      and the URL, it MUST return the option with length field set to zero
>      and a corresponding null URL field as an acknowledgment.  Even in
>
> What this means here is "no URL field"? Generally, the use of "null"
> is confusing in the context of string processing because of C
> semantics.
>
>
> This text is rewritten based on the GENART review.  The requirement for a=
n
> acknowledgment is proposed to be removed.  Please see the thread with
> Robert for the text.
>

OK.

>      Because MUD files contain information that may be used to configure
>      network access lists, they are sensitive.  To insure that they have
>      not been tampered with, it is important that they be signed.  We mak=
e
>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>      this purpose.
>
> It's very odd to be using CMS here when you are serializing in JSON.
> This is a decision for the WG, but why aren't you using JWS?
>
>
> For our purposes we are talking about a file, and its format isn't really
> at issue (which is good because it has changed in the life of this
> document, and could change again at some point).  The file just needs
> signing, and the goal was to integrate with commonly used and available
> tool sets.  This having been said, I could easily envision this evolving =
in
> future versions.
>

Sure, this is just a matter of consistency, and have having to only support
one technology platform, but I can see how one would come to a different
decision.

-Ekr


> Eliot
>
>
>

--000000000000e2b0060569e80950
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Eric,

    

    

    
On 15.04.18 13:32,=
 Eric Rescorla wrote:

    

    

      
Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html=

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://da=
tatracker.ietf.org/doc/draft-ietf-opsawg-mud/



-----------------------------------------------------------------=
-----
DISCUSS:
-----------------------------------------------------------------=
-----

Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ie=
tf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope?  If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.
    

    

    MUD is primarily intended to address the former, but provides some
    benefit against the latter in some cases.=C2=A0 In particular, MUD is
    intended to keep devices from getting infected in the first place.=C2=
=A0
    As a side-effect, if a device *is* broken into, it may be possible
    to either prevent additional access, or otherwise detect the
    break-in based on a change in profile.=C2=A0 I propose to state this mo=
re
    clearly in the introduction, as follows:

    

    NEW:

    

    MUD primarily addresses threats to the device rather than the device
    as a threat.=C2=A0 In some circumstances, however, MUD may offer some
    protection in the latter case, depending on the MUD-URL is
    communicated, and how devices and their communications are
    authenticated.

<=
/div>
LGTM
 

    

    
    



IMPORTANT


      

        
     The certificate extension is described below.

     The information returned by the MUD file server (a web server) is
     valid for the duration of the Thing's connection, or as specified =
in
     the description.  Thus if the Thing is disconnected, any associated
     configuration in the switch can be removed.  Similarly, from time to


      

      
IMPORTANT: What does "disconnected" mean in this conte=
xt? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).

    

    

    Yes, configuration is intended to be removed when a device
    disconnects or a session terminates.=C2=A0 This would be considered
    normal garbage collection.=C2=A0 But whether or not you can simply
    replace the firmware and gain the same access will depend on how the
    MUD-URL is learned.=C2=A0 If it is in a manufacturer certificate, for
    instance, that's not something an attacker will easily replace.=C2=
=A0 If
    the assertion is coming via LLDP, or DHCP, then one has to apply the
    mitigations discussed in the security considerations section (and
    they are numerous). 

I'm =
not following you here. Say it's in a manufacturer certificate, what st=
ops me from getting my own certificate for Attacker LLC and then serving a =
wide open policy? The mitigations don't really seem to do much to count=
eract this.



    
     The MUD URL identifies a Thing with a specificity according =
to the
     manufacturer's wishes.  It could include a brand name, model numbe=
r,
     or something more specific.  It also could provide a means to
     indicate what version the product is.


      

      
IMPORTANT: Are you just using "identify" loosely here?=
 I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


    

    

    This is a bit of an artifact from some changes in earlier versions,
    which did indeed have a schema.=C2=A0 I propose to replace that paragra=
ph
    as follows:

    

    A manufacturer may construct a MUD URL in any way, so long as it
    makes use of the "https" schema.
<=
/div>

LGTM. 

    

    =C2=A0

    

      

      

        
                   -in mudfile -binary -outform DER - \
                   -certfile intermediatecert -out mudfile.p7s

     Note: A MUD file may need to be re-signed if the signature expires.

  12.2.  Verifying a MUD file signature


      

      
IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.

    

    

    Indeed.=C2=A0 I've proposed some additional text to Robert in his g=
enart
    review along the following lines:

    
NEW:


    

      
=C2=A0=C2=A0 It is expected that the Key Usage extension would c=
ontain "Digital
=C2=A0=C2=A0 Signature" and that the extended key usage would include =
either "code
=C2=A0=C2=A0 signing" or "email protection".=C2=A0 What is i=
mportant is simply that the
=C2=A0=C2=A0 verification step match the purpose of the signing certificate=
 to its
=C2=A0=C2=A0 use.=C2=A0 It is not expected that the normal Web PKI will be =
used.=C2=A0 For
=C2=A0=C2=A0 one thing, typically key usage does not allow signatures.


      

    

    

    I would expect future versions of MUD to refine this, as we're just
    getting started.
This doesn't seem to address my concern, which is that ther=
e's no realistic way of knowing
what trust anchors apply. If =
it's not WebPKI, then what? There's also a factual error here:
WebPKI certificates generally do do assert digitalSignature, because =
otherwise you
can't do (EC)DHE.


=



    

    

      
-----------------------------------------------------------=
-----------
COMMENT:
-----------------------------------------------------------------=
-----




      

        
  Abstract

     This memo specifies a component-based architecture for manufacturer
     usage descriptions (MUD).  The goal of MUD is to provide a means for
     Things to signal to the network what sort of access and network


      

      
I realize that "Things" has become a marketing term, b=
ut it's opaque
and unnecessary here. "elements" would be the conventional term.<=
/pre>
    

    

    How about "end devices"?=C2=A0 That makes it clear in the abs=
tract.=C2=A0 I
    don't propose to do a global substitute, because we scope the term
    well in the introduction, as you note directly below.<=
br>

To be honest, I would do a=
 search and replace, but I agree that theis would resolve the ambiguity her=
e. 

    

    

      

      

        
     it continues to make sense for general purpose computing =
devices
     today, including laptops, smart phones, and tablets.

     [RFC7452] discusses design patterns for, and poses questions about,
     smart objects.  Let us then posit a group of objects that are
     specifically not general purpose computers.  These devices, which


      

      
I don't think this makes sense. These devices usually *are* =
general
purpose computers (turing complete, etc.)

    

    

    That these objects might happen to use a general purpose CPU or
    operations system doesn't in and of itself make them general purpos=
e
    devices.=C2=A0 As a complete SKU they are sold with a single or small
    number of uses in mind.=C2=A0 That is what is posited.=C2=A0 Is there a=
 way to
    make that clearer?
<=
br>
Perhaps "not intended to be used for general purpose com=
puting tasks" 

    

    

    

      

      

        
     specifically not general purpose computers.  These device=
s, which
     this memo refers to as Things, have a specific purpose.  By
     definition, therefore, all other uses are not intended.  The
     combination of these two statements can be restated as a manufacturer
     usage description (MUD) that can be applied at various points within
     a network.


      

      
I would make the point here that the purpose of the MUD is to de=
scribe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.

    

    

    I think this statement is predicated on your previous comment, and
    would prefer not to change text at this time.

Hmmm.... No, I don't think you=
're reading me right here. I'm just saying that it would be useful =
upfront to say that MUD
is about saying "this is what commun=
ications pattern these devices are expected to have"

    

    

      

      

        
     can say about that light bulb, then, is that all other ne=
twork access
     is unwanted.  It will not contact a news service, nor speak to the
     refrigerator, and it has no need of a printer or other devices.  It
     has no social networking friends.  Therefore, an access list applied
     to it that states that it will only connect to the single rendezvous
     service will not impede the light bulb in performing its function,


      

      
This *might* be true, but imagine that I wanted to control my li=
ght
bulbs over Tor and then I would want it to act as a Tor hidden
service.

    

    

    I would be happy to add a statement that MUD works best where both
    endpoints can be identified in some fashion.

Sure. I was just objecting to the i=
mplication that that's the only way one might want to run one's sys=
tem.

    

    

      

      

        
     a public key.  In these cases, manufacturers may be able =
to map those
     identifiers to particular MUD URLs (or even the files themselves).
     Similarly, there may be alternative resolution mechanisms available
     for situations where Internet connectivity is limited or does not
     exist.  Such mechanisms are not described in this memo, but are
     possible.  Implementors should allow for this sort of flexibility of


      

      
Do you mean SHOULD?

    

    

    No I didn't.=C2=A0 While I don't feel that strongly,=C2=A0 I do=
 believe in the
    advice we are giving here, it is not required for interoperability
    or security, and so I tend to shy away from normative language in
    such cases.=C2=A0 To avoid confusion, how about: =E2=80=9CImplementors =
are
    encouraged to allow...=E2=80=9D, and as a bonus I propose to unscramble=
 the
    rest of that sentence which reads a little funny, editorially.

SGTM.
 =


=C2=A0

      

        
  1.6.  Processing of the MUD URL

     MUD controllers that are able to do so SHOULD retrieve MUD URLs and
     signature files as per [RFC7230], using the GET method [RFC7231].
     They MUST validate the certificate using the rules in [RFC2618],
     Section 3.1.


      

      
ITYM 2818.

    

    

    Yes I do, thank you.

    

    

      

      

        
     The files that are retrieved are intended to be closely a=
ligned to
     existing network architectures so that they are easy to deploy.  We
     make use of YANG [RFC7950] because of the time and effort spent to
     develop accurate and adequate models for use by network devices.
     JSON is used as a serialization for compactness and readability,


      

      
Nit: "serialization format"




    

    Ok by me.

    

    

      

        
         domain reputation service, and it may test any hosts =
within the
         file against those reputation services, as it deems fit.

     4.  The MUD controller may query the administrator for permission to
         add the Thing and associated policy.  If the Thing is known or
         the Thing type is known, it may skip this step.


      

      
What is a "Thing type"?

    

    

    Propose: =E2=80=9Cor the administrator has established a policy for thi=
ngs
    matching this URL=E2=80=9D (noting security considerations below).

SGTM.
=

    

    

      

      

        
  2.1.  The IETF-MUD YANG Module

     This module is structured into three parts:

     o  The first container "mud" holds information that is relev=
ant to


      

      
This appears to be the only container.

    

    

    Propose s/container/component/ as the next two state.<=
br>

SGTM.
 
<=
span class=3D"">
    

      

      

        
     o  The third component augments the tcp-acl container of =
the ACL
        model to add the ability to match on the direction of initiation
        of a TCP connection.

     A valid MUD file will contain two root objects, a "mud" cont=
ainer and


      

      
MUST contain

    

    I could envision a manufacturer not wanting to specify access
    controls, but still wanting to indicate perhaps the
    meta-information.=C2=A0 I can clarify this as follows:

    

    A valid MUD file MUST contain a "mud" container and MAY conta=
in an
    optional access-lists container that will be present whenever access
    controls are to be requested.

SGTM.
 

    

    

      

      

        
     extension example can be found in Appendix C.

  3.9.  manufacturer

     This node consists of a hostname that would be matched against the
     authority component of another Thing's MUD URL.  In its simplest f=
orm


      

      
In what encoding?

    

    

    This is stated in the YANG.

OK.
 

    

      

      

        
     the expression as is appropriate in their deployments.

  3.13.  controller

     This URI specifies a value that a controller will register with the
     MUD controller.  The node then is expanded to the set of hosts that


      

      
The use of "controller" and "MUD controller"=
 is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agen=
t"?

    

    

    

    Ok.=C2=A0 You're the last person who's going to complain about =
this ;-).
    "Agent" is probably isn't what we're looking for beca=
use it is
    generally used a term for a process that runs on a managED device.=C2=
=A0
    How about MUD manager?

OK.
 
<=
div text=3D"#000000" bgcolor=3D"#FFFFFF">
    

      

      

        
     corresponding direction.  [RFC6092] specifies IPv6 guidan=
ce best
     practices.  While that document is scoped specifically to IPv6, its
     contents are applicable for IPv4 as well.  When this flag is set, and
     the system has no reason to believe a flow has been initiated it MUST
     drop the packet.  This node may be implemented in its simplest form
     by looking at naked SYN bits, but may also be implemented through


      

      
SYN seems over-specific here, as it doesn't apply to UDP-bas=
ed
protocols.

    

    

    The mechanism is only appropriate for TCP and SYN is merely intended
    as an example. Will make this more clear in the text.<=
br>

OK. 

    

    

      

      

        
      reserved =3D 1*( CHAR ) ; from [RFC5234]

     The entire option MUST NOT exceed 255 octets.  If a space follows the
     MUD URL, a reserved string that will be defined in future
     specifications follows.  MUD controllers that do not understand this
     field MUST ignore it.


      

      
This is a matter of taste I suppose, but why not just have two c=
hunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.

    

    

    This came as part of a late discussion with mnot and Adam, and it
    would require a lot of recoding for one byte.=C2=A0 If you were to look
    in previous versions you would have found this to be part of the
    URL, causing us some issues with BCP 190.=C2=A0 We should have the
    discussion about BCP 190, but want to move forward in the meantime
    without a big implementation impact.
<=
/blockquote>

To be clear, it's not about saving a by=
te, but about having a more legible and extensible encoding. However, it=
9;s a matter of taste, I agree.

    

    

      

      

        
  9.2.  Server Behavior

     A DHCP server may ignore these options or take action based on
     receipt of these options.  If a server successfully parses the option
     and the URL, it MUST return the option with length field set to zero
     and a corresponding null URL field as an acknowledgment.  Even in


      

      
What this means here is "no URL field"? Generally, the=
 use of "null"
is confusing in the context of string processing because of C
semantics.

    

    

    This text is rewritten based on the GENART review.=C2=A0 The requiremen=
t
    for an acknowledgment is proposed to be removed.=C2=A0 Please see the
    thread with Robert for the text.

OK. 

    

      

      

        
     Because MUD files contain information that may be used to=
 configure
     network access lists, they are sensitive.  To insure that they have
     not been tampered with, it is important that they be signed.  We make
     use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
     this purpose.


      

      
It's very odd to be using CMS here when you are serializing =
in JSON.
This is a decision for the WG, but why aren't you using JWS?

    

    

    For our purposes we are talking about a file, and its format isn't
    really at issue (which is good because it has changed in the life of
    this document, and could change again at some point).=C2=A0 The file ju=
st
    needs signing, and the goal was to integrate with commonly used and
    available tool sets.=C2=A0 This having been said, I could easily envisi=
on
    this evolving in future versions.

Sure, thi=
s is just a matter of consistency, and have having to only support one tech=
nology platform, but I can see how one would come to a different decision.<=
/div>

-Ekr


    

    Eliot

    

    

  






--000000000000e2b0060569e80950--


From nobody Sun Apr 15 15:28:34 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C214127286; Sun, 15 Apr 2018 15:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 mGOuOUC6vNVt; Sun, 15 Apr 2018 15:28:26 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD3F1271DF; Sun, 15 Apr 2018 15:28:26 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f7q8C-000446-Cu; Sun, 15 Apr 2018 22:28:20 +0000
Date: Sun, 15 Apr 2018 15:28:19 -0700
Message-ID: 
From: Randy Bush 
To: "Joel M. Halpern" 
Cc: heasley , li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , opsawg , "ietf@ietf.org" 
In-Reply-To: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 22:28:27 -0000

> I fone has geo-information, it is unlikely to change.

i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever.  it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.

when you find yourself in a hole, first thing is to stop digging.


From nobody Sun Apr 15 15:47:01 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2666B1272E1; Sun, 15 Apr 2018 15:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 lYTROVNrFd7w; Sun, 15 Apr 2018 15:46:44 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 647B61250B8; Sun, 15 Apr 2018 15:46:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BBE24E004E; Sun, 15 Apr 2018 15:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523832404; bh=ydLFmaVDNlvVr4StRbJ5RCgPEpnlKi6+CEaysQUwM1s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ym9JPKL10SlxhCMucRwcn/WreSnJBGywWcFTSuGhairPeRGcyuYLQs+RAjpgOWLVK nyYIIINlu/9X4MX+8xihstHVwFoCrs5L1e2GDZmC1AW8v7g6o1Vd7f4hIAGW2esb0o M26vb3F80xi6YPssS9WV0VIHDbkaAvscrs6itBiI=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2970A1C0B99; Sun, 15 Apr 2018 15:46:41 -0700 (PDT)
To: Randy Bush 
Cc: "rtg-dir@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , heasley , opsawg , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , li zhenqiang 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>  
From: "Joel M. Halpern" 
Message-ID: <62aa2b28-05c6-37a3-d4cc-142395b28fe0@joelhalpern.com>
Date: Sun, 15 Apr 2018 18:46:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 22:46:46 -0000

Randy, I did suggest that one would update the offline data.
My point was that the draft claims taht extreme timliness is needed. 
For IP block geolocation, timeliness on the order of a day (much shorter 
than the several days before the IETF when the IETF block gets turned on 
somewhere.)

Thus, again, you are not making a case for why the existing techniques 
which are easier to implement and deploy are not sufficie3nt for the 
problem.

Yours,
Joel

On 4/15/18 6:28 PM, Randy Bush wrote:
>> I fone has geo-information, it is unlikely to change.
> 
> i guess you have never noticed when you are at ietf praha and your phone
> says you are in seoul or whatever.  it takes non-trivial ops pain to get
> ietf attendees geoloc to work; and sometimes we can't.
> 
> when you find yourself in a hole, first thing is to stop digging.
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 


From nobody Sun Apr 15 15:54:13 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4751250B8; Sun, 15 Apr 2018 15:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 Ly-jOWLU2cz5; Sun, 15 Apr 2018 15:53:49 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBEB127241; Sun, 15 Apr 2018 15:53:49 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f7qWn-0004AM-4c; Sun, 15 Apr 2018 22:53:45 +0000
Date: Sun, 15 Apr 2018 15:53:43 -0700
Message-ID: 
From: Randy Bush 
To: "Joel M. Halpern" 
Cc: "rtg-dir@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , heasley , opsawg , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , li zhenqiang 
In-Reply-To: <62aa2b28-05c6-37a3-d4cc-142395b28fe0@joelhalpern.com>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>   <62aa2b28-05c6-37a3-d4cc-142395b28fe0@joelhalpern.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 22:53:51 -0000

> Thus, again, you are not making a case for why the existing techniques
> which are easier to implement and deploy are not sufficie3nt for the
> problem.

correct.  i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
granularities.  you are not required to agree.

and you can argue the rest with someone else.


From nobody Sun Apr 15 15:57:41 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AC6127241; Sun, 15 Apr 2018 15:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 R3cFSgiBf0fM; Sun, 15 Apr 2018 15:57:25 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D76111250B8; Sun, 15 Apr 2018 15:57:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C35EB4E004F; Sun, 15 Apr 2018 15:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523833045; bh=6OdgxPXg2V6XYCs/Rj7VHrfTTUKjDDn/m/SvrrOVFpg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=B/a5S7U2UiN1gwFw/xmCrHbdXAy9qm7wCT2c3K3iIgkvezQWKzhihzJ9q+Rmsgsv4 K7voQraJh5VSw2A8CT/QlkhBeS5zQBM8DwOKCQQ2T1KvDCHcEEX57AHHqJRO76zy3v jRrW7dYdsSeXOuxWWNIVhIePD0JGQUkIX7V6FnfI=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B2C5A1C0B99; Sun, 15 Apr 2018 15:57:24 -0700 (PDT)
To: Randy Bush 
Cc: "rtg-dir@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , heasley , opsawg , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , li zhenqiang 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>   <62aa2b28-05c6-37a3-d4cc-142395b28fe0@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: 
Date: Sun, 15 Apr 2018 18:57:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 22:57:27 -0000

randy, noting that the IETF has trouble with the geo-tagging of its 
addresses does not seem to have ANYTHING to do with demonstrating how 
widely used the geo-communities are.

If you want to make that case, make it.  But don't bring up red herrings.

As you note, it is up to the WG, not to me, what to ask for regarding 
this draft.  And it is up to the ADs to judge whether this is a good 
thing to standardize.

Yours,
Joel

On 4/15/18 6:53 PM, Randy Bush wrote:
>> Thus, again, you are not making a case for why the existing techniques
>> which are easier to implement and deploy are not sufficie3nt for the
>> problem.
> 
> correct.  i, and a couple of other ops, are making the case that
> communities are fairly widely used for tagging geo loc at varying
> granularities.  you are not required to agree.
> 
> and you can argue the rest with someone else.
> 


From nobody Sun Apr 15 19:45:43 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6812D77C; Sun, 15 Apr 2018 19:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.21
X-Spam-Level: **
X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=4.1, SPF_PASS=-0.001] autolearn=no 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 wb3NsUr2y1N2; Sun, 15 Apr 2018 19:45:22 -0700 (PDT)
Received: from m21397.mail.qiye.163.com (m21397.mail.qiye.163.com [223.252.213.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A312D77A; Sun, 15 Apr 2018 19:45:21 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.77]) by m21397.mail.qiye.163.com (Hmail) with ESMTPA id BA842142BF7; Mon, 16 Apr 2018 10:45:19 +0800 (CST)
From: "Aijun Wang" 
To: 
Cc: , ,  , , 
References: 
In-Reply-To: 
Date: Mon, 16 Apr 2018 10:45:18 +0800
Message-ID: <00d101d3d52c$f57047d0$e050d770$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01D3D570.039387D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHT1IDANG9Z65W2K0qtbzqg9K7avaQCrqFw
Content-Language: zh-cn
X-HM-Spam-Status: e1ktWUFJV1koWUFKTEtLSjdXWQgYFAkeWUFLVUtXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kSHx4VD1lBWUc6KzY6PBw5DDotTTVOODYYFhEQPgkwCitVSlVKTklI Q09NTElLSU9OVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZDB4ZWUEdGhcIHldZ CAFZQUpDSE9JN1dZEgtZQVlJSkJVSk9JVU1CVUxMWQY+
X-HM-Tid: 0a62cc57a9d97f6bkuukba842142bf7
Archived-At: 
Subject: [OPSAWG] =?gb2312?b?tPC4tDogUnRnZGlyIGVhcmx5IHJldmlldyBvZiBkcmFm?= =?gb2312?b?dC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA2?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 02:45:25 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00D2_01D3D570.039387D0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit

Hi, Joel:

Can we consider this draft from other viewpoints? If the router can report
and correlate the traffic with its associated community, the usage of the
community to differentiate the customer, the service category that be
accessed and the geographical region etc. will be flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

From: Joel Halpern  

Date: 2018-04-13 22:44

To: rtg-dir@ietf.org

CC: draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org; ietf@ietf.org;
opsawg@ietf.org; gen-art@ietf.org

Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

 

This is both a gen-art re-review and a routing directorate requested review.

 

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

 

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add complexity)
or

one has to give up and move all the information through the control plane.
And

even the control plane likely has to add complexity to its RIB logic, as it
has

to move additional information from BGP to the common structures.

 

The secondary problem is that this additional work is justified for the
router

by the claim that the unusual usage of applying community tags for
geographical

location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for it.
But

it is not common.

 

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.

 


------=_NextPart_000_00D2_01D3D570.039387D0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


Hi, Joel:
Can we consider this draft from other viewpoints? If =
the router can report and correlate the traffic with its associated =
community, the usage of the community to differentiate the customer, the =
service category that be accessed and the geographical region etc. will =
be flourished.
And currently, China Telecom has some internal usage =
regulation for community to differentiate some important customers and =
the related services.
 
 
Best Regards.
 
Aijun Wang
Network R&D and Operation Support =
Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, =
China.
 
F=
rom:&=
nbsp;Joel =
Halpern
D=
ate:&=
nbsp;2018-04-13 22:44
T=
o:&=
nbsp;rtg-dir@ietf.org
S=
ubject:&=
nbsp;Rtgdir early review of =
draft-ietf-opsawg-ipfix-bgp-community-06
Reviewer: Joel =
Halpern
Review result: Not =
Ready
 
This is both a gen-art re-review and a routing =
directorate requested review.
 
The revisions from draft-04 to -06 show some =
improvement.  However, I still
have serious problems with this =
work.
 
The primary problem is that this seems to violate the =
designed work
distribution in the IPFIX architecture.  The =
draft itself notes that the
correlation requested could be done in the =
collector.  Which is where
correlation is designed to be done.  Instead, it =
puts a significant new
processing load on the router that is delivering the =
IPFIX information.  For
example, if one delivers IPFIX from the router data =
plane, one either has to
modify the router architecture to include additional =
complex computed
information in the data plane architecture (a bad =
place to add complexity) or
one has to give up and move all the information =
through the control plane.  And
even the control plane likely has to add complexity to =
its RIB logic, as it has
to move additional information from BGP to the common =
structures.
 
The secondary problem is that this additional work is =
justified for the router
by the claim that the unusual usage of applying =
community tags for geographical
location of customers is a common practice.  It =
is a legal practice.  And I
presume it is done somewhere or the authors would not =
be asking for it.   But
it is not common.
 
In short, since even the draft admits that this is not =
needed, I recommend
against publishing this document as an =
RFC.
 

------=_NextPart_000_00D2_01D3D570.039387D0--


From nobody Sun Apr 15 20:39:53 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8874912D77C; Sun, 15 Apr 2018 20:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 uLM6dUn7s_Ga; Sun, 15 Apr 2018 20:39:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 00E3C1204DA; Sun, 15 Apr 2018 20:39:34 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 93B164BCB6247; Mon, 16 Apr 2018 04:39:29 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 16 Apr 2018 04:39:31 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 16 Apr 2018 11:39:25 +0800
From: Tianran Zhou 
To: "Joel M. Halpern" , heasley , li zhenqiang 
CC: "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , "ietf@ietf.org" , opsawg 
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT0zX1x60GZaZE206pZAQJbOzf56QBe9sAgAAGZYCAATo/QA==
Date: Mon, 16 Apr 2018 03:39:25 +0000
Message-ID: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 03:39:35 -0000

SGkgSm9lbCwNCg0KPiBGcm9tIHdoYXQgSSBjYW4gdGVsbCByZWFkaW5nIHRoaXMsIHRoZSB2YWx1
ZSByZXF1aXJlcyBzaWduaWZpY2FudGx5IG1vcmUNCj4gcHJlY2lzaW9uIHRoYW4gInJlZ2lvbiIu
DQoNCkFzIGZhciBhcyBJIGNhbiBzZWUsIHRoaXMgZG9jdW1lbnQgcHJvcG9zZWQgYSBuZXcgYWdn
cmVnYXRpb24gcGFyYW1ldGVyIGZvciBJUEZJWC4gU28gdGhhdCB0aGUgb3BlcmF0b3JzIGNhbiBn
ZXQgdGhlIHRyYWZmaWMgc3RhdGlzdGljIGZyb20gYSBuZXcgZGltZW5zaW9uLg0KQmVjYXVzZSAi
RmxvdyBpbmZvcm1hdGlvbiBiYXNlZCBvbiBJUCBhZGRyZXNzIG9yIElQIHByZWZpeCBtYXkgcHJv
dmlkZSBtdWNoIHRvbyBmaW5lIGdyYW51bGFyaXR5IGZvciBhIGxhcmdlIG5ldHdvcmsuIE9uIHRo
ZSBjb250cmFyeSwgZmxvdyBpbmZvcm1hdGlvbiBiYXNlZCBvbiBBUyBudW1iZXIgbWF5IGJlIHRv
byBjb2Fyc2UuIg0KSXQgc291bmRzIHJlYXNvbmFibGUuDQoNCg0KVGlhbnJhbg0KDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmpv
ZWxAc3RldmVjcm9ja2VyLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxOCAxMjoz
MyBBTQ0KPiBUbzogaGVhc2xleSA8aGVhc0BzaHJ1YmJlcnkubmV0PjsgbGkgemhlbnFpYW5nIDxs
aV96aGVucWlhbmdAaG90bWFpbC5jb20+DQo+IENjOiBydGctZGlyQGlldGYub3JnOyBnZW4tYXJ0
QGlldGYub3JnOw0KPiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LmFsbEBp
ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgb3BzYXdnDQo+IDxvcHNhd2dAaWV0Zi5vcmc+DQo+IFN1
YmplY3Q6IFJlOiBSdGdkaXIgZWFybHkgcmV2aWV3IG9mDQo+IGRyYWZ0LWlldGYtb3BzYXdnLWlw
Zml4LWJncC1jb21tdW5pdHktMDYNCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhhdCBwb2ludGVyLiAg
SXQgaXMgaW5mb3JtYXRpdmUuDQo+IEkgbG9va2VkIGF0IGEgbnVtYmVyIG9mIHRoZSBlbnRyaWVz
ICh0cnlpbmcgdG8gcGljayBsYXJnZXIgSVNQcyBhcyBtb3JlIGxpa2VseQ0KPiB0byBuZWVkIG1v
cmUgaW5mb3JtYXRpb24uKSBXaGF0IGkgc2VlIGlzIHNvbWUgSVNQcyBkb2luZyB3aGF0IFJhbmR5
IEJ1c2gNCj4gbWVudGlvbmVkLCBtYXJraW5nIHJlZ2lvbnMuICBJIHNlZSBhIGZldyBJU1BzIHRo
YXQgZXhwbGljaXRseSBtYXJrIGNvdW50cnkNCj4gKG9yIGluIG9uZSBjYXNlIGNpdHkpLiAgSSBz
ZWUgc29tZSB0aGF0IG1peCBzZXZlcmFsIHBpZWNlcyBvZiBpbmZvcm1hdGlvbg0KPiBpbmNsdWRp
bmcgY291bnRyeSBpbiB0aGUgc2FtZSBjb21tdW5pdHksIG1ha2luZyBpdCBoYXJkIHRvIHBlcmZv
cm0gd2hhdCB0aGlzDQo+IEktRCBjYWxscyBmb3IgKG5vdCBpbXBvc3NpYmxlLCBqdXN0IGhhcmRl
cikuICBJIGRvIG5vdCBzZWUgYW55IGluZGljYXRpb24NCj4gb2Ygd2lkZS1zcHJlYWQgY29uc2lz
dGVuY3kuDQo+IA0KPiBJdCBhcHBlYXJzIHRoYXQgdGhpcyBpcyBvZiB1c2UgdG8gYSBmZXcgSVNQ
cy4gIEkgaGF2ZSBuZXZlciBhcmd1ZWQgdGhhdCBubw0KPiBvbmUgd2FudHMgdGhpcyAodGhlIGF1
dGhvcnMgd291bGQgbm90IGhhdmUgd3JpdHRlbiBpdCBpZiBubyBvbmUgd2FudGVkIGl0LikNCj4g
DQo+ICBGcm9tIHdoYXQgSSBjYW4gdGVsbCByZWFkaW5nIHRoaXMsIHRoZSB2YWx1ZSByZXF1aXJl
cyBzaWduaWZpY2FudGx5IG1vcmUNCj4gcHJlY2lzaW9uIHRoYW4gInJlZ2lvbiIuDQo+IA0KPiBB
bHNvLCBvbmUgb2YgdGhlIGFyZ3VtZW50cyBmb3IgZG9pbmcgdGhpcyBpbiB0aGUgcm91dGVyIGlz
IHRoYXQgeW91IGNhbiBnZXQNCj4gbW9yZSB0aW1lbHkgYW5kIHByZWNpc2UgY29ycmVsYXRpb24u
ICBFeGNlcHQgdGhhdCBmb3IgZ2VvbG9jYXRpb24gb2YgYWRkcmVzcw0KPiBibG9ja3MsIHVwc3Ry
ZWFtIGNvcnJlbGF0aW9uIHNlZW1zIHRvIGJlIHF1aXRlIHN1ZmZpY2llbnRseSBzdGFibGUgYW5k
DQo+IHByZWNpc2UuICBOTFJJIG1heSBjb21lIGFuZCBnby4gIEkgZm9uZSBoYXMgZ2VvLWluZm9y
bWF0aW9uLCBpdCBpcyB1bmxpa2VseQ0KPiB0byBjaGFuZ2UuDQo+IA0KPiBZb3VycywNCj4gSm9l
bA0KPiANCj4gDQo+IE9uIDQvMTUvMTggMTI6MDkgUE0sIGhlYXNsZXkgd3JvdGU6DQo+ID4gU3Vu
LCBBcHIgMTUsIDIwMTggYXQgMDI6NTI6NDNQTSArMDAwMCwgbGkgemhlbnFpYW5nOg0KPiA+PiBX
aHkgZG8geW91IHRoaW5rIHRoaXMgaXMgdW51c3VhbCBhbmQgbm90IGNvbW1vbj8NCj4gPg0KPiA+
IFBvc3NpYmx5LCB3aXRoIGR1ZSByZXNwZWN0LCBiZWNhdXNlIGhlIGlzIG5vdCBhbiBvcGVyYXRv
cj8gIFdoaWxlIEFTZXMNCj4gPiBvZnRlbiBkbyBzbyBpbnRlcm5hbGx5LCBub3QgYWxsIHJldmVh
bCBpdCBleHRlcm5hbGx5IG9yIG5vdA0KPiA+IHViaXF1aXRvdXNseS4gIEJyb3dzZSBodHRwczov
L29uZXN0ZXAubmV0L2NvbW11bml0aWVzLyB0byBmaW5kIHRoZSBnZW8NCj4gdGFnIHZhbHVlcyBv
ZiB2YXJpb3VzIEFTZXMuDQo+ID4NCg==


From nobody Sun Apr 15 20:40:49 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3C1204DA; Sun, 15 Apr 2018 20:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 fFRb4sZYm_FT; Sun, 15 Apr 2018 20:40:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 A705A12D77C; Sun, 15 Apr 2018 20:40:15 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 23118F0721C98; Mon, 16 Apr 2018 04:40:12 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 16 Apr 2018 04:40:13 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 16 Apr 2018 11:40:09 +0800
From: "Dongjie (Jimmy)" 
To: Joel Halpern , "rtg-dir@ietf.org" 
CC: "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" , "gen-art@ietf.org" 
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT0zX1w/Ov8PWmpkGg5ezlfsT2sqQCrsUA
Date: Mon, 16 Apr 2018 03:40:09 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927983DA81F@NKGEML515-MBX.china.huawei.com>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
In-Reply-To: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 03:40:28 -0000

SGkgSm9lbCwgDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgY29tbWVudHMuIA0KDQpS
ZWdhcmRpbmcgeW91ciBmaXJzdCBwcm9ibGVtLCBJIGRvbid0IHRoaW5rIHRoaXMgZHJhZnQgaW50
cm9kdWNlcyAic2lnbmlmaWNhbnQgbmV3IHByb2Nlc3NpbmcgbG9hZCBvbiB0aGUgcm91dGVyIiwg
YXMgc2ltaWxhciBwcm9jZXNzaW5nIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBmb3IgdGhlIEJHUCBB
UyBudW1iZXIgYW5kIEJHUC1uZXh0aG9wIGJhc2VkIHRyYWZmaWMgY29sbGVjdGlvbi4gQXMgZGVz
Y3JpYmVkIGluIHRoZSBkcmFmdCwgdGhlIEJHUC1jb21tdW5pdHkgYmFzZWQgdHJhZmZpYyBjb2xs
ZWN0aW9uIGlzIGRvbmUgYnkgQkdQIGxvb2t1cCBhbmQgY29ycmVsYXRpbmcgdGhlIEJHUCBjb21t
dW5pdHkgd2l0aCB0aGUgZmxvdyBkYXRhIHRvIGJlIGV4cG9ydGVkLiBXaGV0aGVyIGl0IGlzIGRv
bmUgaW4gZGF0YSBwbGFuZSBvciBjb250cm9sIHBsYW5lIGlzIGltcGxlbWVudGF0aW9uIHNwZWNp
ZmljIGFuZCBJTU8gZG9lcyBub3QgYmVsb25nIHRvIGEgSUVURiBkb2N1bWVudC4gDQoNCkFzIGZv
ciB5b3VyIHNlY29uZCBwcm9ibGVtLCBhcyBtYW55IG9wZXJhdG9ycyBoYXZlIHBvaW50ZWQgb3V0
LCBpdCBpcyBhIGNvbW1vbiBjYXNlIHRvIHVzZSBCR1AgY29tbXVuaXRpZXMgdG8gcmVwcmVzZW50
IGdlbyBsb2NhdGlvbnMgYXQgdmFyaW91cyBncmFudWxhcml0aWVzLiBTbyB3ZSBuZWVkIHRvIHBy
b3ZpZGUgdGhlbSB0aGUgdG9vbHMgdG8gbWVldCB0aGVpciByZXF1aXJlbWVudHMuIFN0YW5kYXJk
aXppbmcgdGhlIElFcyBmb3IgQkdQIGNvbW11bml0eSBpcyBhIGdvb2Qgc3RhcnQuDQoNCkJlc3Qg
cmVnYXJkcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpv
ZWwgSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IFNlbnQ6IEZyaWRheSwg
QXByaWwgMTMsIDIwMTggMTA6NDQgUE0NCj4gVG86IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4gQ2M6IGRy
YWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkuYWxsQGlldGYub3JnOyBpZXRmQGll
dGYub3JnOw0KPiBvcHNhd2dAaWV0Zi5vcmc7IGdlbi1hcnRAaWV0Zi5vcmcNCj4gU3ViamVjdDog
UnRnZGlyIGVhcmx5IHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVu
aXR5LTA2DQo+IA0KPiBSZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+IFJldmlldyByZXN1bHQ6IE5v
dCBSZWFkeQ0KPiANCj4gVGhpcyBpcyBib3RoIGEgZ2VuLWFydCByZS1yZXZpZXcgYW5kIGEgcm91
dGluZyBkaXJlY3RvcmF0ZSByZXF1ZXN0ZWQgcmV2aWV3Lg0KPiANCj4gVGhlIHJldmlzaW9ucyBm
cm9tIGRyYWZ0LTA0IHRvIC0wNiBzaG93IHNvbWUgaW1wcm92ZW1lbnQuICBIb3dldmVyLCBJIHN0
aWxsDQo+IGhhdmUgc2VyaW91cyBwcm9ibGVtcyB3aXRoIHRoaXMgd29yay4NCj4gDQo+IFRoZSBw
cmltYXJ5IHByb2JsZW0gaXMgdGhhdCB0aGlzIHNlZW1zIHRvIHZpb2xhdGUgdGhlIGRlc2lnbmVk
IHdvcmsNCj4gZGlzdHJpYnV0aW9uIGluIHRoZSBJUEZJWCBhcmNoaXRlY3R1cmUuICBUaGUgZHJh
ZnQgaXRzZWxmIG5vdGVzIHRoYXQgdGhlDQo+IGNvcnJlbGF0aW9uIHJlcXVlc3RlZCBjb3VsZCBi
ZSBkb25lIGluIHRoZSBjb2xsZWN0b3IuICBXaGljaCBpcyB3aGVyZQ0KPiBjb3JyZWxhdGlvbiBp
cyBkZXNpZ25lZCB0byBiZSBkb25lLiAgSW5zdGVhZCwgaXQgcHV0cyBhIHNpZ25pZmljYW50IG5l
dw0KPiBwcm9jZXNzaW5nIGxvYWQgb24gdGhlIHJvdXRlciB0aGF0IGlzIGRlbGl2ZXJpbmcgdGhl
IElQRklYIGluZm9ybWF0aW9uLiAgRm9yDQo+IGV4YW1wbGUsIGlmIG9uZSBkZWxpdmVycyBJUEZJ
WCBmcm9tIHRoZSByb3V0ZXIgZGF0YSBwbGFuZSwgb25lIGVpdGhlciBoYXMgdG8NCj4gbW9kaWZ5
IHRoZSByb3V0ZXIgYXJjaGl0ZWN0dXJlIHRvIGluY2x1ZGUgYWRkaXRpb25hbCBjb21wbGV4IGNv
bXB1dGVkDQo+IGluZm9ybWF0aW9uIGluIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZSAoYSBi
YWQgcGxhY2UgdG8gYWRkIGNvbXBsZXhpdHkpIG9yDQo+IG9uZSBoYXMgdG8gZ2l2ZSB1cCBhbmQg
bW92ZSBhbGwgdGhlIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxhbmUuDQo+IEFu
ZCBldmVuIHRoZSBjb250cm9sIHBsYW5lIGxpa2VseSBoYXMgdG8gYWRkIGNvbXBsZXhpdHkgdG8g
aXRzIFJJQiBsb2dpYywgYXMgaXQgaGFzDQo+IHRvIG1vdmUgYWRkaXRpb25hbCBpbmZvcm1hdGlv
biBmcm9tIEJHUCB0byB0aGUgY29tbW9uIHN0cnVjdHVyZXMuDQo+IA0KPiBUaGUgc2Vjb25kYXJ5
IHByb2JsZW0gaXMgdGhhdCB0aGlzIGFkZGl0aW9uYWwgd29yayBpcyBqdXN0aWZpZWQgZm9yIHRo
ZSByb3V0ZXIgYnkNCj4gdGhlIGNsYWltIHRoYXQgdGhlIHVudXN1YWwgdXNhZ2Ugb2YgYXBwbHlp
bmcgY29tbXVuaXR5IHRhZ3MgZm9yIGdlb2dyYXBoaWNhbA0KPiBsb2NhdGlvbiBvZiBjdXN0b21l
cnMgaXMgYSBjb21tb24gcHJhY3RpY2UuICBJdCBpcyBhIGxlZ2FsIHByYWN0aWNlLiAgQW5kIEkN
Cj4gcHJlc3VtZSBpdCBpcyBkb25lIHNvbWV3aGVyZSBvciB0aGUgYXV0aG9ycyB3b3VsZCBub3Qg
YmUgYXNraW5nIGZvciBpdC4gICBCdXQNCj4gaXQgaXMgbm90IGNvbW1vbi4NCj4gDQo+IEluIHNo
b3J0LCBzaW5jZSBldmVuIHRoZSBkcmFmdCBhZG1pdHMgdGhhdCB0aGlzIGlzIG5vdCBuZWVkZWQs
IEkgcmVjb21tZW5kDQo+IGFnYWluc3QgcHVibGlzaGluZyB0aGlzIGRvY3VtZW50IGFzIGFuIFJG
Qy4NCg0K


From nobody Sun Apr 15 20:42:14 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AA12D77C; Sun, 15 Apr 2018 20:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 M0upy8DgizHo; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DDDD41204DA; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C152E1C0B99; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523850130; bh=F2C221reOC00PBJMp2JT4KXyaL30W7r0+xiE6m12xmA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pN+26xUsa02IUomPlySSCSBuGvSsBzOFHYY5U8LbxQLd17Ffcv/lj92PzRRmdzzU5 kec/IYDGO6HhRtXS4cQzDtA/XsEflF18D8ciWtRLgAztwQYtJx31uqqX70L3wpCfKi RHcEasMjHXygppqBGuBYFJQTI2cShTMlPc1tHK4Y=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D7E674E00AE; Sun, 15 Apr 2018 20:42:08 -0700 (PDT)
To: Aijun Wang 
Cc: rtg-dir@ietf.org, draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org, ietf@ietf.org, opsawg@ietf.org, gen-art@ietf.org
References:  <00d101d3d52c$f57047d0$e050d770$@org.cn>
From: "Joel M. Halpern" 
Message-ID: <9b559b32-51d0-d761-ae00-08403a041544@joelhalpern.com>
Date: Sun, 15 Apr 2018 23:42:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <00d101d3d52c$f57047d0$e050d770$@org.cn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OPSAWG]  =?utf-8?b?562U5aSNOiBSdGdkaXIgZWFybHkgcmV2aWV3IG9mIGRy?= =?utf-8?q?aft-ietf-opsawg-ipfix-bgp-community-06?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 03:42:12 -0000

There seem to be two separate issues.

The first issue is what information from BGP would one like to correlate 
with the traffic flows.  I understand that there is useful information. 
The motivation given in the draft seems to apply to more cases than I 
thought, but still it is of limited applicability.

More importantly is the question of whether the proposed method is the 
right way to get the information.  As the draft acknowledges, there are 
other ways to get the information.  Ways that do not need new router 
software much less modifications of the fast path.
There is an argument in the draft about timeliness.  At least for the 
use case document in the draft, that argument does not hold water.

Yours,
Joel

On 4/15/18 10:45 PM, Aijun Wang wrote:
>     Hi, Joel:
> 
>     Can we consider this draft from other viewpoints? If the router can
>     report and correlate the traffic with its associated community, the
>     usage of the community to differentiate the customer, the service
>     category that be accessed and the geographical region etc. will be
>     flourished.
> 
>     And currently, China Telecom has some internal usage regulation for
>     community to differentiate some important customers and the related
>     services.
> 
>     Best Regards.
> 
>     Aijun Wang
> 
>     Network R&D and Operation Support Department
> 
>     China Telecom Corporation Limited Beijing Research
>     Institute,Beijing, China.
> 
> *From:*Joel Halpern 
> 
> *Date:* 2018-04-13 22:44
> 
> *To:*rtg-dir@ietf.org 
> 
> *CC:*draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org 
> ; 
> ietf@ietf.org ; opsawg@ietf.org 
> ; gen-art@ietf.org 
> 
> *Subject:* Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
> 
> Reviewer: Joel Halpern
> 
> Review result: Not Ready
> 
> This is both a gen-art re-review and a routing directorate requested review.
> 
> The revisions from draft-04 to -06 show some improvement.  However, I still
> 
> have serious problems with this work.
> 
> The primary problem is that this seems to violate the designed work
> 
> distribution in the IPFIX architecture.  The draft itself notes that the
> 
> correlation requested could be done in the collector.  Which is where
> 
> correlation is designed to be done.  Instead, it puts a significant new
> 
> processing load on the router that is delivering the IPFIX information.  For
> 
> example, if one delivers IPFIX from the router data plane, one either has to
> 
> modify the router architecture to include additional complex computed
> 
> information in the data plane architecture (a bad place to add 
> complexity) or
> 
> one has to give up and move all the information through the control 
> plane.  And
> 
> even the control plane likely has to add complexity to its RIB logic, as 
> it has
> 
> to move additional information from BGP to the common structures.
> 
> The secondary problem is that this additional work is justified for the 
> router
> 
> by the claim that the unusual usage of applying community tags for 
> geographical
> 
> location of customers is a common practice.  It is a legal practice.  And I
> 
> presume it is done somewhere or the authors would not be asking for 
> it.   But
> 
> it is not common.
> 
> In short, since even the draft admits that this is not needed, I recommend
> 
> against publishing this document as an RFC.
> 


From nobody Sun Apr 15 20:43:52 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526921204DA; Sun, 15 Apr 2018 20:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 A8A7sDZLh1Mi; Sun, 15 Apr 2018 20:43:33 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 681BC12D77C; Sun, 15 Apr 2018 20:43:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 526104E0063; Sun, 15 Apr 2018 20:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523850213; bh=JP6L/BA1q+07hOP3Jbu6apBVqwljguSzU01P1LHnvG0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kmtXZdG957CHYzPq9nf6tHSvC20dyy7oVB4fkv9oQbGnEHxppi0eILDitWwtXA1FG HwtZbkMBvZob3v6lhssqnwaFhkHS1ghf+Y9bV6peVIS5H51l5oJ1XHExJpZOzhufBl vgZZnjNVmn7G+a87tp5r1CU+2Iv6EdQfD1PiJ4dw=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 27DDD1C0B99; Sun, 15 Apr 2018 20:43:32 -0700 (PDT)
To: "Dongjie (Jimmy)" , "rtg-dir@ietf.org" 
Cc: "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com> <76CD132C3ADEF848BD84D028D243C927983DA81F@NKGEML515-MBX.china.huawei.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Sun, 15 Apr 2018 23:43:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927983DA81F@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] [RTG-DIR] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 03:43:35 -0000

Thank you Jimmy.
While I disagree, I think this states the case clearly enough for it to 
be up to the working group and relevant ADs.

Yours,
Joel

On 4/15/18 11:40 PM, Dongjie (Jimmy) wrote:
> Hi Joel,
> 
> Thanks a lot for your review comments.
> 
> Regarding your first problem, I don't think this draft introduces "significant new processing load on the router", as similar processing has already been done for the BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the BGP-community based traffic collection is done by BGP lookup and correlating the BGP community with the flow data to be exported. Whether it is done in data plane or control plane is implementation specific and IMO does not belong to a IETF document.
> 
> As for your second problem, as many operators have pointed out, it is a common case to use BGP communities to represent geo locations at various granularities. So we need to provide them the tools to meet their requirements. Standardizing the IEs for BGP community is a good start.
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Joel Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Friday, April 13, 2018 10:44 PM
>> To: rtg-dir@ietf.org
>> Cc: draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org; ietf@ietf.org;
>> opsawg@ietf.org; gen-art@ietf.org
>> Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
>>
>> Reviewer: Joel Halpern
>> Review result: Not Ready
>>
>> This is both a gen-art re-review and a routing directorate requested review.
>>
>> The revisions from draft-04 to -06 show some improvement.  However, I still
>> have serious problems with this work.
>>
>> The primary problem is that this seems to violate the designed work
>> distribution in the IPFIX architecture.  The draft itself notes that the
>> correlation requested could be done in the collector.  Which is where
>> correlation is designed to be done.  Instead, it puts a significant new
>> processing load on the router that is delivering the IPFIX information.  For
>> example, if one delivers IPFIX from the router data plane, one either has to
>> modify the router architecture to include additional complex computed
>> information in the data plane architecture (a bad place to add complexity) or
>> one has to give up and move all the information through the control plane.
>> And even the control plane likely has to add complexity to its RIB logic, as it has
>> to move additional information from BGP to the common structures.
>>
>> The secondary problem is that this additional work is justified for the router by
>> the claim that the unusual usage of applying community tags for geographical
>> location of customers is a common practice.  It is a legal practice.  And I
>> presume it is done somewhere or the authors would not be asking for it.   But
>> it is not common.
>>
>> In short, since even the draft admits that this is not needed, I recommend
>> against publishing this document as an RFC.
> 


From nobody Sun Apr 15 21:00:49 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA108126B6D; Sun, 15 Apr 2018 21:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 6EeETSC_zRH8; Sun, 15 Apr 2018 21:00:36 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A001204DA; Sun, 15 Apr 2018 21:00:36 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f7vJd-0005Xe-Co; Mon, 16 Apr 2018 04:00:29 +0000
Date: Sun, 15 Apr 2018 21:00:28 -0700
Message-ID: 
From: Randy Bush 
To: Tianran Zhou 
Cc: "Joel M. Halpern" , heasley , li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , opsawg , "ietf@ietf.org" 
In-Reply-To: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>  
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 04:00:38 -0000

> As far as I can see, this document proposed a new aggregation
> parameter for IPFIX. So that the operators can get the traffic
> statistic from a new dimension.
>
> Because "Flow information based on IP address or IP prefix may provide
> much too fine granularity for a large network. On the contrary, flow
> information based on AS number may be too coarse."
>
> It sounds reasonable.

iff i can select which community's or communities' values form the
sampling bucket(s), this seems reasonable.  if i am community
transparent, i probably don't want a bucket for each community on my
inbound set.

randy


From nobody Sun Apr 15 22:36:26 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5DE120713; Sun, 15 Apr 2018 22:36:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152385698018.20910.10340923023725081369.idtracker@ietfa.amsl.com>
Date: Sun, 15 Apr 2018 22:36:20 -0700
Archived-At: 
Subject: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 05:36:20 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-opsawg-mud-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

§1.6, 2nd paragraph: Why is the SHOULD not a MUST?

§1.8, 4th paragraph: "The web server is typically run by or on behalf of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownership.

Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a reader
of the abstract in isolation from the rest of the document. (Abstracts should
be able to stand alone.)

§1.1 : first paragraph: The idea that a Thing might have highly restricted
communication patterns seems core to the document. It would be helpful to
mention that earlier in §1.

§1.3, definition of "Manufacturer": The definition says that "Manufacturer" may
not necessarily be the entity that constructed the Thing. But that's the plain
English meaning of the word "manufacturer". If you don't want it to mean that,
please consider choosing a different term. ( for example, "authority")

§1.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities"
should have been "requirements"?

§1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and
otherwise difficult to parse.

§1.9, list item 7:  are we talking about transient disconnect or permanent
removal?

§2: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

§3.8, 2nd sentence: Consider reformulating this as a construction of MUST.

§4: The idea of a "default" in bullet 2 seems in tension with the idea of
"Anything not explicitly permitted is forbidden" in bullet 1.

§14: Please define the concept of "east-west infection".



From nobody Sun Apr 15 23:27:23 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76E12711B; Sun, 15 Apr 2018 23:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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
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 dCpiWpeQQ1MD; Sun, 15 Apr 2018 23:27:14 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99010127058; Sun, 15 Apr 2018 23:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19819; q=dns/txt; s=iport; t=1523860034; x=1525069634; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=E1IeZLhCncAQjWu5zusGpZ88tF0ZP9TKJ37VFeuWqqA=; b=UGOsnbH00H8L3bue6QOIbHU8+ZJp1SojuMXo6DcCmFzjuPVxoQl7owCw JxkAcl7k5xeKHqq/v0tcIiHZo6IjBVmu+/j/Hzjy0j72ftG/e+KBtY0tA dnY1I1vRdq/NVU9+jpnakamIxzqMucPzJ2vZ0XOOKubXT7BWbTcDizgOq I=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,458,1517875200";  d="asc'?scan'208,217";a="3165276"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 06:27:11 +0000
Received: from [10.61.83.172] (ams3-vpn-dhcp5037.cisco.com [10.61.83.172]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3G6R9j9016943; Mon, 16 Apr 2018 06:27:09 GMT
To: Eric Rescorla 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com> 
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>
Date: Mon, 16 Apr 2018 08:27:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pw65UXkCSB05A0PyMjlOpd27nqDBfo0vS"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 06:27:17 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pw65UXkCSB05A0PyMjlOpd27nqDBfo0vS
Content-Type: multipart/mixed; boundary="xPVsO4cyeWO4SEg1pJA9EZgU8W7vB1b0U";
 protected-headers="v1"
From: Eliot Lear 
To: Eric Rescorla 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,
 Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with
 DISCUSS and COMMENT)
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
 <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
 
In-Reply-To: 

--xPVsO4cyeWO4SEg1pJA9EZgU8W7vB1b0U
Content-Type: multipart/alternative;
 boundary="------------727D412589B46B8B073D41B7"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------727D412589B46B8B073D41B7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Eric,

Trimming.


On 15.04.18 21:22, Eric Rescorla wrote:
>
>
>
>
>>     IMPORTANT
>>>          The certificate extension is described below.
>>>
>>>          The information returned by the MUD file server (a web serve=
r) is
>>>          valid for the duration of the Thing's connection, or as spec=
ified in
>>>          the description.  Thus if the Thing is disconnected, any ass=
ociated
>>>          configuration in the switch can be removed.  Similarly, from=
 time to
>>     IMPORTANT: What does "disconnected" mean in this context? Does a
>>     reboot count? What if I am wireless? This is a critical question i=
f
>>     MUD is intended as a post-compromise mechanism. Say that an attack=
er
>>     compromises the firmware for a device and then forces a reboot
>>     followed by a 2 hour pause before the wireless NIC is activated. W=
ill
>>     this result in configuration removal? If so, MUD seems of limited =
use,
>>     because it can then make itself appear to be a new device with a n=
ew
>>     MUD configuration. (This is of course true in general in a wireles=
s
>>     context if the firmware can change the client's L2 address).
>
>     Yes, configuration is intended to be removed when a device
>     disconnects or a session terminates.=C2=A0 This would be considered=

>     normal garbage collection.=C2=A0 But whether or not you can simply
>     replace the firmware and gain the same access will depend on how
>     the MUD-URL is learned.=C2=A0 If it is in a manufacturer certificat=
e,
>     for instance, that's not something an attacker will easily
>     replace.=C2=A0 If the assertion is coming via LLDP, or DHCP, then o=
ne
>     has to apply the mitigations discussed in the security
>     considerations section (and they are numerous).
>
>
> I'm not following you here. Say it's in a manufacturer certificate,
> what stops me from getting my own certificate for Attacker LLC and
> then serving a wide open policy? The mitigations don't really seem to
> do much to counteract this.

I believe this point and one down below, where you write:
> This doesn't seem to address my concern, which is that there's no
> realistic way of knowing
> what trust anchors apply. If it's not WebPKI, then what?=20
are related, and so I propose to address them together, and this text
could go into security considerations.=C2=A0 The *intent* is that mud
managers or their providers will keep a list of known trusted signers.=C2=
=A0
Examples are likely to include certification bodies (we are aware of at
least one that is very interested), the MUD manager vendor themselves,
and perhaps others.=C2=A0 Because these are early days, I don't want to b=
e
too declarative, but we can say this:

NEW:

---
MUD managers and their administrators MUST NOT automatically trust a
manufacturer's certificate simply because it validates.=C2=A0 Rather, the=

certificate MUST be signed by an entity that has previously established
trust for this explicit purpose.=C2=A0 In particular, the WebPKI alone is=
 not
appropriate.
---


That means that just because Joe Evil signed the darn thing doesn't mean
that we should believe it.=C2=A0 On the other hand, I might trust a secur=
ity
company to vet this stuff.=C2=A0 Would this address your concern?=C2=A0 A=
lso, I'll
correct the previous factual error.

And again, I view this as early days.=C2=A0 The architecture is going to =
need
some time to mature and evolve.


>
>
>
>
>>     ------------------------------------------------------------------=
----
>>     COMMENT:
>>     ------------------------------------------------------------------=
----
>>
>>
>>>       Abstract
>>>
>>>          This memo specifies a component-based architecture for manuf=
acturer
>>>          usage descriptions (MUD).  The goal of MUD is to provide a m=
eans for
>>>          Things to signal to the network what sort of access and netw=
ork
>>     I realize that "Things" has become a marketing term, but it's opaq=
ue
>>     and unnecessary here. "elements" would be the conventional term.
>
>     How about "end devices"?=C2=A0 That makes it clear in the abstract.=
=C2=A0 I
>     don't propose to do a global substitute, because we scope the term
>     well in the introduction, as you note directly below.
>
>
> To be honest, I would do a search and replace, but I agree that theis
> would resolve the ambiguity here.
>
>
>>>          it continues to make sense for general purpose computing dev=
ices
>>>          today, including laptops, smart phones, and tablets.
>>>
>>>          [RFC7452] discusses design patterns for, and poses questions=
 about,
>>>          smart objects.  Let us then posit a group of objects that ar=
e
>>>          specifically not general purpose computers.  These devices, =
which
>>     I don't think this makes sense. These devices usually *are* genera=
l
>>     purpose computers (turing complete, etc.)
>
>     That these objects might happen to use a general purpose CPU or
>     operations system doesn't in and of itself make them general
>     purpose devices.=C2=A0 As a complete SKU they are sold with a singl=
e or
>     small number of uses in mind.=C2=A0 That is what is posited.=C2=A0 =
Is there
>     a way to make that clearer?
>
>
> Perhaps "not intended to be used for general purpose computing tasks"

Ok.

>
>
>>>          specifically not general purpose computers.  These devices, =
which
>>>          this memo refers to as Things, have a specific purpose.  By
>>>          definition, therefore, all other uses are not intended.  The=

>>>          combination of these two statements can be restated as a man=
ufacturer
>>>          usage description (MUD) that can be applied at various point=
s within
>>>          a network.
>>     I would make the point here that the purpose of the MUD is to desc=
ribe
>>     the communications pattern. You only really get that by the statem=
ent
>>     in S 1.1 that the communication pattern of other devices is too
>>     complicated to profile.
>
>     I think this statement is predicated on your previous comment, and
>     would prefer not to change text at this time.
>
>
> Hmmm.... No, I don't think you're reading me right here. I'm just
> saying that it would be useful upfront to say that MUD
> is about saying "this is what communications pattern these devices are
> expected to have"

Ok.=C2=A0 I think that's a good add, and propose to add a statement based=
 on
your quoted text.

Thanks again,

Eliot

--------------727D412589B46B8B073D41B7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Eric,

    
Trimming.

    

    

    
On 15.04.18 21:22, Eric Rescorla wrote=
:

    

    

      
      


        


          

            
 

            

            

              
=
 

                  

                    
IMPORTANT


                    

                      
     The certificate extension is described be=
low.

     The information returned by the MUD file server (a web server) is
     valid for the duration of the Thing's connection, or as specified in=

     the description.  Thus if the Thing is disconnected, any associated
     configuration in the switch can be removed.  Similarly, from time to=



                    

                    
IMPORTANT: What does "disconnected" mean in this=
 context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).

                  

                  

                 Yes, configuration is intended to be removed
                when a device disconnects or a session terminates.=C2=A0 =
This
                would be considered normal garbage collection.=C2=A0 But
                whether or not you can simply replace the firmware and
                gain the same access will depend on how the MUD-URL is
                learned.=C2=A0 If it is in a manufacturer certificate, fo=
r
                instance, that's not something an attacker will easily
                replace.=C2=A0 If the assertion is coming via LLDP, or DH=
CP,
                then one has to apply the mitigations discussed in the
                security considerations section (and they are numerous).
                

              

            

            


            

            
I'm not following you here. Say it's in a manufacturer
              certificate, what stops me from getting my own certificate
              for Attacker LLC and then serving a wide open policy? The
              mitigations don't really seem to do much to counteract
              this.

            

          

        

      

    

    

    I believe this point and one down below, where you write:

    

      
This doesn't seem to address my concern, which is that
        there's no realistic way of knowing

      what trust anchors apply. If it's not WebPKI, then what? 
    are related, and so I propose to address them together, and this
    text could go into security considerations.=C2=A0 The *intent* is tha=
t
    mud managers or their providers will keep a list of known trusted
    signers.=C2=A0 Examples are likely to include certification bodies (w=
e
    are aware of at least one that is very interested), the MUD manager
    vendor themselves, and perhaps others.=C2=A0 Because these are early
    days, I don't want to be too declarative, but we can say this:

    

    NEW:

    

    ---

    MUD managers and their administrators MUST NOT automatically trust a
    manufacturer's certificate simply because it validates.=C2=A0 Rather,=
 the
    certificate MUST be signed by an entity that has previously
    established trust for this explicit purpose.=C2=A0 In particular, the=

    WebPKI alone is not appropriate. 

    ---

    

    

    That means that just because Joe Evil signed the darn thing doesn't
    mean that we should believe it.=C2=A0 On the other hand, I might trus=
t a
    security company to vet this stuff.=C2=A0 Would this address your
    concern?=C2=A0 Also, I'll correct the previous factual error.

    

    And again, I view this as early days.=C2=A0 The architecture is going=
 to
    need some time to mature and evolve.

    

    

    

      

        

          

            


            

            


            

            


            

            

              
=
 

                  

                    
-------------------------------------------=
---------------------------
COMMENT:
---------------------------------------------------------------=
-------




                    

                      
  Abstract

     This memo specifies a component-based architecture for manufacturer
     usage descriptions (MUD).  The goal of MUD is to provide a means for=

     Things to signal to the network what sort of access and network


                    

                    
I realize that "Things" has become a marketing t=
erm, but it's opaque
and unnecessary here. "elements" would be the conventional term.

                  

                  

                 How about "end devices"?=C2=A0 That makes it clea=
r in
                the abstract.=C2=A0 I don't propose to do a global
                substitute, because we scope the term well in the
                introduction, as you note directly below.

                

            

            


            

            
To be honest, I would do a search and replace, but I
              agree that theis would resolve the ambiguity here. 

            

            

              
=
 

                  

                    

                      
     it continues to make sense for general pu=
rpose computing devices
     today, including laptops, smart phones, and tablets.

     [RFC7452] discusses design patterns for, and poses questions about,
     smart objects.  Let us then posit a group of objects that are
     specifically not general purpose computers.  These devices, which


                    

                    
I don't think this makes sense. These devices us=
ually *are* general
purpose computers (turing complete, etc.)

                  

                  

                 That these objects might happen to use a general
                purpose CPU or operations system doesn't in and of
                itself make them general purpose devices.=C2=A0 As a comp=
lete
                SKU they are sold with a single or small number of uses
                in mind.=C2=A0 That is what is posited.=C2=A0 Is there a =
way to
                make that clearer?

                

            

            


            

            
Perhaps "not intended to be used for general purpose
              computing tasks" 

            

          

        

      

    

    

    Ok.

    

    

      

        

          

            

              
=
 

                  

                  

                    

                      
     specifically not general purpose computer=
s.  These devices, which
     this memo refers to as Things, have a specific purpose.  By
     definition, therefore, all other uses are not intended.  The
     combination of these two statements can be restated as a manufacture=
r
     usage description (MUD) that can be applied at various points within=

     a network.


                    

                    
I would make the point here that the purpose of =
the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.

                  

                  

                 I think this statement is predicated on your
                previous comment, and would prefer not to change text at
                this time.

                

            

            


            

            
Hmmm.... No, I don't think you're reading me right
              here. I'm just saying that it would be useful upfront to
              say that MUD

            
is about saying "this is what communications pattern
              these devices are expected to have"

            

          

        

      

    

    

    Ok.=C2=A0 I think that's a good add, and propose to add a statement b=
ased
    on your quoted text.

    

    Thanks again,

    

    Eliot

  


--------------727D412589B46B8B073D41B7--

--xPVsO4cyeWO4SEg1pJA9EZgU8W7vB1b0U--

--pw65UXkCSB05A0PyMjlOpd27nqDBfo0vS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrUQjwACgkQh7ZrRtnS
ejNo5ggAnsPNmSTK/QHI4R77no2It6+Sq+XCD3ZOt/M/3+ahO4eINLZIkFZ3ff/d
Pmfxy7nUBz7Za7oGu1mKEgMvewQ5NC1sei28z8tBTilrpmJXW3LMEic30QexCmqU
CKeHil7Dbh8nmQu6vtvXxC9rtbxbdcBy+MZyRFh9gKgeeXMBzhB8N/e+/BdJLDyU
/xthRz9FDgVkyfHud7CUzpfDq3B2fpcP7V1uRM/+2dxul/mio/yRcAUunIC0fwX+
OOeVFMMQEIR/FCjdEGDkNafbdTWvFe2W9vbvrI9H7+0jqIgpNUxTmlaKEtXqV2cr
6B8X5DFIKZzmkSEjmKbRXAXtlH8rDg==
=sI1E
-----END PGP SIGNATURE-----

--pw65UXkCSB05A0PyMjlOpd27nqDBfo0vS--


From nobody Mon Apr 16 00:46:18 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC82B1241F8; Mon, 16 Apr 2018 00:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ybKt9J3wdMsB; Mon, 16 Apr 2018 00:46:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 655331205D3; Mon, 16 Apr 2018 00:46:06 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 18D2650839812; Mon, 16 Apr 2018 08:46:00 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 16 Apr 2018 08:45:54 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Mon, 16 Apr 2018 15:45:47 +0800
From: Tianran Zhou 
To: Randy Bush 
CC: "Joel M. Halpern" , heasley , li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , opsawg , "ietf@ietf.org" 
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT0zX1x60GZaZE206pZAQJbOzf56QBe9sAgAAGZYCAATo/QP//heIAgAC/6OA=
Date: Mon, 16 Apr 2018 07:45:46 +0000
Message-ID: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>   
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 07:46:08 -0000

> iff i can select which community's or communities' values form the sampli=
ng
> bucket(s), this seems reasonable.  if i am community transparent, i proba=
bly
> don't want a bucket for each community on my inbound set.

Yes, this sounds better. It can be achieved by configuring the intermediate=
 process as in RFC6183.=20
This could be a more reasonable use case for the new IE.

Tianran


From nobody Mon Apr 16 05:25:58 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4466312D882 for ; Mon, 16 Apr 2018 05:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 JownniK2jT4Q for ; Mon, 16 Apr 2018 05:25:45 -0700 (PDT)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C7B12DA2C for ; Mon, 16 Apr 2018 05:25:45 -0700 (PDT)
Received: by mail-ot0-x22d.google.com with SMTP id h8-v6so6029125otj.7 for ; Mon, 16 Apr 2018 05:25:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O8pzmVh/PfKKyWxE6WFjUkm3nTgAST/UheywVOjnUzg=; b=Hz3lT/I8dZvKbA6CSiFa5XItuSGPCTPd6jOIboQkG6Uwg482yIuVzOf1jplSQba/hS ZjtgStzyFjaJDHiZKkCjEXYzx0HMkJVPgUc+sjCR10wp/ilTPZIpOWN4M7VJmLNLv2ZQ SKHZLvcN8QmunhYiIs7cscLWMLsUxF2TF/OkWJQbWXeSzo9UQh17pIhS/wxak7AVv3YM 7itD4EGW57A/+SoVhvMQ53A+LyF8yes5MHxI57pxEd2uSCkOm8KYoSq4ONNzS99qPYdK Lu8sTAGVAVApAGKIHDQhI8XL2w1L/s4mOAdK7r/eRHaIb4YlBcXsTnhTFAgzQdBEXicw jpRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O8pzmVh/PfKKyWxE6WFjUkm3nTgAST/UheywVOjnUzg=; b=uMIbZ7qlTOB7APaZFYXAu9F9L7IMPR6WRtGy9qXC/MIJMkDvuLu1PToJiHXv+lLiDN XEU3Ar5uQs+jtTk+ZoSuSty1m9+jyJgMSGdNDNdokvR29Z4uUPcu+KaBteb1sY/mt+sy qjqh6XaJBeyfec2qpuGwkMEvM47I3Ba2Gs1Yn32guPOnYyZb2s6lejcuh4UTbwoUhm1l qAEEzibJnkNgUcghoHMqD4y15U8Qg9ZDb+y8+zaEQ1CE2k1XzjSCfXZDp/K1MWPxLwhM 5HFhHqVgd6ouh9Ygc/mZH4X7RjIzawCGmmtl0blhHm33Fjq+ttqSkLVkNlL3ydCx3S7W gDjQ==
X-Gm-Message-State: ALQs6tD5pxP0dayydtgZ+VJaCz4ivo4mTjj/IGGxglXl+jT6O/a6QD5e vtDN+H3lrANG6604CvghDeBvHQDNSthsBFDH3Qi0hQ==
X-Google-Smtp-Source: AIpwx4+h18DSZxRXyRC/WYXD2wWu+fkbq3XBqwn6djpKLSCGDOMKvjAelS51nFHA6wRAzNpyzAHHmnb9tcVnaoaJwpM=
X-Received: by 2002:a9d:3ec6:: with SMTP id b64-v6mr1475526otc.371.1523881544482;  Mon, 16 Apr 2018 05:25:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 05:25:04 -0700 (PDT)
In-Reply-To: <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>  <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>
From: Eric Rescorla 
Date: Mon, 16 Apr 2018 05:25:04 -0700
Message-ID: 
To: Eliot Lear 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,  Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002395770569f6521e"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 12:25:49 -0000

--0000000000002395770569f6521e
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,

Thanks for continuing the conversation. My question is how this fits into
the system as a whole.

ISTM that there are two ways in which a MUD policy can affect the network's
behavior:

- Additive -- it lets the device do things it otherwise might not be
permitted to do (e.g., accept incoming TCP connections)
- Restrictive -- it stops the device from doing things that it otherwise
would be permitted to do (e.g., make connections to IP addresses on non-443
ports)

In the former case, it's very important not to be able to forge acceptable
MUD policies, but in the latter case, an attacker can just not serve *any*
MUD policy and be in a stronger position than they would be if they had a
valid policy, Thus, it's only in the former (additive) case where forging a
policy is useful to the attacker, and, in fact, it seems like accepting an
unsigned MUD policy would be better than no policy. Given the ubiquity of
non-MUD devices and the relatively limited capabilities that MUD seems to
want to convey, it seems like the additive case isn't very useful.

I should mention one use case that I did think of, where additive would be
immediately useful: "This device is made by the same manufacturer as
another device (and hence they can talk to each other). However, I note
that MUD is actually not capable of securely conveying that, because
there's no proof that the device in hand actually is made by the
manufacturer, only that it possesses a public credential for some device
made by that manufacturer. So, I'm actually left wondering how that feature
is intended to work. I regret not catching this earlier, but perhaps you
could explain?

Thanks,
-Ekr


On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear  wrote:

> Hi Eric,
>
> Trimming.
>
> On 15.04.18 21:22, Eric Rescorla wrote:
>
>
>
>
>
>> IMPORTANT
>>
>>      The certificate extension is described below.
>>
>>      The information returned by the MUD file server (a web server) is
>>      valid for the duration of the Thing's connection, or as specified in
>>      the description.  Thus if the Thing is disconnected, any associated
>>      configuration in the switch can be removed.  Similarly, from time to
>>
>> IMPORTANT: What does "disconnected" mean in this context? Does a
>> reboot count? What if I am wireless? This is a critical question if
>> MUD is intended as a post-compromise mechanism. Say that an attacker
>> compromises the firmware for a device and then forces a reboot
>> followed by a 2 hour pause before the wireless NIC is activated. Will
>> this result in configuration removal? If so, MUD seems of limited use,
>> because it can then make itself appear to be a new device with a new
>> MUD configuration. (This is of course true in general in a wireless
>> context if the firmware can change the client's L2 address).
>>
>>
>> Yes, configuration is intended to be removed when a device disconnects or
>> a session terminates.  This would be considered normal garbage collection.
>> But whether or not you can simply replace the firmware and gain the same
>> access will depend on how the MUD-URL is learned.  If it is in a
>> manufacturer certificate, for instance, that's not something an attacker
>> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
>> one has to apply the mitigations discussed in the security considerations
>> section (and they are numerous).
>>
>
> I'm not following you here. Say it's in a manufacturer certificate, what
> stops me from getting my own certificate for Attacker LLC and then serving
> a wide open policy? The mitigations don't really seem to do much to
> counteract this.
>
>
> I believe this point and one down below, where you write:
>
> This doesn't seem to address my concern, which is that there's no
> realistic way of knowing
> what trust anchors apply. If it's not WebPKI, then what?
>
> are related, and so I propose to address them together, and this text
> could go into security considerations.  The *intent* is that mud managers
> or their providers will keep a list of known trusted signers.  Examples are
> likely to include certification bodies (we are aware of at least one that
> is very interested), the MUD manager vendor themselves, and perhaps
> others.  Because these are early days, I don't want to be too declarative,
> but we can say this:
>
> NEW:
>
> ---
> MUD managers and their administrators MUST NOT automatically trust a
> manufacturer's certificate simply because it validates.  Rather, the
> certificate MUST be signed by an entity that has previously established
> trust for this explicit purpose.  In particular, the WebPKI alone is not
> appropriate.
> ---
>
>
> That means that just because Joe Evil signed the darn thing doesn't mean
> that we should believe it.  On the other hand, I might trust a security
> company to vet this stuff.  Would this address your concern?  Also, I'll
> correct the previous factual error.
>
> And again, I view this as early days.  The architecture is going to need
> some time to mature and evolve.
>
>
>
>
>
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>>   Abstract
>>
>>      This memo specifies a component-based architecture for manufacturer
>>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>>      Things to signal to the network what sort of access and network
>>
>> I realize that "Things" has become a marketing term, but it's opaque
>> and unnecessary here. "elements" would be the conventional term.
>>
>>
>> How about "end devices"?  That makes it clear in the abstract.  I don't
>> propose to do a global substitute, because we scope the term well in the
>> introduction, as you note directly below.
>>
>
> To be honest, I would do a search and replace, but I agree that theis
> would resolve the ambiguity here.
>
>>
>>      it continues to make sense for general purpose computing devices
>>      today, including laptops, smart phones, and tablets.
>>
>>      [RFC7452] discusses design patterns for, and poses questions about,
>>      smart objects.  Let us then posit a group of objects that are
>>      specifically not general purpose computers.  These devices, which
>>
>> I don't think this makes sense. These devices usually *are* general
>> purpose computers (turing complete, etc.)
>>
>>
>> That these objects might happen to use a general purpose CPU or
>> operations system doesn't in and of itself make them general purpose
>> devices.  As a complete SKU they are sold with a single or small number of
>> uses in mind.  That is what is posited.  Is there a way to make that
>> clearer?
>>
>
> Perhaps "not intended to be used for general purpose computing tasks"
>
>
> Ok.
>
>
>>
>>      specifically not general purpose computers.  These devices, which
>>      this memo refers to as Things, have a specific purpose.  By
>>      definition, therefore, all other uses are not intended.  The
>>      combination of these two statements can be restated as a manufacturer
>>      usage description (MUD) that can be applied at various points within
>>      a network.
>>
>> I would make the point here that the purpose of the MUD is to describe
>> the communications pattern. You only really get that by the statement
>> in S 1.1 that the communication pattern of other devices is too
>> complicated to profile.
>>
>>
>> I think this statement is predicated on your previous comment, and would
>> prefer not to change text at this time.
>>
>
> Hmmm.... No, I don't think you're reading me right here. I'm just saying
> that it would be useful upfront to say that MUD
> is about saying "this is what communications pattern these devices are
> expected to have"
>
>
> Ok.  I think that's a good add, and propose to add a statement based on
> your quoted text.
>
> Thanks again,
>
> Eliot
>

--0000000000002395770569f6521e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

Thanks for continu=
ing the conversation. My question is how this fits into the system as a who=
le.

ISTM that there are two ways in which a MUD po=
licy can affect the network's behavior:

- Addi=
tive -- it lets the device do things it otherwise might not be permitted to=
 do (e.g., accept incoming TCP connections)
- Restrictive -- =
it stops the device from doing things that it otherwise would be permitted =
to do (e.g., make connections to IP addresses on non-443 ports)
<=
br>
In the former case, it's very important not to be able to=
 forge acceptable MUD policies, but in the latter case, an attacker can jus=
t not serve *any* MUD policy and be in a stronger position than they would =
be if they had a valid policy, Thus, it's only in the former (additive)=
 case where forging a policy is useful to the attacker, and, in fact, it se=
ems like accepting an unsigned MUD policy would be better than no policy. G=
iven the ubiquity of non-MUD devices and the relatively limited capabilitie=
s that MUD seems to want to convey, it seems like the additive case isn'=
;t very useful.

I should mention one use case that=
 I did think of, where additive would be immediately useful: "This dev=
ice is made by the same manufacturer as another device (and hence they can =
talk to each other). However, I note that MUD is actually not capable of se=
curely conveying that, because there's no proof that the device in hand=
 actually is made by the manufacturer, only that it possesses a public cred=
ential for some device made by that manufacturer. So, I'm actually left=
 wondering how that feature is intended to work. I regret not catching this=
 earlier, but perhaps you could explain?

Thank=
s,
-Ekr

=

On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear=
 <=
lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Eric,

    
Trimming.

    

    

    
On 15.04.18 21:22, =
Eric Rescorla wrote:

    

    

     =20
      


        


          

            
 

            

            

              
 

                  

                    
IMPORTANT


                    

                      
     The certificate extension is described belo=
w.

     The information returned by the MUD file server (a web server) is
     valid for the duration of the Thing's connection, or as specified =
in
     the description.  Thus if the Thing is disconnected, any associated
     configuration in the switch can be removed.  Similarly, from time to


                    

                    
IMPORTANT: What does "disconnected" mean=
 in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).

                  

                  

                 Yes, configuration is intended to be removed
                when a device disconnects or a session terminates.=C2=A0 Th=
is
                would be considered normal garbage collection.=C2=A0 But
                whether or not you can simply replace the firmware and
                gain the same access will depend on how the MUD-URL is
                learned.=C2=A0 If it is in a manufacturer certificate, for
                instance, that's not something an attacker will easily
                replace.=C2=A0 If the assertion is coming via LLDP, or DHCP=
,
                then one has to apply the mitigations discussed in the
                security considerations section (and they are numerous).
                

              

            

            


            

            
I'm not following you here. Say it's in a manufact=
urer
              certificate, what stops me from getting my own certificate
              for Attacker LLC and then serving a wide open policy? The
              mitigations don't really seem to do much to counteract
              this.

            

          

        

      

    

    

    I believe this point and one down below, where you write:

    

      
This doesn't seem to address my concern, which is that
        there's no realistic way of knowing

      what trust anchors apply. If it's not WebPKI, then what? 
    are related, and so I propose to address them together, and this
    text could go into security considerations.=C2=A0 The *intent* is that
    mud managers or their providers will keep a list of known trusted
    signers.=C2=A0 Examples are likely to include certification bodies (we
    are aware of at least one that is very interested), the MUD manager
    vendor themselves, and perhaps others.=C2=A0 Because these are early
    days, I don't want to be too declarative, but we can say this:

    

    NEW:

    

    ---

    MUD managers and their administrators MUST NOT automatically trust a
    manufacturer's certificate simply because it validates.=C2=A0 Rathe=
r, the
    certificate MUST be signed by an entity that has previously
    established trust for this explicit purpose.=C2=A0 In particular, the
    WebPKI alone is not appropriate. 

    ---

    

    

    That means that just because Joe Evil signed the darn thing doesn't
    mean that we should believe it.=C2=A0 On the other hand, I might trust =
a
    security company to vet this stuff.=C2=A0 Would this address your
    concern?=C2=A0 Also, I'll correct the previous factual error.

    

    And again, I view this as early days.=C2=A0 The architecture is going t=
o
    need some time to mature and evolve.

    

    

    

      

        

          

            


            

            


            

            


            

            

              
 

                  

                    
---------------------------------------------=
-------------------------
COMMENT:
-----------------------------------------------------------------=
-----




                    

                      
  Abstract

     This memo specifies a component-based architecture for manufacturer
     usage descriptions (MUD).  The goal of MUD is to provide a means for
     Things to signal to the network what sort of access and network


                    

                    
I realize that "Things" has become a mar=
keting term, but it's opaque
and unnecessary here. "elements" would be the conventional term.<=
/pre>
                  

                  

                 How about "end devices"?=C2=A0 That makes=
 it clear in
                the abstract.=C2=A0 I don't propose to do a global
                substitute, because we scope the term well in the
                introduction, as you note directly below.

                

            

            


            

            
To be honest, I would do a search and replace, but I
              agree that theis would resolve the ambiguity here. 

            

            

              
 

                  

                    

                      
     it continues to make sense for general purp=
ose computing devices
     today, including laptops, smart phones, and tablets.

     [RFC7452] discusses design patterns for, and poses questions about,
     smart objects.  Let us then posit a group of objects that are
     specifically not general purpose computers.  These devices, which


                    

                    
I don't think this makes sense. These devices =
usually *are* general
purpose computers (turing complete, etc.)

                  

                  

                 That these objects might happen to use a general
                purpose CPU or operations system doesn't in and of
                itself make them general purpose devices.=C2=A0 As a comple=
te
                SKU they are sold with a single or small number of uses
                in mind.=C2=A0 That is what is posited.=C2=A0 Is there a wa=
y to
                make that clearer?

                

            

            


            

            
Perhaps "not intended to be used for general purpose
              computing tasks" 

            

          

        

      

    

    

    Ok.

    

    

      

        

          

            

              
 

                  

                  

                    

                      
     specifically not general purpose computers.=
  These devices, which
     this memo refers to as Things, have a specific purpose.  By
     definition, therefore, all other uses are not intended.  The
     combination of these two statements can be restated as a manufacturer
     usage description (MUD) that can be applied at various points within
     a network.


                    

                    
I would make the point here that the purpose of th=
e MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.

                  

                  

                 I think this statement is predicated on your
                previous comment, and would prefer not to change text at
                this time.

                

            

            


            

            
Hmmm.... No, I don't think you're reading me right
              here. I'm just saying that it would be useful upfront to
              say that MUD

            
is about saying "this is what communications pattern
              these devices are expected to have"

            

          

        

      

    

    

    Ok.=C2=A0 I think that's a good add, and propose to add a statement=
 based
    on your quoted text.

    

    Thanks again,

    

    Eliot

  






--0000000000002395770569f6521e--


From nobody Mon Apr 16 06:04:11 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11CA124F57; Mon, 16 Apr 2018 06:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mHqV1XAcWKW0; Mon, 16 Apr 2018 06:04:01 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E6F120227; Mon, 16 Apr 2018 06:04:00 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id i144so5814683ywc.2; Mon, 16 Apr 2018 06:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Beg1JiuXtYVcLXWPe1YMhdIQ7MtM+QTtT/l3O/6xAVo=; b=OEeQXjKDToz0qlKUydA8xo4+Co0O2vck+474PwQ0SOXbLEE1KM+q/G+70EEJjaFrOB AQurRCHRS7Vc4iVM9QDpQbCk6BQfgAnskZZ7HqRS7ANKIFNn9ndgdLVsNWWO6j5hC4yS 6+IriJb2OzSSU7tkSw+JSqjdhpVGWSbq6Iv0EmYQ19ydzIn20mXMdpKWcKEJYhfd4RFf KfykRTc5g1eaq21RjSF8Wx7yeXMVaMZ9F4wHE9PfrhEtTihOwh7pzrqEvQLn+bxWfyAI LG8B+4kq0IzOIXmjpBhuPhhk6zccPP8WsxWlaXLavK5IJw3ihfqJfZQK4vHasgUvyg3D Afmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Beg1JiuXtYVcLXWPe1YMhdIQ7MtM+QTtT/l3O/6xAVo=; b=P647izR0wvu6hAYbutITP16km6cREZz45X/NJc5GOYg11jiVzVZ4MbVn00Copu5kG7 KM8ZIe4JdQCmzMTK4HJ9X6L0UGUR+hibhCiogXodXFWbRYm7JDzd4pd4U2iz9GFlvozL cqzVVvXxmVTyNulMzNcSScGEqiI7GYr/kjfrA7w0pDGg40GG961tbA3BYb3LRMHhR5+K bBwnpAIaZFZfzs29KqC2jU6/FFuX/UHdzZGp6cHPBS5GqVRx0FukAiRaa6a8R5pDlloC WmYiQ9q3h8w3GgsdooSWRNPZQGinzTXZvyNNlQInjc+agXfQuZ7aaemrBOn8xaNByiy8 bPQA==
X-Gm-Message-State: ALQs6tDNG+0vJHgI2a+tszWXuZ3D2neCo6A+z6B72QxQDe/nj7R02Ep3 rNrDsU869/ChGZA2dQhSbFsO9e8Qc/RpJekj7cE=
X-Google-Smtp-Source: AIpwx4995VxFyoRWnTw9DpgIH7ts6X+HO+hgvJ8yRf+l7QWjjGyniNWHCLloRfu4sd5OKje225hNA0/M/TcxZd5sqrE=
X-Received: by 10.129.41.209 with SMTP id p200mr6445363ywp.424.1523883839658;  Mon, 16 Apr 2018 06:03:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:c06:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 06:03:59 -0700 (PDT)
In-Reply-To: 
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>  <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com> 
From: Spencer Dawkins at IETF 
Date: Mon, 16 Apr 2018 08:03:59 -0500
Message-ID: 
To: Eric Rescorla 
Cc: Eliot Lear , draft-ietf-opsawg-mud@ietf.org, opsawg@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, The IESG 
Content-Type: multipart/alternative; boundary="001a11422594f11e8f0569f6da5b"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 13:04:05 -0000

--001a11422594f11e8f0569f6da5b
Content-Type: text/plain; charset="UTF-8"

I haven't balloted yet, and this is EKR's ballot thread, but one point is
worth bringing up here ...

On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla  wrote:

> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits into
> the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it otherwise
> would be permitted to do (e.g., make connections to IP addresses on non-443
> ports)
>

I've read previous versions of this draft and some of the mailing list
discussion, but not a lot. Having said that, I hadn't heard anyone express
the possibility of the additive case described here. The context I always
heard about, was roughly "we've gotta keep all the coke machines on campus
from doing anything except reporting that they need to be refilled", or
whatever variation of cameras, printers, or *mumble* have access to your
network for a specific reason, are running some arbitrary version of some
OS stack that included TCP or UDP capabilities, aren't being maintained
enough to be current on security patches, and aren't being managed, so are
ripe for attacks to create botnets.

Perhaps I need to get out more. Almost certainly. But ... the possibility
of additive policies is interesting, and new to me.

I'll be interested to watch this discussion. Eric, thanks for asking the
question.

Spencer

In the former case, it's very important not to be able to forge acceptable
> MUD policies, but in the latter case, an attacker can just not serve *any*
> MUD policy and be in a stronger position than they would be if they had a
> valid policy, Thus, it's only in the former (additive) case where forging a
> policy is useful to the attacker, and, in fact, it seems like accepting an
> unsigned MUD policy would be better than no policy. Given the ubiquity of
> non-MUD devices and the relatively limited capabilities that MUD seems to
> want to convey, it seems like the additive case isn't very useful.
>
> I should mention one use case that I did think of, where additive would be
> immediately useful: "This device is made by the same manufacturer as
> another device (and hence they can talk to each other). However, I note
> that MUD is actually not capable of securely conveying that, because
> there's no proof that the device in hand actually is made by the
> manufacturer, only that it possesses a public credential for some device
> made by that manufacturer. So, I'm actually left wondering how that feature
> is intended to work. I regret not catching this earlier, but perhaps you
> could explain?
>
> Thanks,
> -Ekr
>
>
> On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear  wrote:
>
>> Hi Eric,
>>
>> Trimming.
>>
>> On 15.04.18 21:22, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>> IMPORTANT
>>>
>>>      The certificate extension is described below.
>>>
>>>      The information returned by the MUD file server (a web server) is
>>>      valid for the duration of the Thing's connection, or as specified in
>>>      the description.  Thus if the Thing is disconnected, any associated
>>>      configuration in the switch can be removed.  Similarly, from time to
>>>
>>> IMPORTANT: What does "disconnected" mean in this context? Does a
>>> reboot count? What if I am wireless? This is a critical question if
>>> MUD is intended as a post-compromise mechanism. Say that an attacker
>>> compromises the firmware for a device and then forces a reboot
>>> followed by a 2 hour pause before the wireless NIC is activated. Will
>>> this result in configuration removal? If so, MUD seems of limited use,
>>> because it can then make itself appear to be a new device with a new
>>> MUD configuration. (This is of course true in general in a wireless
>>> context if the firmware can change the client's L2 address).
>>>
>>>
>>> Yes, configuration is intended to be removed when a device disconnects
>>> or a session terminates.  This would be considered normal garbage
>>> collection.  But whether or not you can simply replace the firmware and
>>> gain the same access will depend on how the MUD-URL is learned.  If it is
>>> in a manufacturer certificate, for instance, that's not something an
>>> attacker will easily replace.  If the assertion is coming via LLDP, or
>>> DHCP, then one has to apply the mitigations discussed in the security
>>> considerations section (and they are numerous).
>>>
>>
>> I'm not following you here. Say it's in a manufacturer certificate, what
>> stops me from getting my own certificate for Attacker LLC and then serving
>> a wide open policy? The mitigations don't really seem to do much to
>> counteract this.
>>
>>
>> I believe this point and one down below, where you write:
>>
>> This doesn't seem to address my concern, which is that there's no
>> realistic way of knowing
>> what trust anchors apply. If it's not WebPKI, then what?
>>
>> are related, and so I propose to address them together, and this text
>> could go into security considerations.  The *intent* is that mud managers
>> or their providers will keep a list of known trusted signers.  Examples are
>> likely to include certification bodies (we are aware of at least one that
>> is very interested), the MUD manager vendor themselves, and perhaps
>> others.  Because these are early days, I don't want to be too declarative,
>> but we can say this:
>>
>> NEW:
>>
>> ---
>> MUD managers and their administrators MUST NOT automatically trust a
>> manufacturer's certificate simply because it validates.  Rather, the
>> certificate MUST be signed by an entity that has previously established
>> trust for this explicit purpose.  In particular, the WebPKI alone is not
>> appropriate.
>> ---
>>
>>
>> That means that just because Joe Evil signed the darn thing doesn't mean
>> that we should believe it.  On the other hand, I might trust a security
>> company to vet this stuff.  Would this address your concern?  Also, I'll
>> correct the previous factual error.
>>
>> And again, I view this as early days.  The architecture is going to need
>> some time to mature and evolve.
>>
>>
>>
>>
>>
>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>>
>>>
>>>   Abstract
>>>
>>>      This memo specifies a component-based architecture for manufacturer
>>>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>>>      Things to signal to the network what sort of access and network
>>>
>>> I realize that "Things" has become a marketing term, but it's opaque
>>> and unnecessary here. "elements" would be the conventional term.
>>>
>>>
>>> How about "end devices"?  That makes it clear in the abstract.  I don't
>>> propose to do a global substitute, because we scope the term well in the
>>> introduction, as you note directly below.
>>>
>>
>> To be honest, I would do a search and replace, but I agree that theis
>> would resolve the ambiguity here.
>>
>>>
>>>      it continues to make sense for general purpose computing devices
>>>      today, including laptops, smart phones, and tablets.
>>>
>>>      [RFC7452] discusses design patterns for, and poses questions about,
>>>      smart objects.  Let us then posit a group of objects that are
>>>      specifically not general purpose computers.  These devices, which
>>>
>>> I don't think this makes sense. These devices usually *are* general
>>> purpose computers (turing complete, etc.)
>>>
>>>
>>> That these objects might happen to use a general purpose CPU or
>>> operations system doesn't in and of itself make them general purpose
>>> devices.  As a complete SKU they are sold with a single or small number of
>>> uses in mind.  That is what is posited.  Is there a way to make that
>>> clearer?
>>>
>>
>> Perhaps "not intended to be used for general purpose computing tasks"
>>
>>
>> Ok.
>>
>>
>>>
>>>      specifically not general purpose computers.  These devices, which
>>>      this memo refers to as Things, have a specific purpose.  By
>>>      definition, therefore, all other uses are not intended.  The
>>>      combination of these two statements can be restated as a manufacturer
>>>      usage description (MUD) that can be applied at various points within
>>>      a network.
>>>
>>> I would make the point here that the purpose of the MUD is to describe
>>> the communications pattern. You only really get that by the statement
>>> in S 1.1 that the communication pattern of other devices is too
>>> complicated to profile.
>>>
>>>
>>> I think this statement is predicated on your previous comment, and would
>>> prefer not to change text at this time.
>>>
>>
>> Hmmm.... No, I don't think you're reading me right here. I'm just saying
>> that it would be useful upfront to say that MUD
>> is about saying "this is what communications pattern these devices are
>> expected to have"
>>
>>
>> Ok.  I think that's a good add, and propose to add a statement based on
>> your quoted text.
>>
>> Thanks again,
>>
>> Eliot
>>
>
>

--001a11422594f11e8f0569f6da5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I haven't balloted yet, and this is EKR's ballot t=
hread, but one point is worth bringing up here ...

On Mon, Apr 16, 2018 at 7:25 AM, Eric Resc=
orla <ekr@rtfm.com> wrote:
Hi Eliot,

Thanks for continuing =
the conversation. My question is how this fits into the system as a whole.<=
/div>

ISTM that there are two ways in which a MUD policy=
 can affect the network's behavior:

- Additive=
 -- it lets the device do things it otherwise might not be permitted to do =
(e.g., accept incoming TCP connections)
- Restrictive -- it s=
tops the device from doing things that it otherwise would be permitted to d=
o (e.g., make connections to IP addresses on non-443 ports)

I've read previous versions of this draft =
and some of the mailing list discussion, but not a lot. Having said that, I=
 hadn't heard anyone express the possibility of the additive case descr=
ibed here. The context I always heard about, was roughly "we've go=
tta keep all the coke machines on campus from doing anything except reporti=
ng that they need to be refilled", or whatever variation of cameras, p=
rinters, or *mumble* have access to your network for a specific reason, are=
 running some arbitrary version of some OS stack that included TCP or UDP c=
apabilities, aren't being maintained enough to be current on security p=
atches, and aren't being managed, so are ripe for attacks to create bot=
nets.=C2=A0

Perhaps I need to get out more. Almost=
 certainly. But ... the possibility of additive policies is interesting, an=
d new to me.

I'll be interested to watch this =
discussion. Eric, thanks for asking the question.

=
Spencer

In the former case, it's very important not to be able to forge a=
cceptable MUD policies, but in the latter case, an attacker can just not se=
rve *any* MUD policy and be in a stronger position than they would be if th=
ey had a valid policy, Thus, it's only in the former (additive) case wh=
ere forging a policy is useful to the attacker, and, in fact, it seems like=
 accepting an unsigned MUD policy would be better than no policy. Given the=
 ubiquity of non-MUD devices and the relatively limited capabilities that M=
UD seems to want to convey, it seems like the additive case isn't very =
useful.

I should mention one use case that I d=
id think of, where additive would be immediately useful: "This device =
is made by the same manufacturer as another device (and hence they can talk=
 to each other). However, I note that MUD is actually not capable of secure=
ly conveying that, because there's no proof that the device in hand act=
ually is made by the manufacturer, only that it possesses a public credenti=
al for some device made by that manufacturer. So, I'm actually left won=
dering how that feature is intended to work. I regret not catching this ear=
lier, but perhaps you could explain?

Thanks,
-Ekr


On Sun, =
Apr 15, 2018 at 11:27 PM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Eric,

    
Trimming.

    

    

    
On 15.04.18 21:22, Eric Rescorla wrote:

    

    

     =20
      


        


          

            
 

            

            

              
 

                  

                    
IMPORTANT


                    

                      
     The certificate extension is described belo=
w.

     The information returned by the MUD file server (a web server) is
     valid for the duration of the Thing's connection, or as specified =
in
     the description.  Thus if the Thing is disconnected, any associated
     configuration in the switch can be removed.  Similarly, from time to


                    

                    
IMPORTANT: What does "disconnected" mean=
 in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).

                  

                  

                 Yes, configuration is intended to be removed
                when a device disconnects or a session terminates.=C2=A0 Th=
is
                would be considered normal garbage collection.=C2=A0 But
                whether or not you can simply replace the firmware and
                gain the same access will depend on how the MUD-URL is
                learned.=C2=A0 If it is in a manufacturer certificate, for
                instance, that's not something an attacker will easily
                replace.=C2=A0 If the assertion is coming via LLDP, or DHCP=
,
                then one has to apply the mitigations discussed in the
                security considerations section (and they are numerous).
                

              

            

            


            

            
I'm not following you here. Say it's in a manufact=
urer
              certificate, what stops me from getting my own certificate
              for Attacker LLC and then serving a wide open policy? The
              mitigations don't really seem to do much to counteract
              this.

            

          

        

      

    

    

    I believe this point and one down below, where you write:

    

      
This doesn't seem to address my concern, which is that
        there's no realistic way of knowing

      what trust anchors apply. If it's not WebPKI, then what? 
    are related, and so I propose to address them together, and this
    text could go into security considerations.=C2=A0 The *intent* is that
    mud managers or their providers will keep a list of known trusted
    signers.=C2=A0 Examples are likely to include certification bodies (we
    are aware of at least one that is very interested), the MUD manager
    vendor themselves, and perhaps others.=C2=A0 Because these are early
    days, I don't want to be too declarative, but we can say this:

    

    NEW:

    

    ---

    MUD managers and their administrators MUST NOT automatically trust a
    manufacturer's certificate simply because it validates.=C2=A0 Rathe=
r, the
    certificate MUST be signed by an entity that has previously
    established trust for this explicit purpose.=C2=A0 In particular, the
    WebPKI alone is not appropriate. 

    ---

    

    

    That means that just because Joe Evil signed the darn thing doesn't
    mean that we should believe it.=C2=A0 On the other hand, I might trust =
a
    security company to vet this stuff.=C2=A0 Would this address your
    concern?=C2=A0 Also, I'll correct the previous factual error.

    

    And again, I view this as early days.=C2=A0 The architecture is going t=
o
    need some time to mature and evolve.

    

    

    

      

        

          

            


            

            


            

            


            

            

              
 

                  

                    
---------------------------------------------=
-------------------------
COMMENT:
-----------------------------------------------------------------=
-----




                    

                      
  Abstract

     This memo specifies a component-based architecture for manufacturer
     usage descriptions (MUD).  The goal of MUD is to provide a means for
     Things to signal to the network what sort of access and network


                    

                    
I realize that "Things" has become a mar=
keting term, but it's opaque
and unnecessary here. "elements" would be the conventional term.<=
/pre>
                  

                  

                 How about "end devices"?=C2=A0 That makes=
 it clear in
                the abstract.=C2=A0 I don't propose to do a global
                substitute, because we scope the term well in the
                introduction, as you note directly below.

                

            

            


            

            
To be honest, I would do a search and replace, but I
              agree that theis would resolve the ambiguity here. 

            

            

              
 

                  

                    

                      
     it continues to make sense for general purp=
ose computing devices
     today, including laptops, smart phones, and tablets.

     [RFC7452] discusses design patterns for, and poses questions about,
     smart objects.  Let us then posit a group of objects that are
     specifically not general purpose computers.  These devices, which


                    

                    
I don't think this makes sense. These devices =
usually *are* general
purpose computers (turing complete, etc.)

                  

                  

                 That these objects might happen to use a general
                purpose CPU or operations system doesn't in and of
                itself make them general purpose devices.=C2=A0 As a comple=
te
                SKU they are sold with a single or small number of uses
                in mind.=C2=A0 That is what is posited.=C2=A0 Is there a wa=
y to
                make that clearer?

                

            

            


            

            
Perhaps "not intended to be used for general purpose
              computing tasks" 

            

          

        

      

    

    

    Ok.

    

    

      

        

          

            

              
 

                  

                  

                    

                      
     specifically not general purpose computers.=
  These devices, which
     this memo refers to as Things, have a specific purpose.  By
     definition, therefore, all other uses are not intended.  The
     combination of these two statements can be restated as a manufacturer
     usage description (MUD) that can be applied at various points within
     a network.


                    

                    
I would make the point here that the purpose of th=
e MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.

                  

                  

                 I think this statement is predicated on your
                previous comment, and would prefer not to change text at
                this time.

                

            

            


            

            
Hmmm.... No, I don't think you're reading me right
              here. I'm just saying that it would be useful upfront to
              say that MUD

            
is about saying "this is what communications pattern
              these devices are expected to have"

            

          

        

      

    

    

    Ok.=C2=A0 I think that's a good add, and propose to add a statement=
 based
    on your quoted text.

    

    Thanks again,

    

    Eliot

  









--001a11422594f11e8f0569f6da5b--


From nobody Mon Apr 16 06:55:37 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095EF12D947; Mon, 16 Apr 2018 06:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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
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 Ir2dZHHNKNbM; Mon, 16 Apr 2018 06:55:34 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5009F1243F3; Mon, 16 Apr 2018 06:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10268; q=dns/txt; s=iport; t=1523886933; x=1525096533; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VqvYuqxN8nzxxTiLuhZP1/+Z4KaU440s7oYnkl1itg8=; b=Xc2dPK5aEg0S+htcoesj+3R5vUsMM7oKdzqD/IkHYD9cvFSR33gGc9lI 2TR8Qdinhf1VLv4dzk6QUG92rW3OrWa8F7bLhIZ70lgWKn5WIT9ZepppO uRKRbCqgD033oIwfPZB4bUk37BF7LMugygWeTK4RX73ndUP+gH2bObX9H 8=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,459,1517875200";  d="asc'?scan'208,217";a="3222705"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 13:55:31 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3GDtUgE009640; Mon, 16 Apr 2018 13:55:30 GMT
To: Eric Rescorla 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>  <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com> 
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <20ed5819-a47a-be0d-712a-6e3f566393ee@cisco.com>
Date: Mon, 16 Apr 2018 15:55:29 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FUtxksxiUsbMLw5bkIFsZHBZKmla5WkkI"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 13:55:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FUtxksxiUsbMLw5bkIFsZHBZKmla5WkkI
Content-Type: multipart/mixed; boundary="FgwbTQTIYIf3VNsKGDJwr1wFc3zZL4MZS";
 protected-headers="v1"
From: Eliot Lear 
To: Eric Rescorla 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,
 Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <20ed5819-a47a-be0d-712a-6e3f566393ee@cisco.com>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with
 DISCUSS and COMMENT)
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com>
 <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>
 
 <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>
 
In-Reply-To: 

--FgwbTQTIYIf3VNsKGDJwr1wFc3zZL4MZS
Content-Type: multipart/alternative;
 boundary="------------59CAC6B9219F1A3055A4CFD9"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------59CAC6B9219F1A3055A4CFD9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Eric,

On 16.04.18 14:25, Eric Rescorla wrote:
> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits
> into the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it
> otherwise would be permitted to do (e.g., make connections to IP
> addresses on non-443 ports)

What you describe is the choice of the network administrator, and not
the standard nor the manufacturer.=C2=A0 You are essentially asking, =E2=80=
=9Cwhat is
the default policy?=E2=80=9D and that will vary based on deployment.=C2=A0=
 It could
be "additive", "restrictive", or something else.=C2=A0 It could be a
walled-off IoT network.=C2=A0 Consider the cases:

  * This device has a MUD file and will be segmented accordingly.
  * This device has no MUD file and we may,
      o 1: give it no access,
      o 2: give it all access,
      o 3: give it some limited access,
      o 4: ask, or
      o 5: other.

All of these are perfectly valid approaches, depending on the deployment.=

>
> In the former case, it's very important not to be able to forge
> acceptable MUD policies, but in the latter case, an attacker can just
> not serve *any* MUD policy and be in a stronger position than they
> would be if they had a valid policy,[...]

And so that will depend on the deployment.=C2=A0 And many of the attacks
would be detectable.=C2=A0 All?=C2=A0 I would never be so bold.=C2=A0 But=
 also, MUD is
not an acronym for "magic bullet".=C2=A0 I really did try to spell that o=
ut
in the draft.

> I should mention one use case that I did think of, where additive
> would be immediately useful: "This device is made by the same
> manufacturer as another device (and hence they can talk to each
> other). However, I note that MUD is actually not capable of securely
> conveying that, because there's no proof that the device in hand
> actually is made by the manufacturer, only that it possesses a public
> credential for some device made by that manufacturer.

That is the point of building out a PKI, and as I wrote, there are some
interested in providing what amounts to a certification for this
purpose.=C2=A0 This is also something the MUD manager can take on: as tim=
e
goes on it can white list signers, and it can flag devices that are not
recognized as being risky.=C2=A0 In addition, if you have someone willing=
 to
take accountability for that device to lay a claim, it may not be
"proof", but that is=C2=A0 good enough in an enterprise environment, wher=
e
someone can be called to account for having added the device.

And we have to start somewhere.=C2=A0 The goal here it to establish a =E2=
=80=9Cwalk
before we run=E2=80=9D approach in several dimensions.=C2=A0 I just ask t=
hat we be
allowed to walk ;-)

With that, how would you like to proceed?=C2=A0 I've proposed text but co=
uld
go further if you like.

Eliot


--------------59CAC6B9219F1A3055A4CFD9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Eric,

    
On 16.04.18 14:25, Eric Rescorla wrote=
:

    

    

      
      

        
Hi Eliot,

        


        

        
Thanks for continuing the conversation. My question is how
          this fits into the system as a whole.

        


        

        
ISTM that there are two ways in which a MUD policy can
          affect the network's behavior:

        


        

        
- Additive -- it lets the device do things it otherwise
          might not be permitted to do (e.g., accept incoming TCP
          connections)

        

        
- Restrictive -- it stops the device from doing things that
          it otherwise would be permitted to do (e.g., make connections
          to IP addresses on non-443 ports)

      

    

    

    What you describe is the choice of the network administrator, and
    not the standard nor the manufacturer.=C2=A0 You are essentially aski=
ng,
    =E2=80=9Cwhat is the default policy?=E2=80=9D and that will vary base=
d on
    deployment.=C2=A0 It could be "additive", "restrictive", or something=

    else.=C2=A0 It could be a walled-off IoT network.=C2=A0 Consider the =
cases:

    

    
    
      
  • This device has a MUD file and will be segmented accordingly.
      
  • This device has no MUD file and we may, 
    
      
    • 
      
      
        
    • 1: give it no access, 
      
        
      • 
        
    • 2: give it all access, 
      
        
      • 
        
    • 3: give it some limited access, 
      
        
      • 
        
    • 4: ask, or
      
        
      • 
        
    • 5: other.
      
        
      • 
      
    
    

    All of these are perfectly valid approaches, depending on the
    deployment.

    

      

        


        

        
In the former case, it's very important not to be able to
          forge acceptable MUD policies, but in the latter case, an
          attacker can just not serve *any* MUD policy and be in a
          stronger position than they would be if they had a valid
          policy,[...]

      

    

    

    And so that will depend on the deployment.=C2=A0 And many of the atta=
cks
    would be detectable.=C2=A0 All?=C2=A0 I would never be so bold.=C2=A0=
 But also, MUD
    is not an acronym for "magic bullet".=C2=A0 I really did try to spell=

    that out in the draft.

    

    

      

        
I should mention one use case that I did think of, where
          additive would be immediately useful: "This device is made by
          the same manufacturer as another device (and hence they can
          talk to each other). However, I note that MUD is actually not
          capable of securely conveying that, because there's no proof
          that the device in hand actually is made by the manufacturer,
          only that it possesses a public credential for some device
          made by that manufacturer. 

      

    

    

    That is the point of building out a PKI, and as I wrote, there are
    some interested in providing what amounts to a certification for
    this purpose.=C2=A0 This is also something the MUD manager can take o=
n:
    as time goes on it can white list signers, and it can flag devices
    that are not recognized as being risky.=C2=A0 In addition, if you hav=
e
    someone willing to take accountability for that device to lay a
    claim, it may not be "proof", but that is=C2=A0 good enough in an
    enterprise environment, where someone can be called to account for
    having added the device.

    

    And we have to start somewhere.=C2=A0 The goal here it to establish a=

    =E2=80=9Cwalk before we run=E2=80=9D approach in several dimensions.=C2=
=A0 I just ask
    that we be allowed to walk ;-)

    

    With that, how would you like to proceed?=C2=A0 I've proposed text bu=
t
    could go further if you like.

    

    Eliot

    

  


--------------59CAC6B9219F1A3055A4CFD9--

--FgwbTQTIYIf3VNsKGDJwr1wFc3zZL4MZS--

--FUtxksxiUsbMLw5bkIFsZHBZKmla5WkkI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrUq1EACgkQh7ZrRtnS
ejM3ZggAtlRw698p4s8CNy4D4L+WGMw08Ibkx8AsuhsqtLEF4cZvb4bZPTcdad/N
3PfnpSUYDKEfAMT6ux6RO0nKNseG0qfWrC/dGw/jL8oOuecEfGAPeB51xv/MgxFL
Peym1/90Q22MqmdlCmO3IvQV3HZ/o0DxDIDYgw+xx3W7DNt2ryOsx7nTKZxBtbVM
yEt6k3t77eKKtMtzXzTUSK5eueF2P0iHgrVILqc99uK8gor84vrmMkim5EWKvDYu
bTHzAOBeS+E7LKNT0Tyi1+sQjkATmpX2RAV7CkMwOzvGNRfnt5eqoef0ymqou4/a
cuxiKToZ71olx0kM3Frhd8YqaZYnBQ==
=dZDK
-----END PGP SIGNATURE-----

--FUtxksxiUsbMLw5bkIFsZHBZKmla5WkkI--


From nobody Mon Apr 16 07:04:32 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B22127137 for ; Mon, 16 Apr 2018 07:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 uhxGSSy1PrPq for ; Mon, 16 Apr 2018 07:04:20 -0700 (PDT)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC1012D952 for ; Mon, 16 Apr 2018 07:04:11 -0700 (PDT)
Received: by mail-ot0-x22b.google.com with SMTP id v64-v6so17469901otb.13 for ; Mon, 16 Apr 2018 07:04:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BJHnIvSOlLh/elljDfyHlIRZbqx9Yp2rl+WmuB4wlNk=; b=rv2/LgLya5ez+oHIBuUF7DmYhL+6JpiZJQO11H18VyM+XpMkKt8WEdzQpMDRfdFOQc f/Pfvb0Bq7WOj+t4oUh7ntlaVQl0+U0sPPxtZe7sVLI7AmujdNY51AeQptLoahbFe/FV zDsSQ3NezyDjTbnTULtvzqaFaE//eP9xdUNZAN/I5366rZZ3KZZ26MLvnJTpsRYjQBis HE6b7TYul9EuGhV6Nh4X+1DVDGmIvlhXoQ8/ADlB+MROOdAgR7efRKCgELOhX6Hlz268 tRduE1UhJqdhzUsL83cRjdpOX5ZYzzycE7A662ZOqkXio+02bd2O5Ge+cfwz/06Bg4HY KtzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BJHnIvSOlLh/elljDfyHlIRZbqx9Yp2rl+WmuB4wlNk=; b=ec1Ik4ThIvmUZd37f2GphXFq53iVCaKYv/nFFtFtzAVR0CKAIBSRSWr9j00QWqmWPI jReMPInUYDyIx/5q/sklBHgpYvbvXBVw9boshPxPoB50JcDMVqSCmg0HzeREffhl/5OE tjKyb0zXfWuSqQ8XHuZeRV0rvpbAALZJfLWetuQlsJfkYgV50KFR1D+usHJOaESzhV7A 52RMQX4MErAeOFA5n3CTAaPnynNxOz8gK0N6hOSrzHZOUOtCXq5peHTvJ3PIY7LlBaEE U3i+pYy9a9PS3bzu6fGU/q3IXGeBda28RCAi8RpLy+Rmphs0PioXIeW9JrzK2Z3L/ERA 8Rqg==
X-Gm-Message-State: ALQs6tCcUrs+oax+rjJ2d+rZI1EVl1gzd8qRZzOrFjVAmlXa+i7At/k0 rPNy4aOX85CI/zcNJqq/pZgKRdaK6rjm0BXU5IW9XA==
X-Google-Smtp-Source: AIpwx4/V15xRa3ZJH1EAGUs1wo8eZN3v9zlC/iAvf/281IXh68mbAbalWGNu+DOWWBeiHbFdax+W2kzGIm2rMWG2qGE=
X-Received: by 2002:a9d:2a4f:: with SMTP id t73-v6mr3770811ota.392.1523887449947;  Mon, 16 Apr 2018 07:04:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 07:03:29 -0700 (PDT)
In-Reply-To: <20ed5819-a47a-be0d-712a-6e3f566393ee@cisco.com>
References: <152379196417.19651.6380075441438812361.idtracker@ietfa.amsl.com> <55cc525b-b85c-7316-4b2c-d0d32135a20f@cisco.com>  <591a7d2b-5379-0eff-2a0e-72e9394e64c1@cisco.com>  <20ed5819-a47a-be0d-712a-6e3f566393ee@cisco.com>
From: Eric Rescorla 
Date: Mon, 16 Apr 2018 07:03:29 -0700
Message-ID: 
To: Eliot Lear 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,  Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="00000000000021d50a0569f7b2e4"
Archived-At: 
Subject: Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 14:04:30 -0000

--00000000000021d50a0569f7b2e4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear  wrote:

> Hi Eric,
> On 16.04.18 14:25, Eric Rescorla wrote:
>
> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits into
> the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it otherwise
> would be permitted to do (e.g., make connections to IP addresses on non-4=
43
> ports)
>
>
> What you describe is the choice of the network administrator, and not the
> standard nor the manufacturer.  You are essentially asking, =E2=80=9Cwhat=
 is the
> default policy?
>

No, I'm not asking that. What I'm looking for is the document to describe
the various use cases and ensure that the mechanisms it provides actually
be able to effect those use cases.



In the former case, it's very important not to be able to forge acceptable
> MUD policies, but in the latter case, an attacker can just not serve *any=
*
> MUD policy and be in a stronger position than they would be if they had a
> valid policy,[...]
>
>
> And so that will depend on the deployment.  And many of the attacks would
> be detectable.
>

How would those attacks be detectable?


I should mention one use case that I did think of, where additive would be
> immediately useful: "This device is made by the same manufacturer as
> another device (and hence they can talk to each other). However, I note
> that MUD is actually not capable of securely conveying that, because
> there's no proof that the device in hand actually is made by the
> manufacturer, only that it possesses a public credential for some device
> made by that manufacturer.
>
>
> That is the point of building out a PKI, and as I wrote, there are some
> interested in providing what amounts to a certification for this purpose.
> This is also something the MUD manager can take on: as time goes on it ca=
n
> white list signers, and it can flag devices that are not recognized as
> being risky.  In addition, if you have someone willing to take
> accountability for that device to lay a claim, it may not be "proof", but
> that is  good enough in an enterprise environment, where someone can be
> called to account for having added the device.
>

Well, there are two types of PKI here:

1. The one associated with the device certificate
2. The one associated with the MUD signature.

My point is that only the former provides any assurance that the actual
device has anything to do with the manufacturer. In the latter case, I can
just stuff the URL of any manufacturer's MUD policy in my device that I
please.

-Ekr

--00000000000021d50a0569f7b2e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Eric,

    
On 16.04.18 14:25,=
 Eric Rescorla wrote:

    

    

     =20
      

        
Hi Eliot,

        


        

        
Thanks for continuing the conversation. My question is how
          this fits into the system as a whole.

        


        

        
ISTM that there are two ways in which a MUD policy can
          affect the network's behavior:

        


        

        
- Additive -- it lets the device do things it otherwise
          might not be permitted to do (e.g., accept incoming TCP
          connections)

        

        
- Restrictive -- it stops the device from doing things that
          it otherwise would be permitted to do (e.g., make connections
          to IP addresses on non-443 ports)

      

    

    

    What you describe is the choice of the network administrator, and
    not the standard nor the manufacturer.=C2=A0 You are essentially asking=
,
    =E2=80=9Cwhat is the default policy?

<=
div>No, I'm not asking that. What I'm looking for is the document t=
o describe the various use cases and ensure that the mechanisms it provides=
 actually be able to effect those use cases.


<=
/div>
In the former case, =
it's very important not to be able to
          forge acceptable MUD policies, but in the latter case, an
          attacker can just not serve *any* MUD policy and be in a
          stronger position than they would be if they had a valid
          policy,[...]

      

    

    

    And so that will depend on the deployment.=C2=A0 And many of the attack=
s
    would be detectable.=C2=A0

How wo=
uld those attacks be detectable?

<=
/span>

    

      

        
I should mention one use case that I did think of, where
          additive would be immediately useful: "This device is made b=
y
          the same manufacturer as another device (and hence they can
          talk to each other). However, I note that MUD is actually not
          capable of securely conveying that, because there's no proof
          that the device in hand actually is made by the manufacturer,
          only that it possesses a public credential for some device
          made by that manufacturer. 

      

    

    

    That is the point of building out a PKI, and as I wrote, there are
    some interested in providing what amounts to a certification for
    this purpose.=C2=A0 This is also something the MUD manager can take on:
    as time goes on it can white list signers, and it can flag devices
    that are not recognized as being risky.=C2=A0 In addition, if you have
    someone willing to take accountability for that device to lay a
    claim, it may not be "proof", but that is=C2=A0 good enough i=
n an
    enterprise environment, where someone can be called to account for
    having added the device.

Well=
, there are two types of PKI here:

1. The one asso=
ciated with the device certificate
2. The one associated with the=
 MUD signature.

My point is that only the former p=
rovides any assurance that the actual device has anything to do with the ma=
nufacturer. In the latter case, I can just stuff the URL of any manufacture=
r's MUD policy in my device that I please.

-Ekr



--00000000000021d50a0569f7b2e4--


From nobody Mon Apr 16 09:00:49 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D8C12E8C7; Mon, 16 Apr 2018 09:00:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152389444233.19573.9529430698968493643.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 09:00:42 -0700
Archived-At: 
Subject: [OPSAWG] Alexey Melnikov's No Record on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 16:00:42 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-opsawg-mud-20: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've only reviewed a part of the document, so sending you my current comments:

16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

    o Security considerations: See Security Considerations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFCXXXX]" instead of "this document" here, so that when the
RFC is published, the registration template can be posted to IANA website and
will have correct reference.

    o Applications that use this media type: MUD controllers as
      specified by this document.

As above.

    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear , Ralph Droms 

I think Ralph's address is wrong in 2 places.

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear 
         Ralph Droms 
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).



From nobody Mon Apr 16 12:09:22 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA8120725; Mon, 16 Apr 2018 12:09:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Spencer Dawkins 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 12:09:15 -0700
Archived-At: 
Subject: [OPSAWG] Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 19:09:15 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
Thanks for doing this work.

I do have some questions and comments.

I don't think this requires any changes to the current document, but I note that

3.15.  direction-initiated

   When applied this matches packets when the flow was initiated in the
   corresponding direction.  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.  When this flag is set, and
   the system has no reason to believe a flow has been initiated it MUST
   drop the packet.  This node may be implemented in its simplest form
   by looking at naked SYN bits, but may also be implemented through
   more stateful mechanisms.

it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
over QUIC, and I'm a bit suspicious of "may also be implemented through more
stateful mechanisms" in 2018. Do the right thing, of course.

Does

3.5.  is-supported

   This boolean is an indication from the manufacturer to the network
   administrator as to whether or not the Thing is supported.  In this
   context a Thing is said to not be supported if the manufacturer
   intends never to issue an update to the Thing or never update the MUD
   file.  A MUD controller MAY still periodically check for updates.

ever mean anything except "is-updated"? "Supported" covers a lot of ground …

If a manufacturer sells off one product line (so, flobbidy.example.com covered
multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
maintained by a manufacturer that isn't flobbidy.example.com), is there a good
plan for what comes next? I'm not sure what happens to is-supported, for
instance.

I'm sensitive to Eliot's "walk before trying to run" comment on another ballot
thread, but I'm thinking that

3.11.  model

   This string matches the entire MUD URL, thus covering the model that
   is unique within the context of the authority.  It may contain not
   only model information, but versioning information as well, and any
   other information that the manufacturer wishes to add.  The intended
   use is for devices of this precise class to match, to permit or deny
   communication between one another.

might usefully result in a BCP about naming models, after the community has
some experience with MUD. So, that's not intended to affect the current draft
text, only the working group that produced it ;-)

And, double ;-) ;-) but I wrote that before I saw this text in Section 14:

  A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may have impact on
   access of other Things.  Put another way, the admission may grow the
   access-list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that
   access-list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

So, when people know enough to describe best practices, I hope they do.



From nobody Mon Apr 16 12:11:26 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862C9126CD6 for ; Mon, 16 Apr 2018 12:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 Ku4kJ238F2TC for ; Mon, 16 Apr 2018 12:11:22 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2852C120725 for ; Mon, 16 Apr 2018 12:11:22 -0700 (PDT)
Received: from [192.168.20.38] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id DBD9ECE for ; Mon, 16 Apr 2018 19:11:20 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok 
In-Reply-To: <152377192081.19876.1408016458351314486@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 15:11:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <586220B4-9153-4EEF-B034-561CDCD442B8@deployingradius.com>
References: <152377192081.19876.1408016458351314486@ietfa.amsl.com>
To: IETF OOPSAWG 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 19:11:24 -0000

  I have some concerns with the document, and with the process by which =
we've gotten here.

  Let me recap some history.  There's a lot to take
in, so I'll present concerns in point form.

  First, the document.

* my "Security Considerations" text was first plagarised in draft-06,

* when I pointed this out (May 9, 2017), there was no reply to my
  message by the authors, and no change was made to the document.

* the ADs did respond, and indicated that they had talked to the
  authors about the issue, and that it was a simple misunderstand and
  would be fixed.

* A year later, I raised the issue again (March 2018).  There as no
  reply to my concerns by the authors, and no change was made to the
  document.

* in all, 4 separate revisions of the document plagarized my text, for
  over a year, sometimes with minor edits, despite repeated requests
  to address the issue.

  Those issues alone are surprising.

* The text which was good enough to plagarize was then claimed to have
  deficiencies

* no one in the WG had noted any technical issues with the text

* the only issues were with attribution, not with the text in the
  Security Considerations section

* there is now a -10, which has essentially the same points as the
  previous text, just reworded

  I should point out that the RFC process is supposed to be about
content, not authorship.  There are many RFCs issued with text written
by multiple people.  Where the authors cannot all be acknowledged on
the first page, the primary editor can be listed with the (Ed.)
suffix, to indicate editorship.  Other authors can be named as authors
on the first page, or in the Acknowledgements section.

  Second, concerns with engagement with the WG.  It continues.

* multiple people in the WG have requested the authors engage with the
  Working Group.  Most notably, many messages in May 2017.

* multiple people in the WG have requested the authors explain what's
  changed in each new revision, or perhaps to acknowlege comments and
  reviews (May 2017 again, among other times).

* This engagement has been minimal, despite multiple revisions of
  the document being published after these WG requests.

* new revisions have most often been "thrown over the wall" with
  minimal (or no) explanation as to what changed, and why.

* this new draft is no different, i.e. it "revised the security
  section".  Why?  How?  What changed?  What were any alleged
  "deficiencies"?

* the author have stated again that they "will endeavor to be much
  more reactive to comments".

* this statement or similar ones have been repeatdly, with little
  change in observable behavior.

* The authors request (again) that the WG review this new document
  wholesale.

  Speaking of reviews, let's continue with third, responses to
reviews.

* I have given multiple line-by-line reviews of the entire document,
  for multiple revisions of the document.

* as noted above, these reviews have generally been ignored.

* as noted above, new versions of the document have appeared which may
  or may not have addressed these reviews.

* Given the lack of feedback on the reviews before a new draft is
  issued, it is unclear whether the review comments have been
  addressed.

* due to these issues, I have stopped reviewing the document, as it
  is not productive.

  There are other issues with the larger community.  I'll continue.

* there was broad support for publication of early revisions of the
  document, despite it clearly not describing the protocol in a way
  that permits inter-operable implementations

* the people who supported adopting the document as a WG document
  have generally not reviewed or commented on it

* existing implementors of TACACS+ have not reviewed or commented on
  the document (Alex Clouter's review was done as part of a brand-new
  implementation)

* we have therefore no idea whether or not this document describes
  anything that anyone has implemented

  In order for the document to be published, we should have (at the
minimum) statements from multiple implementors that the draft matches
their implementations.

  Fourth, there are process issues, too.  I'll continue.

* the IETF has traditionally started a new WG to standardize new
  management protocols (i.e. a protocol new to the IETF)

* examples include the protocols described in RFC 6632.  These
  protocols have had their own working groups, going back to at least
  1996, and continuing to the present

* working on a new (and eventually standards track) document in the
  OPS area is therefore a new step for the IETF

* I have raised all of the concerns mentioned herein with the chairs
  and ADs in private email, public email on the list, and in person at
  multiple meetings

* There does not appear to be any action taken as a result.

* Messages to the list raising these issues have largely been
  unaddressed

  It is general IETF practice for document authors to interact with
the WG. And, to respond to WG reviews and comments.  See the many
comments in the OPSAWG archives in May 2017 for broad WG support of
this position.

  As the authors have largely ignored the WG comments, the chairs and
ADs should have taken steps to address this issue.  As of this
writing, it appears to be the same "status quo" of the past few years.

  I don't think these comments are unreasonable.  If we truly don't
care about the WG opinion, then the chairs and AD can:

* make a public statement saying that WG feedback can be ignored

* state that that the document can be published in whatever form the
  authors choose

* publish the document even if it does not describe the protocol in
  sufficient detail to create inter-operable implementations.

  I don't think that's the right approach, of course.  But it's
largely what's been happening due to silence and/or inaction of the
parties involved.

  I see no point in further reviewing the document.  I again oppose
publication of this document until such time as all of the WG issues
have been addressed.

  If we do actually care about what's in the document, then I suggest
finally the following steps be taken to address the ongoing concerns:

* the document should not be published until such time as multiple
  implementors have agreed that the specification matches their
  implementation.

* the chairs and ADs should insist that the authors address the
  outstanding WG concerns about this document

* the chairs and ADs should insist that authors follow established
  practice of *interacting* with the WG, including responding to
  future reviews and comments.

* the chairs and ADs should insist that new revisions of the document
  are accompanied by an explanation of what changed, and why

* that if the authors do not follow these steps (as they have not so
  far), that the chairs and ADs should replace them with other WG
  member(s) who will follow the IETF process.

  Alan DeKok.


From nobody Mon Apr 16 16:29:55 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597412D779; Mon, 16 Apr 2018 16:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 3FrMpyqyyeP4; Mon, 16 Apr 2018 16:29:31 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ECD1271DF; Mon, 16 Apr 2018 16:29:31 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id C546A3AC35; Mon, 16 Apr 2018 23:29:30 +0000 (UTC)
Date: Mon, 16 Apr 2018 23:29:30 +0000
From: heasley 
To: "Joel M. Halpern" 
Cc: heasley , li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" ,  "ietf@ietf.org" , opsawg 
Message-ID: <20180416232930.GB47095@shrubbery.net>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 23:29:33 -0000

Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern:
> (the authors would not have written it if no one wanted it.)

eh, that might not be a valid argument :)

> Also, one of the arguments for doing this in the router is that you can 
> get more timely and precise correlation.  Except that for geolocation of 
> address blocks, upstream correlation seems to be quite sufficiently 
> stable and precise.  NLRI may come and go.  I fone has geo-information, 
> it is unlikely to change.

This may have been answered, but in case not or un-clear; what I and I
believe others refer to here as geo location, is different from what you
and randy are talking about in the sense of the IETF's prefixes.  I do not
always care about that location.

I am placing my own marks on routes - where I hear them; region, country,
metro, relationship with the neighbor, etc.  Though it is not the whole
story, this is typically of more interest to me.

If a neighbor AS does similarly and sends them to me, I could make use of
them.  However, as you observed, these are all choices local to the AS -
the values, whether to send them, etc.  There is definitely a maintenance
cost associate with using this data and a question of accuracy.

Other's comments about accuracy and burden of external enrichment are valid.
Whether this particular additional resolution is much of a burden on routers,
I suspect not, but I am not an implementer.

Authors: please use a spell checker.  Also seems a few of the reference
links are broken.


From nobody Mon Apr 16 23:43:46 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F11812EAEE; Mon, 16 Apr 2018 23:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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
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 8HHlkDyfuNQo; Mon, 16 Apr 2018 23:43:41 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3075D12EADE; Mon, 16 Apr 2018 23:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28089; q=dns/txt; s=iport; t=1523947420; x=1525157020; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jfxCcmnvZolDwTz7tLYYPyO+bBD8WAh5W3bt9rq6C3w=; b=m7TgHBK4g+m+pjImkM8VFgM2/Hn61ePHl4mLvcaVRJvx5mL0dGTTRnA4 jsJDcDglDR00DfoQMYanGQwz9LdEaoK3PArPCpkhRepkR+YR7/vQ6p+va k/mjBx1E021Z5ZiYc2uACHS4mp563TswKECXqcH+HOc2br2J0recrJ8eU M=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,462,1517875200";  d="asc'?scan'208,217";a="3229849"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 06:43:38 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3H6hbl3031810; Tue, 17 Apr 2018 06:43:37 GMT
To: Spencer Dawkins , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com>
Date: Tue, 17 Apr 2018 08:43:36 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2suv3lMZbqwbOnpveteNBpUC35wA3t0Qj"
Archived-At: 
Subject: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 06:43:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2suv3lMZbqwbOnpveteNBpUC35wA3t0Qj
Content-Type: multipart/mixed; boundary="1MBM2LW1bon7rGtleIqViBcZ1EdEaSBj5";
 protected-headers="v1"
From: Eliot Lear 
To: Spencer Dawkins , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com>
Subject: (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on
 draft-ietf-opsawg-mud-20: (with COMMENT)
References: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>
In-Reply-To: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>

--1MBM2LW1bon7rGtleIqViBcZ1EdEaSBj5
Content-Type: multipart/alternative;
 boundary="------------2C5F6EBB150B76FF5D8CA74A"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------2C5F6EBB150B76FF5D8CA74A
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Responding to Spencer, Ben, and Alexy (in order).


On 16.04.18 21:09, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a=
 Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I =
note that
>
> 3.15.  direction-initiated
>
>    When applied this matches packets when the flow was initiated in the=

>    corresponding direction.  [RFC6092] specifies IPv6 guidance best
>    practices.  While that document is scoped specifically to IPv6, its
>    contents are applicable for IPv4 as well.  When this flag is set, an=
d
>    the system has no reason to believe a flow has been initiated it MUS=
T
>    drop the packet.  This node may be implemented in its simplest form
>    by looking at naked SYN bits, but may also be implemented through
>    more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in=
 HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through=
 more
> stateful mechanisms" in 2018. Do the right thing, of course.

I proposed a clarification: direction initiated is a TCP element.
>
> Does
>
> 3.5.  is-supported
>
>    This boolean is an indication from the manufacturer to the network
>    administrator as to whether or not the Thing is supported.  In this
>    context a Thing is said to not be supported if the manufacturer
>    intends never to issue an update to the Thing or never update the MU=
D
>    file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"?=20

Mostly that what it means, but the implication is that there's no
support, and enterprise administrators in particular might want to know
that (usually they do- because those devices represent a particular risk)=
=2E

> "Supported" covers a lot of ground =E2=80=A6
>
> If a manufacturer sells off one product line (so, flobbidy.example.com =
covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb wi=
ll be
> maintained by a manufacturer that isn't flobbidy.example.com), is there=
 a good
> plan for what comes next? I'm not sure what happens to is-supported, fo=
r
> instance.

The intent is that the entity providing the MUD file (probably the
manufacturer) will not be issuing software/firmware updates or MUD file
updates.=C2=A0 But your point is more about device lifecycle, and that's =
a
more interesting question than just "is-supported".=C2=A0 Steve Rich and
Thorsten Dahm have begun to delve in that direction.=C2=A0 There are at l=
east
a few possibilities, such as the use of redirects, or even domain names
that are used for particular classes of devices, or even common repos.=C2=
=A0
More work needed.

>
> I'm sensitive to Eliot's "walk before trying to run" comment on another=
 ballot
> thread, but I'm thinking that
>
> 3.11.  model
>
>    This string matches the entire MUD URL, thus covering the model that=

>    is unique within the context of the authority.  It may contain not
>    only model information, but versioning information as well, and any
>    other information that the manufacturer wishes to add.  The intended=

>    use is for devices of this precise class to match, to permit or deny=

>    communication between one another.
>
> might usefully result in a BCP about naming models, after the community=
 has
> some experience with MUD. So, that's not intended to affect the current=
 draft
> text, only the working group that produced it ;-)
>
> And, double ;-) ;-) but I wrote that before I saw this text in Section =
14:
>
>   A caution about some of the classes: admission of a Thing into the
>    "manufacturer" and "same-manufacturer" class may have impact on
>    access of other Things.  Put another way, the admission may grow the=

>    access-list on switches connected to other Things, depending on how
>    access is managed.  Some care should be given on managing that
>    access-list growth.  Alternative methods such as additional network
>    segmentation can be used to keep that growth within reason.
>
> So, when people know enough to describe best practices, I hope they do.=

>

Thanks, Spencer.=C2=A0 We're just getting going.

Now to Ben:

> =C2=A71.6, 2nd paragraph: Why is the SHOULD not a MUST?

Because at this stage there is only one encoding and no source of
confusion as to what is returned, and the people implementing this stuff
are getting their feet wet.=C2=A0 If they're using a service that simply
doesn't include the right Accept: header, and the right thing can still
happen, let's let that happen.

>
> =C2=A71.8, 4th paragraph: "The web server is typically run by or on beh=
alf of the
> manufacturer.
>    Its domain name is that of the authority found in the MUD URL. "
>
> These URLS are likely to be hardcoded, correct? This seems to point to
> operational considerations, especially around Thing lifecycle and owner=
ship.

Indeed.=C2=A0 It's captured in Security Considerations, but we can place =
a
forward pointer there.

>
> Editorial/Nits:
>
> Abstract: I'm not sure the use of the term "Things" will be obvious to =
a reader
> of the abstract in isolation from the rest of the document. (Abstracts =
should
> be able to stand alone.)

EKR beat you to it.=C2=A0 Change proposed.
>
> =C2=A71.1 : first paragraph: The idea that a Thing might have highly re=
stricted
> communication patterns seems core to the document. It would be helpful =
to
> mention that earlier in =C2=A71.

I think EKR beat you to this one as well ;-).=C2=A0 Change proposed.

> =C2=A71.3, definition of "Manufacturer": The definition says that "Manu=
facturer" may
> not necessarily be the entity that constructed the Thing. But that's th=
e plain
> English meaning of the word "manufacturer". If you don't want it to mea=
n that,
> please consider choosing a different term. ( for example, "authority")

This one's harder to change, and authority has its own ambiguities.

>
> =C2=A71.4: "... we assume that a device has so few
>    capabilities that it will implement the least necessary capabilities=

>    to function properly."
>
> That's a bit circular. Perhaps one of the two instances of "capabilitie=
s"
> should have been "requirements"?

How about:
> In seeking a general
> solution, however, we assume that a device will=C2=A0=C2=A0 =C2=A0imple=
ment
> functionality necessary to fulfill its limited purpose.


>
> =C2=A71.8 4th paragraph: The 2nd (and last) sentence is a comma splice,=
 and
> otherwise difficult to parse.

That is a mouthful.=C2=A0 Propose:
> =C2=A0=C2=A0 The web server is typically run by or on behalf of the man=
ufacturer.
> =C2=A0=C2=A0 Its domain name is that of the authority found in the MUD =
URL.=C2=A0 For
> =C2=A0=C2=A0 legacy cases where Things cannot emit a URL, if the switch=
 is able to
> =C2=A0=C2=A0 determine the appropriate URL, it may proxy it.=C2=A0 In t=
he trivial case
> =C2=A0=C2=A0 it may hardcode MUD-URL on a switch port or a map from som=
e
> =C2=A0=C2=A0 available identifier such as an L2 address or certificate =
hash to a
> =C2=A0=C2=A0 MUD-URL.


>
> =C2=A71.9, list item 7:  are we talking about transient disconnect or p=
ermanent
> removal?

Could be either.=C2=A0 The only difference between the two is that at som=
e
point someone has to CRUD the thing out of a database somewhere.
>
> =C2=A72: "A MUD file consists of a YANG model ..."
> A model instance, right? That is, not the model itself?

Indeed.
>
> =C2=A73.8, 2nd sentence: Consider reformulating this as a construction =
of MUST.

I think that's fair, and propose to change it to the following:

> Note that MUD extensions MUST NOT be used in a MUD file without
> the extensions being declared.=C2=A0 Implementations MUST ignore any no=
de
> in this file that they do not understand.

>
> =C2=A74: The idea of a "default" in bullet 2 seems in tension with the =
idea of
> "Anything not explicitly permitted is forbidden" in bullet 1.

Maybe so, but the intent here is that a great many devices are going to
be making use of DNS and NTP, and that not listing them in a MUD file is
more likely to lead to mistakes, rather than accidentally listing them.

>
> =C2=A714: Please define the concept of "east-west infection".
>

Propose "lateral infection" with a parenthetical definition.

On to Alexey:
> 16.4.  MIME Media-type Registration for MUD files
>
>    The following media-type is defined for transfer of MUD file:
>
>     o Type name: application
>     o Subtype name: mud+json
>     o Required parameters: n/a
>     o Optional parameters: n/a
>     o Encoding considerations: 8bit; application/mud+json values
>       are represented as a JSON object; UTF-8 encoding SHOULD be
>       employed.
>
> I am tempted to say "MUST be UTF-8 encoded".

In this day and age I think that sounds correct.=C2=A0 I personally have =
no
objections.

>
>     o Security considerations: See Security Considerations
>       of this document.
>     o Interoperability considerations: n/a
>     o Published specification: this document
>
> Nit: IANA Media Type registration templates need to have fully qualifie=
d
> references. Use "[RFCXXXX]" instead of "this document" here, so that wh=
en the
> RFC is published, the registration template can be posted to IANA websi=
te and
> will have correct reference.
Ok
>
>     o Applications that use this media type: MUD controllers as
>       specified by this document.
>
> As above.
Ok
>
>     o Fragment identifier considerations: n/a
>     o Additional information:
>
>         Magic number(s): n/a
>         File extension(s): n/a
>         Macintosh file type code(s): n/a
>
>     o Person & email address to contact for further information:
>       Eliot Lear , Ralph Droms 
>
> I think Ralph's address is wrong in 2 places.

Corrected.
>
>     o Intended usage: COMMON
>     o Restrictions on usage: none
>     o Author:
>          Eliot Lear 
>          Ralph Droms 
>     o Change controller: IESG
>     o Provisional registration? (standards tree only): No.
>
> UTF-8 needs to be a Normative reference (RFC 3629).
>
Ok.

Thanks, all.

Eliot

--------------2C5F6EBB150B76FF5D8CA74A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Responding to Spencer, Ben, and Alexy (in order).

    

    

    
On 16.04.18 21:09, Spencer Dawkins
      wrote:

    

    

      
Spencer Dawkins has entered the following ballot pos=
ition for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/st=
atement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes who's watching Discussions with other ADs, but that's still a Y=
es.
Thanks for doing this work.

I do have some questions and comments.

I don't think this requires any changes to the current document, but I no=
te that

3.15.  direction-initiated

   When applied this matches packets when the flow was initiated in the
   corresponding direction.  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.  When this flag is set, and
   the system has no reason to believe a flow has been initiated it MUST
   drop the packet.  This node may be implemented in its simplest form
   by looking at naked SYN bits, but may also be implemented through
   more stateful mechanisms.

it's not clear that "looking at naked SYN bits" will have an analogy in H=
TTP/2
over QUIC, and I'm a bit suspicious of "may also be implemented through m=
ore
stateful mechanisms" in 2018. Do the right thing, of course.

    

    

    I proposed a clarification: direction initiated is a TCP element.
=

    

      

Does

3.5.  is-supported

   This boolean is an indication from the manufacturer to the network
   administrator as to whether or not the Thing is supported.  In this
   context a Thing is said to not be supported if the manufacturer
   intends never to issue an update to the Thing or never update the MUD
   file.  A MUD controller MAY still periodically check for updates.

ever mean anything except "is-updated"? 

    

    

    Mostly that what it means, but the implication is that there's no
    support, and enterprise administrators in particular might want to
    know that (usually they do- because those devices represent a
    particular risk).

    

    

      
"Supported" covers a lot of ground =E2=80=A6

If a manufacturer sells off one product line (so, flobbidy.example.com co=
vered
multiple product lines, but now flobbidy.example.com/mark1/lightbulb will=
 be
maintained by a manufacturer that isn't flobbidy.example.com), is there a=
 good
plan for what comes next? I'm not sure what happens to is-supported, for
instance.

    

    

    The intent is that the entity providing the MUD file (probably the
    manufacturer) will not be issuing software/firmware updates or MUD
    file updates.=C2=A0 But your point is more about device lifecycle, an=
d
    that's a more interesting question than just "is-supported".=C2=A0 St=
eve
    Rich and Thorsten Dahm have begun to delve in that direction.=C2=A0 T=
here
    are at least a few possibilities, such as the use of redirects, or
    even domain names that are used for particular classes of devices,
    or even common repos.=C2=A0 More work needed.

    

    

      

I'm sensitive to Eliot's "walk before trying to run" comment on another b=
allot
thread, but I'm thinking that

3.11.  model

   This string matches the entire MUD URL, thus covering the model that
   is unique within the context of the authority.  It may contain not
   only model information, but versioning information as well, and any
   other information that the manufacturer wishes to add.  The intended
   use is for devices of this precise class to match, to permit or deny
   communication between one another.

might usefully result in a BCP about naming models, after the community h=
as
some experience with MUD. So, that's not intended to affect the current d=
raft
text, only the working group that produced it ;-)

And, double ;-) ;-) but I wrote that before I saw this text in Section 14=
:

  A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may have impact on
   access of other Things.  Put another way, the admission may grow the
   access-list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that
   access-list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

So, when people know enough to describe best practices, I hope they do.



    

    

    Thanks, Spencer.=C2=A0 We're just getting going.

    

    Now to Ben:

    

    

    

      
=C2=A71.6, 2nd paragraph: Why is the SHOULD not a MU=
ST?

    

    

    Because at this stage there is only one encoding and no source of
    confusion as to what is returned, and the people implementing this
    stuff are getting their feet wet.=C2=A0 If they're using a service th=
at
    simply doesn't include the right Accept: header, and the right thing
    can still happen, let's let that happen.

    

    

      

=C2=A71.8, 4th paragraph: "The web server is typically run by or on behal=
f of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownersh=
ip.

    

    

    Indeed.=C2=A0 It's captured in Security Considerations, but we can pl=
ace
    a forward pointer there.

    

    

      

Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a =
reader
of the abstract in isolation from the rest of the document. (Abstracts sh=
ould
be able to stand alone.)

    

    

    EKR beat you to it.=C2=A0 Change proposed.

    

      

=C2=A71.1 : first paragraph: The idea that a Thing might have highly rest=
ricted
communication patterns seems core to the document. It would be helpful to=

mention that earlier in =C2=A71.


    

    

    I think EKR beat you to this one as well ;-).=C2=A0 Change proposed.<=
br>
    

    

      
=C2=A71.3, definition of "Manufacturer": The definition says that "Manufa=
cturer" may
not necessarily be the entity that constructed the Thing. But that's the =
plain
English meaning of the word "manufacturer". If you don't want it to mean =
that,
please consider choosing a different term. ( for example, "authority")
    

    

    This one's harder to change, and authority has its own ambiguities.
    

    

      

=C2=A71.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities"=

should have been "requirements"?


    

    

    How about:

    
In seeking a general

      solution, however, we assume that a device will=C2=A0=C2=A0 =C2=A0i=
mplement

      functionality necessary to fulfill its limited purpose.
    

    

    

      

=C2=A71.8 4th paragraph: The 2nd (and last) sentence is a comma splice, a=
nd
otherwise difficult to parse.

    

    

    That is a mouthful.=C2=A0 Propose:

    
=C2=A0=C2=A0 The web server is typically ru=
n by or on
      behalf of the manufacturer.

      =C2=A0=C2=A0 Its domain name is that of the authority found in the =
MUD URL.=C2=A0
      For

      =C2=A0=C2=A0 legacy cases where Things cannot emit a URL, if the sw=
itch is
      able to

      =C2=A0=C2=A0 determine the appropriate URL, it may proxy it.=C2=A0 =
In the trivial
      case

      =C2=A0=C2=A0 it may hardcode MUD-URL on a switch port or a map from=
 some

      =C2=A0=C2=A0 available identifier such as an L2 address or certific=
ate hash
      to a

      =C2=A0=C2=A0 MUD-URL.

    

    

    

      

=C2=A71.9, list item 7:  are we talking about transient disconnect or per=
manent
removal?

    

    

    Could be either.=C2=A0 The only difference between the two is that at=

    some point someone has to CRUD the thing out of a database
    somewhere.

    

      

=C2=A72: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

    

    

    Indeed.

    

      

=C2=A73.8, 2nd sentence: Consider reformulating this as a construction of=
 MUST.

    

    

    I think that's fair, and propose to change it to the following:

    

    
Note that MUD extensions MUST NOT be used i=
n
      a MUD file without

      the extensions being declared.=C2=A0 Implementations MUST ignore an=
y
      node

      in this file that they do not understand.

    

    

      

=C2=A74: The idea of a "default" in bullet 2 seems in tension with the id=
ea of
"Anything not explicitly permitted is forbidden" in bullet 1.

    

    

    Maybe so, but the intent here is that a great many devices are going
    to be making use of DNS and NTP, and that not listing them in a MUD
    file is more likely to lead to mistakes, rather than accidentally
    listing them.

    

    

      

=C2=A714: Please define the concept of "east-west infection".



    

    

    Propose "lateral infection" with a parenthetical definition.

    

    On to Alexey:

    

      
16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

    

    

    In this day and age I think that sounds correct.=C2=A0 I personally h=
ave
    no objections.

    

    

      

    o Security considerations: See Security Considerations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFCXXXX]" instead of "this document" here, so that when=
 the
RFC is published, the registration template can be posted to IANA website=
 and
will have correct reference.

    

    Ok

    

      

    o Applications that use this media type: MUD controllers as
      specified by this document.

As above.

    

    Ok

    

      

    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear <lear@cisco.com>, Ralph Droms <rdroms@cisco.com>=


I think Ralph's address is wrong in 2 places.

    

    

    Corrected.

    

      

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear <lear@cisco.com>
         Ralph Droms <rdroms@cisco.com>
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).



    

    Ok.

    

    Thanks, all.

    

    Eliot

  


--------------2C5F6EBB150B76FF5D8CA74A--

--1MBM2LW1bon7rGtleIqViBcZ1EdEaSBj5--

--2suv3lMZbqwbOnpveteNBpUC35wA3t0Qj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrVl5gACgkQh7ZrRtnS
ejMt6wgAn9fLbGTEk3tOrSMByhDhFEy0kovhjrgkkUGbt82RMVdybJeHWgTxYuAZ
D+LWDSh/KMosaJpeZIxS/KByOjOaqBzsx6F+l+CN/Acrma36MQO3HWbNurOna51u
xYymygyyFBUKs9WSU6gvsxEfIrA03PYvQlrknwPxyV4fFH+6HYvRnqyJ4trM23/D
L9e/MO5v3/3UtktaxpIesl/t1YYT8WYFsc2CRHGjiaHJ98jULT3uCdjPTgxHAK5N
iVHIadBeriEC8L8kg2mz6tw5WIL5i7TY0QDRBe9qcHziet3xGzd+MLMbeo3twnrz
FOqMyU2UEIhMxemiyMxvy2kTwt5wwg==
=bEjC
-----END PGP SIGNATURE-----

--2suv3lMZbqwbOnpveteNBpUC35wA3t0Qj--


From nobody Tue Apr 17 04:35:22 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F7B1275FD; Tue, 17 Apr 2018 04:35:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152396491475.26123.7997206862891997022.idtracker@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 04:35:14 -0700
Archived-At: 
Subject: [OPSAWG] Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 11:35:15 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

3.6.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a localized name
   associated with the Thing.

systeminfo is provided by the manufacturer (or whoever generated the MUD file),
right? Why would it be *localized* for the administrator? Think of a
manufacturer from China and a sysadmin in Russia.

3.13.  controller

   This URI specifies a value that a controller will register with the
   MUD controller.  The node then is expanded to the set of hosts that
   are so registered.  This node may also be a URN.  In this case, the
   URN describes a well known service, such as DNS or NTP.

You don't list the DNS/NTP URNs until much later in the document. Please either
add a forward reference or list them here.

As per response from Eliot, my earlier comments should have been addressed in
editor's copy:

16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

    o Security considerations: See Security Considerations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFCXXXX]" instead of "this document" here, so that when the
RFC is published, the registration template can be posted to IANA website and
will have correct reference.

    o Applications that use this media type: MUD controllers as
      specified by this document.

As above.

    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear , Ralph Droms 

I think Ralph's address is wrong in 2 places.

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear 
         Ralph Droms 
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).



From nobody Tue Apr 17 05:13:01 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4631A12EB1A; Tue, 17 Apr 2018 05:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 HkSiahVKoS-Q; Tue, 17 Apr 2018 05:12:58 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEE712EB13; Tue, 17 Apr 2018 05:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5667; q=dns/txt; s=iport; t=1523967178; x=1525176778; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jrH6rpG/9xeYb7VwEudHrd+uXLJQ/10fm9tXb4Gwe18=; b=IWSnn2IHzvYfLWKnrICppHkubTh1uDfxS0w8wrATwx+64gkfHO6MNIEX yfy7PIreR+N2fc1nyQ3LvbO8KAwUKcQDLWuk7Qd7yfL5b+zxMPcSy1HAI mooPQKTiZ2v+23s1Fm7k4ijqPrPQUz2gt4Sf2I3H75QLbzc6o/8g564HY M=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,463,1517875200"; d="asc'?scan'208"; a="3191703"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 12:12:55 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3HCCt5X011484; Tue, 17 Apr 2018 12:12:55 GMT
To: Alexey Melnikov , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152396491475.26123.7997206862891997022.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <7826eb4a-60e1-5dce-f8f5-30b446c05c7a@cisco.com>
Date: Tue, 17 Apr 2018 14:12:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152396491475.26123.7997206862891997022.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WSGSNPmfgu60YH4Q4JoraR1CiEHyPX5kd"
Archived-At: 
Subject: Re: [OPSAWG] Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 12:13:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WSGSNPmfgu60YH4Q4JoraR1CiEHyPX5kd
Content-Type: multipart/mixed; boundary="sXRDq7SQ2bUxmoepERbb7PXAv7DLS6Efb";
 protected-headers="v1"
From: Eliot Lear 
To: Alexey Melnikov , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <7826eb4a-60e1-5dce-f8f5-30b446c05c7a@cisco.com>
Subject: Re: Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
References: <152396491475.26123.7997206862891997022.idtracker@ietfa.amsl.com>
In-Reply-To: <152396491475.26123.7997206862891997022.idtracker@ietfa.amsl.com>

--sXRDq7SQ2bUxmoepERbb7PXAv7DLS6Efb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Alexey,


On 17.04.18 13:35, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 3.6.  systeminfo
>
>    This is a textual UTF-8 description of the Thing to be connected.
>    The intent is for administrators to be able to see a localized name
>    associated with the Thing.
>
> systeminfo is provided by the manufacturer (or whoever generated the MU=
D file),
> right? Why would it be *localized* for the administrator? Think of a
> manufacturer from China and a sysadmin in Russia.

Yes, that was a spurious leftover from earlier versions.=C2=A0 It is gone=
 in
my copy.=C2=A0 I=C2=A0 do wish we could have done better at this, but wit=
h the
response Robert's review, I hope I can at least get a link that people
can copy into their browsers to actually find localized content.

>
> 3.13.  controller
>
>    This URI specifies a value that a controller will register with the
>    MUD controller.  The node then is expanded to the set of hosts that
>    are so registered.  This node may also be a URN.  In this case, the
>    URN describes a well known service, such as DNS or NTP.
>
> You don't list the DNS/NTP URNs until much later in the document. Pleas=
e either
> add a forward reference or list them here.

Ok.=C2=A0 Will add forward reference.

And indeed the below are corrected in my copy.

Thanks for improving the work,

Eliot

>
> As per response from Eliot, my earlier comments should have been addres=
sed in
> editor's copy:
>
> 16.4.  MIME Media-type Registration for MUD files
>
>    The following media-type is defined for transfer of MUD file:
>
>     o Type name: application
>     o Subtype name: mud+json
>     o Required parameters: n/a
>     o Optional parameters: n/a
>     o Encoding considerations: 8bit; application/mud+json values
>       are represented as a JSON object; UTF-8 encoding SHOULD be
>       employed.
>
> I am tempted to say "MUST be UTF-8 encoded".
>
>     o Security considerations: See Security Considerations
>       of this document.
>     o Interoperability considerations: n/a
>     o Published specification: this document
>
> Nit: IANA Media Type registration templates need to have fully qualifie=
d
> references. Use "[RFCXXXX]" instead of "this document" here, so that wh=
en the
> RFC is published, the registration template can be posted to IANA websi=
te and
> will have correct reference.
>
>     o Applications that use this media type: MUD controllers as
>       specified by this document.
>
> As above.
>
>     o Fragment identifier considerations: n/a
>     o Additional information:
>
>         Magic number(s): n/a
>         File extension(s): n/a
>         Macintosh file type code(s): n/a
>
>     o Person & email address to contact for further information:
>       Eliot Lear , Ralph Droms 
>
> I think Ralph's address is wrong in 2 places.
>
>     o Intended usage: COMMON
>     o Restrictions on usage: none
>     o Author:
>          Eliot Lear 
>          Ralph Droms 
>     o Change controller: IESG
>     o Provisional registration? (standards tree only): No.
>
> UTF-8 needs to be a Normative reference (RFC 3629).
>
>
>



--sXRDq7SQ2bUxmoepERbb7PXAv7DLS6Efb--

--WSGSNPmfgu60YH4Q4JoraR1CiEHyPX5kd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrV5MYACgkQh7ZrRtnS
ejNdUQf/Y8fS7/jP69hTvg43nO8gdiv7JWlPs2CWQKdgsp8hYGz+EnNAjrprJwEC
WXF300WLWLyB9czV3n5rdvkpyECyEH7adhOXIZ1StcuHd18OYifJEY7ORFvrTwD/
t898+3/zUxhvGxZ/tQjqBquCazLdyw9L7eCVAeOai54avspgaHG0Wu/84Lik1Ooc
PyikNJTM+C94dSkW2P+037SpW1mYzEwr6HjdWL+bvJK9krBfRgPDkI1SmVCjXVnO
x4G7uEQiptYCue9G21eqUBKKiG5kQADhQ2CjxRAlbV1CRrLDmlSO5/q9DjCdBNIJ
nZ/gCRqoCswr7pOoPE5ZUt0u9Q702g==
=x/ng
-----END PGP SIGNATURE-----

--WSGSNPmfgu60YH4Q4JoraR1CiEHyPX5kd--


From nobody Tue Apr 17 05:41:23 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B34F12EB2A for ; Tue, 17 Apr 2018 05:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 AJKpGgQKyqKH for ; Tue, 17 Apr 2018 05:41:20 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 9D96B12EB26 for ; Tue, 17 Apr 2018 05:41:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AF31F261096; Tue, 17 Apr 2018 05:41:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523968877; bh=y7igdbkPcOYX2QT1BAUnbaAcUpNQtOUJ630JIeSgOas=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ICHMXk821gglDdD+q7hxTafiqQ8udhKjxOrpgLZEhdiAx0Fz3YZm6TFQzCTURcJPH 4LCN3ZTGJl0Wy3QV6r8GDa63EwW3uQBYvyREBGpP6Pvu2rWzQAaJCs0DuU29UrQbbi RIwrWXCt//yWi47XaGDKyIkA3vOXqT6uDeTG8jYM=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0BAE4241299; Tue, 17 Apr 2018 05:41:16 -0700 (PDT)
To: Tianran Zhou , "opsawg@ietf.org" 
References: <6fc59353-a600-ebf8-d525-c4a026cb82bf@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: <944d2973-6d1a-c6f7-aec7-79fd60eb4f6e@joelhalpern.com>
Date: Tue, 17 Apr 2018 08:41:16 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 12:41:22 -0000

As far as I can tell, the formal IPR disclosure with IPR terms was not 
filed until several days after that request.
Thus, the WG can not have considered it in the light of the actual terms.

When I asked one WG participant, he was quite surprised by the terms.

Given the difficulty both Huawei and Ericsson have gotten from IETF 
participants over similar terms, I do not think this can be ignored.

Yours,
Joel

On 4/17/18 1:12 AM, Tianran Zhou wrote:
> Hi Joel,
> 
> Thanks for reminding this important information.
> Yes, we did the IPR poll when it became a WG draft. The IPR was disclosed then. Please see
> https://www.ietf.org/mail-archive/web/opsawg/current/msg04792.html
> We did not received any objection based on this.
> 
> Thanks,
> Tianran
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Tuesday, April 17, 2018 8:25 AM
>> To: opsawg-chairs@ietf.org
>> Subject: regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
>>
>> Is the working group aware of the IPR disclosure China Mobile made against
>> this document?  Specifically, that the IPR disclosure says that a license
>> may be required?
>>
>> Normally, I would not even comment on that, and as you can see, I am not
>> commenting on the list about it.
>>
>> But I note that this is a case where there is a clear workaround (just don't
>> do this).  So I would expect that the shepherd report, whenever that is
>> produced, will need to discuss the IPR disclosure.
>>
>> Yours,
>> Joel


From nobody Tue Apr 17 05:45:07 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2012EB2F; Tue, 17 Apr 2018 05:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xOYtafHzD6fv; Tue, 17 Apr 2018 05:44:57 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8E412EB26; Tue, 17 Apr 2018 05:44:57 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id u83so2305334ywc.4; Tue, 17 Apr 2018 05:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EiyTJs03e3Egkc1Qd9VJjORx6s3inHQSLkcErC9Do9I=; b=ldRvBxgL+7WMXk6R2dD0X9ViIffhwGwzu50imLwczEGaB4Nt4rJ0wIwS+n3FPRoBCn r3lODG/rds6aIo118xmCNBbaHGZhyzGpSCmDMaA/qrBlfypForyWUL/hFxx6Gm1YdXOw AN9ZvZBeSLYpV2wYdcKXsDMttNAXjFuc4nRdgcJDoiB8mrghOsTKbe94RGiGiI+hyXXV ylcDzrz4IYO6se2WX6+1l/O/I0OLjYXiGr44REEWgwCp+dMP2VEu30ye3esRWccwvtZL Un1rJ+wu5AWtZ6ERpZmRh4XGKFcRtXUO0vEHIJMOuNbihcA/6LKCesVsg0+nxgWMvFeA iadw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EiyTJs03e3Egkc1Qd9VJjORx6s3inHQSLkcErC9Do9I=; b=VzCEjwVUXeEuRqHPjEcgV1OXmNjRAeYCuI5KKhp1ug29pHlHHhpX58Lgv0epohd3Sq rRlfiIFtt8XxNIJce21ITcqVhFP5bsUFk8BFNgj3r9kSZZ/167V+1FRHnkavxAw4/3Dl If8eQv+/qM4g6/a3s9Ouragz4RmLOJA4VsI4HDgUoboWo3huAbkMOdVurL0vCP5GGJq/ mUTZM8ffwF8BRYfhvBYZ4LrRGcThEBR3/ix0ceNj7NAQg8Hp5MQaCot1kUL4JeEMkmLc tYZBwEX4eCu1XAEfkU2KF+dgWh/3iJabn3gptw5vj6mssVFcaY2HsymdwkNJgqjUeb1W lKfQ==
X-Gm-Message-State: ALQs6tAwtdfjIN0Lz1Z42hn3iCYYVG/+4Po/nKDMeRVnVvawx8eCIiH5 A7Rn7SSnmypgRSr6L74aorWZVpbLe6vaBI18W6A=
X-Google-Smtp-Source: AIpwx48/mI4KlhaFi9Bh8W9/ryksYax0eVsmRR4h/RxJHTWaIhZ0pXiUHLJ/G+v6E1Ae3vI64IjQNYpHhSY+yU3/s1E=
X-Received: by 10.129.199.13 with SMTP id m13mr990916ywi.279.1523969096255; Tue, 17 Apr 2018 05:44:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:c06:0:0:0:0:0 with HTTP; Tue, 17 Apr 2018 05:44:55 -0700 (PDT)
In-Reply-To: <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com>
References: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com> <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com>
From: Spencer Dawkins at IETF 
Date: Tue, 17 Apr 2018 07:44:55 -0500
Message-ID: 
To: Eliot Lear 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,  Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="089e0821fc0ca18e49056a0ab42e"
Archived-At: 
Subject: Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 12:45:01 -0000

--089e0821fc0ca18e49056a0ab42e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  wrote:

> Responding to Spencer, Ben, and Alexy (in order).
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:https:=
//datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Y=
es.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I no=
te that
>
> 3.15.  direction-initiated
>
>    When applied this matches packets when the flow was initiated in the
>    corresponding direction.  [RFC6092] specifies IPv6 guidance best
>    practices.  While that document is scoped specifically to IPv6, its
>    contents are applicable for IPv4 as well.  When this flag is set, and
>    the system has no reason to believe a flow has been initiated it MUST
>    drop the packet.  This node may be implemented in its simplest form
>    by looking at naked SYN bits, but may also be implemented through
>    more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in H=
TTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through m=
ore
> stateful mechanisms" in 2018. Do the right thing, of course.
>
>
> I proposed a clarification: direction initiated is a TCP element.
>

That is a clarification.

I guess what I'm thinking, on reflection, is that direction is likely to be
helpful for TCP-based communication, is not likely to be helpful for
UDP-based communication without stateful inspection (so, my camera probably
does need to act as a DNS client, but probably doesn't need to act as a DNS
server), and is likely to be increasingly unhelpful if we really do see
things using encrypted, UDP-based transports like QUIC.

This does poke the "how are network managers going to manage networks
running encrypted, UDP-based transport" bear, but that's way bigger than
this document. Say as much as you think is helpful, and then move on, I
think.

> Does
>
> 3.5.  is-supported
>
>    This boolean is an indication from the manufacturer to the network
>    administrator as to whether or not the Thing is supported.  In this
>    context a Thing is said to not be supported if the manufacturer
>    intends never to issue an update to the Thing or never update the MUD
>    file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"?
>
>
> Mostly that what it means, but the implication is that there's no support=
,
> and enterprise administrators in particular might want to know that
> (usually they do- because those devices represent a particular risk).
>

 Here, I must apologize, because I've been thinking of MUD as the other
side of a coin that also has SUIT, TEEP, and similar tools - If your Thing
is just being installed and forgotten until it's an attack platform, you
need MUD descriptions, but if your Thing is going to be updated, you should
be looking at SUIT, TEEP, and whatever else seems helpful.

I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
that's a lack of imagination on my part, but the most relevant side effect
of that, is that if you know what your printer needs to do, to be a network
printer, and you get a MUD description for it, and the printer isn't going
to be updated, that MUD description should be fine, forever.

I'm still connecting dots.

> "Supported" covers a lot of ground =E2=80=A6
>
> If a manufacturer sells off one product line (so, flobbidy.example.com co=
vered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will=
 be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a=
 good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.
>
>
> The intent is that the entity providing the MUD file (probably the
> manufacturer) will not be issuing software/firmware updates or MUD file
> updates.  But your point is more about device lifecycle, and that's a mor=
e
> interesting question than just "is-supported".  Steve Rich and Thorsten
> Dahm have begun to delve in that direction.  There are at least a few
> possibilities, such as the use of redirects, or even domain names that ar=
e
> used for particular classes of devices, or even common repos.  More work
> needed.
>

Yeah, and I didn't mean to slow MUD down waiting for that work. Just to be
clear (hence, Yes).


>
> I'm sensitive to Eliot's "walk before trying to run" comment on another b=
allot
> thread, but I'm thinking that
>
> 3.11.  model
>
>    This string matches the entire MUD URL, thus covering the model that
>    is unique within the context of the authority.  It may contain not
>    only model information, but versioning information as well, and any
>    other information that the manufacturer wishes to add.  The intended
>    use is for devices of this precise class to match, to permit or deny
>    communication between one another.
>
> might usefully result in a BCP about naming models, after the community h=
as
> some experience with MUD. So, that's not intended to affect the current d=
raft
> text, only the working group that produced it ;-)
>
> And, double ;-) ;-) but I wrote that before I saw this text in Section 14=
:
>
>   A caution about some of the classes: admission of a Thing into the
>    "manufacturer" and "same-manufacturer" class may have impact on
>    access of other Things.  Put another way, the admission may grow the
>    access-list on switches connected to other Things, depending on how
>    access is managed.  Some care should be given on managing that
>    access-list growth.  Alternative methods such as additional network
>    segmentation can be used to keep that growth within reason.
>
> So, when people know enough to describe best practices, I hope they do.
>
>
>
> Thanks, Spencer.  We're just getting going.
>

And I'm darned glad to see that happening.

Thanks for the quick responses.

Spencer


> Now to Ben:
>
> =C2=A71.6, 2nd paragraph: Why is the SHOULD not a MUST?
>
>
> Because at this stage there is only one encoding and no source of
> confusion as to what is returned, and the people implementing this stuff
> are getting their feet wet.  If they're using a service that simply doesn=
't
> include the right Accept: header, and the right thing can still happen,
> let's let that happen.
>
> =C2=A71.8, 4th paragraph: "The web server is typically run by or on behal=
f of the
> manufacturer.
>    Its domain name is that of the authority found in the MUD URL. "
>
> These URLS are likely to be hardcoded, correct? This seems to point to
> operational considerations, especially around Thing lifecycle and ownersh=
ip.
>
>
> Indeed.  It's captured in Security Considerations, but we can place a
> forward pointer there.
>
> Editorial/Nits:
>
> Abstract: I'm not sure the use of the term "Things" will be obvious to a =
reader
> of the abstract in isolation from the rest of the document. (Abstracts sh=
ould
> be able to stand alone.)
>
>
> EKR beat you to it.  Change proposed.
>
> =C2=A71.1 : first paragraph: The idea that a Thing might have highly rest=
ricted
> communication patterns seems core to the document. It would be helpful to
> mention that earlier in =C2=A71.
>
>
> I think EKR beat you to this one as well ;-).  Change proposed.
>
> =C2=A71.3, definition of "Manufacturer": The definition says that "Manufa=
cturer" may
> not necessarily be the entity that constructed the Thing. But that's the =
plain
> English meaning of the word "manufacturer". If you don't want it to mean =
that,
> please consider choosing a different term. ( for example, "authority")
>
>
> This one's harder to change, and authority has its own ambiguities.
>
> =C2=A71.4: "... we assume that a device has so few
>    capabilities that it will implement the least necessary capabilities
>    to function properly."
>
> That's a bit circular. Perhaps one of the two instances of "capabilities"
> should have been "requirements"?
>
>
> How about:
>
> In seeking a general
> solution, however, we assume that a device will    implement
> functionality necessary to fulfill its limited purpose.
>
>
>
> =C2=A71.8 4th paragraph: The 2nd (and last) sentence is a comma splice, a=
nd
> otherwise difficult to parse.
>
>
> That is a mouthful.  Propose:
>
>    The web server is typically run by or on behalf of the manufacturer.
>    Its domain name is that of the authority found in the MUD URL.  For
>    legacy cases where Things cannot emit a URL, if the switch is able to
>    determine the appropriate URL, it may proxy it.  In the trivial case
>    it may hardcode MUD-URL on a switch port or a map from some
>    available identifier such as an L2 address or certificate hash to a
>    MUD-URL.
>
>
>
> =C2=A71.9, list item 7:  are we talking about transient disconnect or per=
manent
> removal?
>
>
> Could be either.  The only difference between the two is that at some
> point someone has to CRUD the thing out of a database somewhere.
>
> =C2=A72: "A MUD file consists of a YANG model ..."
> A model instance, right? That is, not the model itself?
>
>
> Indeed.
>
> =C2=A73.8, 2nd sentence: Consider reformulating this as a construction of=
 MUST.
>
>
> I think that's fair, and propose to change it to the following:
>
> Note that MUD extensions MUST NOT be used in a MUD file without
> the extensions being declared.  Implementations MUST ignore any node
> in this file that they do not understand.
>
>
> =C2=A74: The idea of a "default" in bullet 2 seems in tension with the id=
ea of
> "Anything not explicitly permitted is forbidden" in bullet 1.
>
>
> Maybe so, but the intent here is that a great many devices are going to b=
e
> making use of DNS and NTP, and that not listing them in a MUD file is mor=
e
> likely to lead to mistakes, rather than accidentally listing them.
>
> =C2=A714: Please define the concept of "east-west infection".
>
>
>
> Propose "lateral infection" with a parenthetical definition.
>
> On to Alexey:
>
> 16.4.  MIME Media-type Registration for MUD files
>
>    The following media-type is defined for transfer of MUD file:
>
>     o Type name: application
>     o Subtype name: mud+json
>     o Required parameters: n/a
>     o Optional parameters: n/a
>     o Encoding considerations: 8bit; application/mud+json values
>       are represented as a JSON object; UTF-8 encoding SHOULD be
>       employed.
>
> I am tempted to say "MUST be UTF-8 encoded".
>
>
> In this day and age I think that sounds correct.  I personally have no
> objections.
>
>     o Security considerations: See Security Considerations
>       of this document.
>     o Interoperability considerations: n/a
>     o Published specification: this document
>
> Nit: IANA Media Type registration templates need to have fully qualified
> references. Use "[RFCXXXX]" instead of "this document" here, so that when=
 the
> RFC is published, the registration template can be posted to IANA website=
 and
> will have correct reference.
>
> Ok
>
>     o Applications that use this media type: MUD controllers as
>       specified by this document.
>
> As above.
>
> Ok
>
>     o Fragment identifier considerations: n/a
>     o Additional information:
>
>         Magic number(s): n/a
>         File extension(s): n/a
>         Macintosh file type code(s): n/a
>
>     o Person & email address to contact for further information:
>       Eliot Lear  , Ralph Droms  
>
> I think Ralph's address is wrong in 2 places.
>
>
> Corrected.
>
>     o Intended usage: COMMON
>     o Restrictions on usage: none
>     o Author:
>          Eliot Lear  
>          Ralph Droms  
>     o Change controller: IESG
>     o Provisional registration? (standards tree only): No.
>
> UTF-8 needs to be a Normative reference (RFC 3629).
>
>
> Ok.
>
> Thanks, all.
>
> Eliot
>

--089e0821fc0ca18e49056a0ab42e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear <=
;lear@cisco.com>=
 wrote:

 =20
   =20
 =20
  

    
Responding to Spencer, Ben, and Alexy (in order).

    

    

    
On 16.04.18 21:09, =
Spencer Dawkins
      wrote:

    

    

      
Spencer Dawkins has entered the following ballot position for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<=
/a>
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://dat=
atracker.ietf.org/doc/draft-ietf-opsawg-mud/



-----------------------------------------------------------------=
-----
COMMENT:
-----------------------------------------------------------------=
-----

I'm a Yes who's watching Discussions with other ADs, but that's=
 still a Yes.
Thanks for doing this work.

I do have some questions and comments.

I don't think this requires any changes to the current document, but I =
note that

3.15.  direction-initiated

   When applied this matches packets when the flow was initiated in the
   corresponding direction.  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.  When this flag is set, and
   the system has no reason to believe a flow has been initiated it MUST
   drop the packet.  This node may be implemented in its simplest form
   by looking at naked SYN bits, but may also be implemented through
   more stateful mechanisms.

it's not clear that "looking at naked SYN bits" will have an =
analogy in HTTP/2
over QUIC, and I'm a bit suspicious of "may also be implemented th=
rough more
stateful mechanisms" in 2018. Do the right thing, of course.

    

    

    I proposed a clarification: direction initiated is a TCP element.

That is a clarification.=C2=A0

I guess what I'm thinking, on reflection, is that dir=
ection is likely to be helpful for TCP-based communication, is not likely t=
o be helpful for UDP-based communication without stateful inspection (so, m=
y camera probably does need to act as a DNS client, but probably doesn'=
t need to act as a DNS server), and is likely to be increasingly unhelpful =
if we really do see things using encrypted, UDP-based transports like QUIC.=
=C2=A0

This does poke the "how are network ma=
nagers going to manage networks running encrypted, UDP-based transport"=
; bear, but that's way bigger than this document. Say as much as you th=
ink is helpful, and then move on, I think.=C2=A0

    

      
Does

3.5.  is-supported

   This boolean is an indication from the manufacturer to the network
   administrator as to whether or not the Thing is supported.  In this
   context a Thing is said to not be supported if the manufacturer
   intends never to issue an update to the Thing or never update the MUD
   file.  A MUD controller MAY still periodically check for updates.

ever mean anything except "is-updated"? 

    

    

    Mostly that what it means, but the implication is that there's no
    support, and enterprise administrators in particular might want to
    know that (usually they do- because those devices represent a
    particular risk).

=C2=A0Here,=
 I must apologize, because I've been thinking of MUD as the other side =
of a coin that also has SUIT, TEEP, and similar tools - If your Thing is ju=
st being installed and forgotten until it's an attack platform, you nee=
d MUD descriptions, but if your Thing is going to be updated, you should be=
 looking at SUIT, TEEP, and whatever else seems helpful.=C2=A0
I had not been thinking of using both MUD and SUIT/TEEP/whatev=
er, and that's a lack of imagination on my part, but the most relevant =
side effect of that, is that if you know what your printer needs to do, to =
be a network printer, and you get a MUD description for it, and the printer=
 isn't going to be updated, that MUD description should be fine, foreve=
r.

I'm still connecting dots.
"Supported" covers a lot of ground =E2=80=A6

If a manufacturer sells off one product line (so, flobbidy.example.com covered
multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
maintained by a manufacturer that isn't flobbidy.example.com), is there a good
plan for what comes next? I'm not sure what happens to is-supported, fo=
r
instance.

    

    

    The intent is that the entity providing the MUD file (probably the
    manufacturer) will not be issuing software/firmware updates or MUD
    file updates.=C2=A0 But your point is more about device lifecycle, and
    that's a more interesting question than just "is-supported&quo=
t;.=C2=A0 Steve
    Rich and Thorsten Dahm have begun to delve in that direction.=C2=A0 The=
re
    are at least a few possibilities, such as the use of redirects, or
    even domain names that are used for particular classes of devices,
    or even common repos.=C2=A0 More work needed.

Yeah, and I didn't mean to slow MUD down waiting for t=
hat work. Just to be clear (hence, Yes).
=C2=A0

    

    

      
I'm sensitive to Eliot's "walk before trying to run=
" comment on another ballot
thread, but I'm thinking that

3.11.  model

   This string matches the entire MUD URL, thus covering the model that
   is unique within the context of the authority.  It may contain not
   only model information, but versioning information as well, and any
   other information that the manufacturer wishes to add.  The intended
   use is for devices of this precise class to match, to permit or deny
   communication between one another.

might usefully result in a BCP about naming models, after the community has
some experience with MUD. So, that's not intended to affect the current=
 draft
text, only the working group that produced it ;-)

And, double ;-) ;-) but I wrote that before I saw this text in Section 14:

  A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may hav=
e impact on
   access of other Things.  Put another way, the admission may grow the
   access-list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that
   access-list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

So, when people know enough to describe best practices, I hope they do.



    

    

    Thanks, Spencer.=C2=A0 We're just getting going.

And I'm darned glad to see that happening.

Thanks for the quick responses.

Spencer
=C2=A0
Now to Ben:

    

    

    

      
=C2=A71.6, 2nd paragraph: Why is the SHOULD not a MUST?

    

    

    Because at this stage there is only one encoding and no source of
    confusion as to what is returned, and the people implementing this
    stuff are getting their feet wet.=C2=A0 If they're using a service =
that
    simply doesn't include the right Accept: header, and the right thin=
g
    can still happen, let's let that happen.

    

    

      
=C2=A71.8, 4th paragraph: "The web server is typically run =
by or on behalf of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownership=
.

    

    

    Indeed.=C2=A0 It's captured in Security Considerations, but we can =
place
    a forward pointer there.

    

    

      
Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be o=
bvious to a reader
of the abstract in isolation from the rest of the document. (Abstracts shou=
ld
be able to stand alone.)

    

    

    EKR beat you to it.=C2=A0 Change proposed.

    

      
=C2=A71.1 : first paragraph: The idea that a Thing might have hi=
ghly restricted
communication patterns seems core to the document. It would be helpful to
mention that earlier in =C2=A71.


    

    

    I think EKR beat you to this one as well ;-).=C2=A0 Change proposed.
    

    

      
=C2=A71.3, definition of "Manufacturer": The definitio=
n says that "Manufacturer" may
not necessarily be the entity that constructed the Thing. But that's th=
e plain
English meaning of the word "manufacturer". If you don't want=
 it to mean that,
please consider choosing a different term. ( for example, "authority&q=
uot;)

    

    

    This one's harder to change, and authority has its own ambiguities.=


    

    

      
=C2=A71.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabi=
lities"
should have been "requirements"?


    

    

    How about:

    
In seeking a general

      solution, however, we assume that a device will=C2=A0=C2=A0 =C2=A0imp=
lement

      functionality necessary to fulfill its limited purpose.

    

    

    

      
=C2=A71.8 4th paragraph: The 2nd (and last) sentence is a comma =
splice, and
otherwise difficult to parse.

    

    

    That is a mouthful.=C2=A0 Propose:

    
=C2=A0=C2=A0 The web server is typically run =
by or on
      behalf of the manufacturer.

      =C2=A0=C2=A0 Its domain name is that of the authority found in the MU=
D URL.=C2=A0
      For

      =C2=A0=C2=A0 legacy cases where Things cannot emit a URL, if the swit=
ch is
      able to

      =C2=A0=C2=A0 determine the appropriate URL, it may proxy it.=C2=A0 In=
 the trivial
      case

      =C2=A0=C2=A0 it may hardcode MUD-URL on a switch port or a map from s=
ome

      =C2=A0=C2=A0 available identifier such as an L2 address or certificat=
e hash
      to a

      =C2=A0=C2=A0 MUD-URL.

    

    

    

      
=C2=A71.9, list item 7:  are we talking about transient disconne=
ct or permanent
removal?

    

    

    Could be either.=C2=A0 The only difference between the two is that at
    some point someone has to CRUD the thing out of a database
    somewhere.

    

      
=C2=A72: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

    

    

    Indeed.

    

      
=C2=A73.8, 2nd sentence: Consider reformulating this as a constr=
uction of MUST.

    

    

    I think that's fair, and propose to change it to the following:

    

    
Note that MUD extensions MUST NOT be used in
      a MUD file without

      the extensions being declared.=C2=A0 Implementations MUST ignore any
      node

      in this file that they do not understand.

    

    

      
=C2=A74: The idea of a "default" in bullet 2 seems in =
tension with the idea of
"Anything not explicitly permitted is forbidden" in bullet 1.
    

    

    Maybe so, but the intent here is that a great many devices are going
    to be making use of DNS and NTP, and that not listing them in a MUD
    file is more likely to lead to mistakes, rather than accidentally
    listing them.

    

    

      
=C2=A714: Please define the concept of "east-west infection=
".



    

    

    Propose "lateral infection" with a parenthetical definition.<=
br>
    

    On to Alexey:

    

      
16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

    

    

    In this day and age I think that sounds correct.=C2=A0 I personally hav=
e
    no objections.

    

    

      
    o Security considerations: See Security Considerations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFCXXXX]" instead of "this document" =
here, so that when the
RFC is published, the registration template can be posted to IANA website a=
nd
will have correct reference.

    

    Ok

    

      
    o Applications that use this media type: MUD controllers as
      specified by this document.

As above.

    

    Ok

    

      
    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear <lear@cisco.com>, =
Ralph Droms <rdroms@cisco.com>

I think Ralph's address is wrong in 2 places.

    

    

    Corrected.

    

      
    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear <lear@cisco.com>
         Ralph Droms <rdroms@cisco.com&g=
t;
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).



    

    Ok.

    

    Thanks, all.

    

    Eliot

  






--089e0821fc0ca18e49056a0ab42e--


From nobody Tue Apr 17 05:57:04 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A495312EB35; Tue, 17 Apr 2018 05:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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
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 tsMx_SJlP3cm; Tue, 17 Apr 2018 05:56:52 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02F112EB27; Tue, 17 Apr 2018 05:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41032; q=dns/txt; s=iport; t=1523969812; x=1525179412; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=v7AJ0YKSl/La7uOJ/eYm8NwMYGJA74hRqNdwW0wCn7A=; b=WEc7y7R8F9qVvnFcKbjvI70kicJvNlhaVPRSGpsswDb8FIiw5eFjOVHs ATvVf8hiSlsh7pamzcudxjo8IkYJHsel6QBMEZQ8ILgsqaQ3lcNVuxGwl XQBCXF9/17446HdE/94JzQ7/0EtzgbW7EEP1Z5NlAoSG1npd0xv9ag4PO I=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,463,1517875200";  d="asc'?scan'208,217";a="3237579"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 12:56:49 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3HCumXQ020694; Tue, 17 Apr 2018 12:56:48 GMT
To: Spencer Dawkins at IETF 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com> <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com> 
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: 
Date: Tue, 17 Apr 2018 14:56:47 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LMgp3wXGSQth9gISkUjEeEzqXc9jvjKmi"
Archived-At: 
Subject: Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 12:56:58 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LMgp3wXGSQth9gISkUjEeEzqXc9jvjKmi
Content-Type: multipart/mixed; boundary="2K0gZbTkDa49BNMQqWOsPrgpxW3nuKVAB";
 protected-headers="v1"
From: Eliot Lear 
To: Spencer Dawkins at IETF 
Cc: The IESG , draft-ietf-opsawg-mud@ietf.org,
 Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: 
Subject: Re: (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on
 draft-ietf-opsawg-mud-20: (with COMMENT)
References: <152390575517.19640.3919526636067910532.idtracker@ietfa.amsl.com>
 <4218241e-f2d6-ad81-34df-0e538510c70b@cisco.com>
 
In-Reply-To: 

--2K0gZbTkDa49BNMQqWOsPrgpxW3nuKVAB
Content-Type: multipart/alternative;
 boundary="------------A21CAB7560FB4421E621E122"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------A21CAB7560FB4421E621E122
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 17.04.18 14:44, Spencer Dawkins at IETF wrote:
> Hi, Eliot,
>
> On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  > wrote:
>
>     Responding to Spencer, Ben, and Alexy (in order).
>
>
>     On 16.04.18 21:09, Spencer Dawkins wrote:
>>     Spencer Dawkins has entered the following ballot position for
>>     draft-ietf-opsawg-mud-20: Yes
>>
>>     When responding, please keep the subject line intact and reply to =
all
>>     email addresses included in the To and CC lines. (Feel free to cut=
 this
>>     introductory paragraph, however.)
>>
>>
>>     Please refer to https://www.ietf.org/iesg/statement/discuss-criter=
ia.html
>>     
>>     for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>     The document, along with other ballot positions, can be found here=
:
>>     https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>>     
>>
>>
>>
>>     ------------------------------------------------------------------=
----
>>     COMMENT:
>>     ------------------------------------------------------------------=
----
>>
>>     I'm a Yes who's watching Discussions with other ADs, but that's st=
ill a Yes.
>>     Thanks for doing this work.
>>
>>     I do have some questions and comments.
>>
>>     I don't think this requires any changes to the current document, b=
ut I note that
>>
>>     3.15.  direction-initiated
>>
>>        When applied this matches packets when the flow was initiated i=
n the
>>        corresponding direction.  [RFC6092] specifies IPv6 guidance bes=
t
>>        practices.  While that document is scoped specifically to IPv6,=
 its
>>        contents are applicable for IPv4 as well.  When this flag is se=
t, and
>>        the system has no reason to believe a flow has been initiated i=
t MUST
>>        drop the packet.  This node may be implemented in its simplest =
form
>>        by looking at naked SYN bits, but may also be implemented throu=
gh
>>        more stateful mechanisms.
>>
>>     it's not clear that "looking at naked SYN bits" will have an analo=
gy in HTTP/2
>>     over QUIC, and I'm a bit suspicious of "may also be implemented th=
rough more
>>     stateful mechanisms" in 2018. Do the right thing, of course.
>
>     I proposed a clarification: direction initiated is a TCP element.
>
>
> That is a clarification.=C2=A0
>
> I guess what I'm thinking, on reflection, is that direction is likely
> to be helpful for TCP-based communication, is not likely to be helpful
> for UDP-based communication without stateful inspection (so, my camera
> probably does need to act as a DNS client, but probably doesn't need
> to act as a DNS server), and is likely to be increasingly unhelpful if
> we really do see things using encrypted, UDP-based transports like QUIC=
=2E=C2=A0
>
> This does poke the "how are network managers going to manage networks
> running encrypted, UDP-based transport" bear, but that's way bigger
> than this document. Say as much as you think is helpful, and then move
> on, I think.

Well indeed.=C2=A0 I think the key here is to recognize that all MUD can =
do
is invoke network management capabilities already present in the
infrastructure.=C2=A0 "Picture if you will", however, a MUD extension tha=
t
modifies the meaning of "direction-initiated" to say, please do stateful
to allow stuff outbound, and re-adds the element in the UDP context.=C2=A0=

Absolutely possible.=C2=A0 I think it's a matter of whether the underlyin=
g
infrastructure broadly supports such a capability.



>>     Does
>>
>>     3.5.  is-supported
>>
>>        This boolean is an indication from the manufacturer to the netw=
ork
>>        administrator as to whether or not the Thing is supported.  In =
this
>>        context a Thing is said to not be supported if the manufacturer=

>>        intends never to issue an update to the Thing or never update t=
he MUD
>>        file.  A MUD controller MAY still periodically check for update=
s.
>>
>>     ever mean anything except "is-updated"?=20
>
>     Mostly that what it means, but the implication is that there's no
>     support, and enterprise administrators in particular might want to
>     know that (usually they do- because those devices represent a
>     particular risk).
>
>
> =C2=A0Here, I must apologize, because I've been thinking of MUD as the
> other side of a coin that also has SUIT, TEEP, and similar tools - If
> your Thing is just being installed and forgotten until it's an attack
> platform, you need MUD descriptions, but if your Thing is going to be
> updated, you should be looking at SUIT, TEEP, and whatever else seems
> helpful.=C2=A0
>
> I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
> that's a lack of imagination on my part, but the most relevant side
> effect of that, is that if you know what your printer needs to do, to
> be a network printer, and you get a MUD description for it, and the
> printer isn't going to be updated, that MUD description should be
> fine, forever.
>

I've been thinking about this as well.=C2=A0 Had MUD been completed later=
, I
would have wanted to leave a reference to the work, along the lines of
"MUD is part of a nutritious breakfast, along with SUIT, TEEP, etc".=C2=A0=
 By
the time we do v2, I expect us to do just that.

Regards,

Eliot

> I'm still connecting dots.
>
>>     "Supported" covers a lot of ground =E2=80=A6
>>
>>     If a manufacturer sells off one product line (so, flobbidy.example=
=2Ecom  covered
>>     multiple product lines, but now flobbidy.example.com/mark1/lightbu=
lb
>>      will be
>>     maintained by a manufacturer that isn't flobbidy.example.com ), is there a good
>>     plan for what comes next? I'm not sure what happens to is-supporte=
d, for
>>     instance.
>
>     The intent is that the entity providing the MUD file (probably the
>     manufacturer) will not be issuing software/firmware updates or MUD
>     file updates.=C2=A0 But your point is more about device lifecycle, =
and
>     that's a more interesting question than just "is-supported".=C2=A0
>     Steve Rich and Thorsten Dahm have begun to delve in that
>     direction.=C2=A0 There are at least a few possibilities, such as th=
e
>     use of redirects, or even domain names that are used for
>     particular classes of devices, or even common repos.=C2=A0 More wor=
k
>     needed.
>
>
> Yeah, and I didn't mean to slow MUD down waiting for that work. Just
> to be clear (hence, Yes).
> =C2=A0
>
>
>>     I'm sensitive to Eliot's "walk before trying to run" comment on an=
other ballot
>>     thread, but I'm thinking that
>>
>>     3.11.  model
>>
>>        This string matches the entire MUD URL, thus covering the model=
 that
>>        is unique within the context of the authority.  It may contain =
not
>>        only model information, but versioning information as well, and=
 any
>>        other information that the manufacturer wishes to add.  The int=
ended
>>        use is for devices of this precise class to match, to permit or=
 deny
>>        communication between one another.
>>
>>     might usefully result in a BCP about naming models, after the comm=
unity has
>>     some experience with MUD. So, that's not intended to affect the cu=
rrent draft
>>     text, only the working group that produced it ;-)
>>
>>     And, double ;-) ;-) but I wrote that before I saw this text in Sec=
tion 14:
>>
>>       A caution about some of the classes: admission of a Thing into t=
he
>>        "manufacturer" and "same-manufacturer" class may have impact on=

>>        access of other Things.  Put another way, the admission may gro=
w the
>>        access-list on switches connected to other Things, depending on=
 how
>>        access is managed.  Some care should be given on managing that
>>        access-list growth.  Alternative methods such as additional net=
work
>>        segmentation can be used to keep that growth within reason.
>>
>>     So, when people know enough to describe best practices, I hope the=
y do.
>>
>
>     Thanks, Spencer.=C2=A0 We're just getting going.
>
>
> And I'm darned glad to see that happening.
>
> Thanks for the quick responses.
>
> Spencer
> =C2=A0
>
>     Now to Ben:
>
>>     =C2=A71.6, 2nd paragraph: Why is the SHOULD not a MUST?
>
>     Because at this stage there is only one encoding and no source of
>     confusion as to what is returned, and the people implementing this
>     stuff are getting their feet wet.=C2=A0 If they're using a service =
that
>     simply doesn't include the right Accept: header, and the right
>     thing can still happen, let's let that happen.
>
>>     =C2=A71.8, 4th paragraph: "The web server is typically run by or o=
n behalf of the
>>     manufacturer.
>>        Its domain name is that of the authority found in the MUD URL. =
"
>>
>>     These URLS are likely to be hardcoded, correct? This seems to poin=
t to
>>     operational considerations, especially around Thing lifecycle and =
ownership.
>
>     Indeed.=C2=A0 It's captured in Security Considerations, but we can
>     place a forward pointer there.
>
>>     Editorial/Nits:
>>
>>     Abstract: I'm not sure the use of the term "Things" will be obviou=
s to a reader
>>     of the abstract in isolation from the rest of the document. (Abstr=
acts should
>>     be able to stand alone.)
>
>     EKR beat you to it.=C2=A0 Change proposed.
>>     =C2=A71.1 : first paragraph: The idea that a Thing might have high=
ly restricted
>>     communication patterns seems core to the document. It would be hel=
pful to
>>     mention that earlier in =C2=A71.
>
>     I think EKR beat you to this one as well ;-).=C2=A0 Change proposed=
=2E
>
>>     =C2=A71.3, definition of "Manufacturer": The definition says that =
"Manufacturer" may
>>     not necessarily be the entity that constructed the Thing. But that=
's the plain
>>     English meaning of the word "manufacturer". If you don't want it t=
o mean that,
>>     please consider choosing a different term. ( for example, "authori=
ty")
>
>     This one's harder to change, and authority has its own ambiguities.=

>
>>     =C2=A71.4: "... we assume that a device has so few
>>        capabilities that it will implement the least necessary capabil=
ities
>>        to function properly."
>>
>>     That's a bit circular. Perhaps one of the two instances of "capabi=
lities"
>>     should have been "requirements"?
>
>     How about:
>>     In seeking a general
>>     solution, however, we assume that a device will=C2=A0=C2=A0 =C2=A0=
implement
>>     functionality necessary to fulfill its limited purpose.
>
>
>>     =C2=A71.8 4th paragraph: The 2nd (and last) sentence is a comma sp=
lice, and
>>     otherwise difficult to parse.
>
>     That is a mouthful.=C2=A0 Propose:
>>     =C2=A0=C2=A0 The web server is typically run by or on behalf of th=
e
>>     manufacturer.
>>     =C2=A0=C2=A0 Its domain name is that of the authority found in the=
 MUD
>>     URL.=C2=A0 For
>>     =C2=A0=C2=A0 legacy cases where Things cannot emit a URL, if the s=
witch is
>>     able to
>>     =C2=A0=C2=A0 determine the appropriate URL, it may proxy it.=C2=A0=
 In the
>>     trivial case
>>     =C2=A0=C2=A0 it may hardcode MUD-URL on a switch port or a map fro=
m some
>>     =C2=A0=C2=A0 available identifier such as an L2 address or certifi=
cate hash
>>     to a
>>     =C2=A0=C2=A0 MUD-URL.
>
>
>>     =C2=A71.9, list item 7:  are we talking about transient disconnect=
 or permanent
>>     removal?
>
>     Could be either.=C2=A0 The only difference between the two is that =
at
>     some point someone has to CRUD the thing out of a database somewher=
e.
>>     =C2=A72: "A MUD file consists of a YANG model ..."
>>     A model instance, right? That is, not the model itself?
>
>     Indeed.
>>     =C2=A73.8, 2nd sentence: Consider reformulating this as a construc=
tion of MUST.
>
>     I think that's fair, and propose to change it to the following:
>
>>     Note that MUD extensions MUST NOT be used in a MUD file without
>>     the extensions being declared.=C2=A0 Implementations MUST ignore a=
ny node
>>     in this file that they do not understand.
>
>>     =C2=A74: The idea of a "default" in bullet 2 seems in tension with=
 the idea of
>>     "Anything not explicitly permitted is forbidden" in bullet 1.
>
>     Maybe so, but the intent here is that a great many devices are
>     going to be making use of DNS and NTP, and that not listing them
>     in a MUD file is more likely to lead to mistakes, rather than
>     accidentally listing them.
>
>>     =C2=A714: Please define the concept of "east-west infection".
>>
>
>     Propose "lateral infection" with a parenthetical definition.
>
>     On to Alexey:
>>     16.4.  MIME Media-type Registration for MUD files
>>
>>        The following media-type is defined for transfer of MUD file:
>>
>>         o Type name: application
>>         o Subtype name: mud+json
>>         o Required parameters: n/a
>>         o Optional parameters: n/a
>>         o Encoding considerations: 8bit; application/mud+json values
>>           are represented as a JSON object; UTF-8 encoding SHOULD be
>>           employed.
>>
>>     I am tempted to say "MUST be UTF-8 encoded".
>
>     In this day and age I think that sounds correct.=C2=A0 I personally=

>     have no objections.
>
>>         o Security considerations: See Security Considerations
>>           of this document.
>>         o Interoperability considerations: n/a
>>         o Published specification: this document
>>
>>     Nit: IANA Media Type registration templates need to have fully qua=
lified
>>     references. Use "[RFCXXXX]" instead of "this document" here, so th=
at when the
>>     RFC is published, the registration template can be posted to IANA =
website and
>>     will have correct reference.
>     Ok
>>         o Applications that use this media type: MUD controllers as
>>           specified by this document.
>>
>>     As above.
>     Ok
>>         o Fragment identifier considerations: n/a
>>         o Additional information:
>>
>>             Magic number(s): n/a
>>             File extension(s): n/a
>>             Macintosh file type code(s): n/a
>>
>>         o Person & email address to contact for further information:
>>           Eliot Lear  , Ralph D=
roms  
>>
>>     I think Ralph's address is wrong in 2 places.
>
>     Corrected.
>>         o Intended usage: COMMON
>>         o Restrictions on usage: none
>>         o Author:
>>              Eliot Lear  
>>              Ralph Droms  
>>         o Change controller: IESG
>>         o Provisional registration? (standards tree only): No.
>>
>>     UTF-8 needs to be a Normative reference (RFC 3629).
>>
>     Ok.
>
>     Thanks, all.
>
>     Eliot
>
>


--------------A21CAB7560FB4421E621E122
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 17.04.18 14:44, Spencer Dawkins at
      IETF wrote:

    

    

      
      
Hi, Eliot,
        


          
On Tue, Apr 17, 2018 at 1:43 AM,
            Eliot Lear <lear@cisco.com>
            wrote:

            

              

                
Responding to Spencer, Ben, and Alexy (in order).

                

                

                
On
                  16.04.18 21:09, Spencer Dawkins wrote:

                

                

                  
Spencer Dawkins has entered the following ballot p=
osition for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statemen=
t/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg=
-mud/



---------------------------------------------------------------=
-------
COMMENT:
---------------------------------------------------------------=
-------

I'm a Yes who's watching Discussions with other ADs, but that's still a Y=
es.
Thanks for doing this work.

I do have some questions and comments.

I don't think this requires any changes to the current document, but I no=
te that

3.15.  direction-initiated

   When applied this matches packets when the flow was initiated in the
   corresponding direction.  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.  When this flag is set, and
   the system has no reason to believe a flow has been initiated it MUST
   drop the packet.  This node may be implemented in its simplest form
   by looking at naked SYN bits, but may also be implemented through
   more stateful mechanisms.

it's not clear that "looking at naked SYN bits" will have an analogy in H=
TTP/2
over QUIC, and I'm a bit suspicious of "may also be implemented through m=
ore
stateful mechanisms" in 2018. Do the right thing, of course.

                

                

                I proposed a clarification: direction initiated is a TCP
                element.

              

            

            


            

            
That is a clarification.=C2=A0

            


            

            
I guess what I'm thinking, on reflection, is that
              direction is likely to be helpful for TCP-based
              communication, is not likely to be helpful for UDP-based
              communication without stateful inspection (so, my camera
              probably does need to act as a DNS client, but probably
              doesn't need to act as a DNS server), and is likely to be
              increasingly unhelpful if we really do see things using
              encrypted, UDP-based transports like QUIC.=C2=A0

            


            

            
This does poke the "how are network managers going to
              manage networks running encrypted, UDP-based transport"
              bear, but that's way bigger than this document. Say as
              much as you think is helpful, and then move on, I think. 
            

          

        

      

    

    

    Well indeed.=C2=A0 I think the key here is to recognize that all MUD =
can
    do is invoke network management capabilities already present in the
    infrastructure.=C2=A0 "Picture if you will", however, a MUD extension=

    that modifies the meaning of "direction-initiated" to say, please do
    stateful to allow stuff outbound, and re-adds the element in the UDP
    context.=C2=A0 Absolutely possible.=C2=A0 I think it's a matter of wh=
ether the
    underlying infrastructure broadly supports such a capability.

    

    

    

    

      

        

          

            

              

                

                  
Does

3.5.  is-supported

   This boolean is an indication from the manufacturer to the network
   administrator as to whether or not the Thing is supported.  In this
   context a Thing is said to not be supported if the manufacturer
   intends never to issue an update to the Thing or never update the MUD
   file.  A MUD controller MAY still periodically check for updates.

ever mean anything except "is-updated"? 

                

                

                Mostly that what it means, but the implication is that
                there's no support, and enterprise administrators in
                particular might want to know that (usually they do-
                because those devices represent a particular risk).

              

            

            


            

            
=C2=A0Here, I must apologize, because I've been thinking=
 of
              MUD as the other side of a coin that also has SUIT, TEEP,
              and similar tools - If your Thing is just being installed
              and forgotten until it's an attack platform, you need MUD
              descriptions, but if your Thing is going to be updated,
              you should be looking at SUIT, TEEP, and whatever else
              seems helpful.=C2=A0

            


            

            
I had not been thinking of using both MUD and
              SUIT/TEEP/whatever, and that's a lack of imagination on my
              part, but the most relevant side effect of that, is that
              if you know what your printer needs to do, to be a network
              printer, and you get a MUD description for it, and the
              printer isn't going to be updated, that MUD description
              should be fine, forever.

            


            

          

        

      

    

    

    I've been thinking about this as well.=C2=A0 Had MUD been completed
    later, I would have wanted to leave a reference to the work, along
    the lines of "MUD is part of a nutritious breakfast, along with
    SUIT, TEEP, etc".=C2=A0 By the time we do v2, I expect us to do just
    that.

    

    Regards,

    

    Eliot

    

    

      

        

          

            
I'm still connecting dots.

            

              

                

                  
"Supported" covers a lot of ground =E2=80=A6

If a manufacturer sells off one product line (so, flobbidy.exam=
ple.com covered
multiple product lines, but now flobbidy.exampl=
e.com/mark1/lightbulb will be
maintained by a manufacturer that isn't flobbidy.example.com), is there a good
plan for what comes next? I'm not sure what happens to is-supported, for
instance.

                

                

                The intent is that the entity providing the MUD file
                (probably the manufacturer) will not be issuing
                software/firmware updates or MUD file updates.=C2=A0 But =
your
                point is more about device lifecycle, and that's a more
                interesting question than just "is-supported".=C2=A0 Stev=
e
                Rich and Thorsten Dahm have begun to delve in that
                direction.=C2=A0 There are at least a few possibilities, =
such
                as the use of redirects, or even domain names that are
                used for particular classes of devices, or even common
                repos.=C2=A0 More work needed.

              

            

            


            

            
Yeah, and I didn't mean to slow MUD down waiting for
              that work. Just to be clear (hence, Yes).

            
=C2=A0

            

              
 

                

                  
I'm sensitive to Eliot's "walk before trying to ru=
n" comment on another ballot
thread, but I'm thinking that

3.11.  model

   This string matches the entire MUD URL, thus covering the model that
   is unique within the context of the authority.  It may contain not
   only model information, but versioning information as well, and any
   other information that the manufacturer wishes to add.  The intended
   use is for devices of this precise class to match, to permit or deny
   communication between one another.

might usefully result in a BCP about naming models, after the community h=
as
some experience with MUD. So, that's not intended to affect the current d=
raft
text, only the working group that produced it ;-)

And, double ;-) ;-) but I wrote that before I saw this text in Section 14=
:

  A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may have impact on
   access of other Things.  Put another way, the admission may grow the
   access-list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that
   access-list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

So, when people know enough to describe best practices, I hope they do.



                

                

                Thanks, Spencer.=C2=A0 We're just getting going.

              

            

            


            

            
And I'm darned glad to see that happening.

            


            

            
Thanks for the quick responses.

            


            

            
Spencer

            
=C2=A0

            

              
Now to Ben:

                

                

                  
=C2=A71.6, 2nd paragraph: Why is the SHOULD not a =
MUST?

                

                

                Because at this stage there is only one encoding and no
                source of confusion as to what is returned, and the
                people implementing this stuff are getting their feet
                wet.=C2=A0 If they're using a service that simply doesn't=

                include the right Accept: header, and the right thing
                can still happen, let's let that happen.

                

                

                  
=C2=A71.8, 4th paragraph: "The web server is typic=
ally run by or on behalf of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownersh=
ip.

                

                

                Indeed.=C2=A0 It's captured in Security Considerations, b=
ut
                we can place a forward pointer there.

                

                

                  
Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a =
reader
of the abstract in isolation from the rest of the document. (Abstracts sh=
ould
be able to stand alone.)

                

                

                EKR beat you to it.=C2=A0 Change proposed.

                

                  
=C2=A71.1 : first paragraph: The idea that a Thing=
 might have highly restricted
communication patterns seems core to the document. It would be helpful to=

mention that earlier in =C2=A71.


                

                

                I think EKR beat you to this one as well ;-).=C2=A0 Chang=
e
                proposed.

                

                

                  
=C2=A71.3, definition of "Manufacturer": The defin=
ition says that "Manufacturer" may
not necessarily be the entity that constructed the Thing. But that's the =
plain
English meaning of the word "manufacturer". If you don't want it to mean =
that,
please consider choosing a different term. ( for example, "authority")
                

                

                This one's harder to change, and authority has its own
                ambiguities.

                

                

                  
=C2=A71.4: "... we assume that a device has so few=

   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities"=

should have been "requirements"?


                

                

                How about:

                
In seeking a general

                  solution, however, we assume that a device will=C2=A0=C2=
=A0
                  =C2=A0implement

                  functionality necessary to fulfill its limited
                  purpose.

                

                

                

                  
=C2=A71.8 4th paragraph: The 2nd (and last) senten=
ce is a comma splice, and
otherwise difficult to parse.

                

                

                That is a mouthful.=C2=A0 Propose:

                
=C2=A0=C2=A0 The web server is =
typically
                  run by or on behalf of the manufacturer.

                  =C2=A0=C2=A0 Its domain name is that of the authority f=
ound in
                  the MUD URL.=C2=A0 For

                  =C2=A0=C2=A0 legacy cases where Things cannot emit a UR=
L, if the
                  switch is able to

                  =C2=A0=C2=A0 determine the appropriate URL, it may prox=
y it.=C2=A0 In
                  the trivial case

                  =C2=A0=C2=A0 it may hardcode MUD-URL on a switch port o=
r a map
                  from some

                  =C2=A0=C2=A0 available identifier such as an L2 address=
 or
                  certificate hash to a

                  =C2=A0=C2=A0 MUD-URL.

                

                

                

                  
=C2=A71.9, list item 7:  are we talking about tran=
sient disconnect or permanent
removal?

                

                

                Could be either.=C2=A0 The only difference between the tw=
o is
                that at some point someone has to CRUD the thing out of
                a database somewhere.

                

                  
=C2=A72: "A MUD file consists of a YANG model ..."=

A model instance, right? That is, not the model itself?

                

                

                Indeed.

                

                  
=C2=A73.8, 2nd sentence: Consider reformulating th=
is as a construction of MUST.

                

                

                I think that's fair, and propose to change it to the
                following:

                

                
Note that MUD extensions MUST
                  NOT be used in a MUD file without

                  the extensions being declared.=C2=A0 Implementations MU=
ST
                  ignore any node

                  in this file that they do not understand.

                

                

                  
=C2=A74: The idea of a "default" in bullet 2 seems=
 in tension with the idea of
"Anything not explicitly permitted is forbidden" in bullet 1.

                

                

                Maybe so, but the intent here is that a great many
                devices are going to be making use of DNS and NTP, and
                that not listing them in a MUD file is more likely to
                lead to mistakes, rather than accidentally listing them.<=
br>
                

                

                  
=C2=A714: Please define the concept of "east-west =
infection".



                

                

                Propose "lateral infection" with a parenthetical
                definition.

                

                On to Alexey:

                

                  
16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

                

                

                In this day and age I think that sounds correct.=C2=A0 I
                personally have no objections.

                

                

                  
    o Security considerations: See Security Consid=
erations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFCXXXX]" instead of "this document" here, so that when=
 the
RFC is published, the registration template can be posted to IANA website=
 and
will have correct reference.

                

                Ok

                

                  
    o Applications that use this media type: MUD c=
ontrollers as
      specified by this document.

As above.

                

                Ok

                

                  
    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear <lear@cisco.com>, Ralph Droms <rdroms@cisco.com>

I think Ralph's address is wrong in 2 places.

                

                

                Corrected.

                

                  
    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear <lear@cisco.com>
         Ralph Droms <rdroms@cisco.com>
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).



                

                Ok.

                

                Thanks, all.

                    

                    Eliot

                  

            

          

          

        

      

    

    

  


--------------A21CAB7560FB4421E621E122--

--2K0gZbTkDa49BNMQqWOsPrgpxW3nuKVAB--

--LMgp3wXGSQth9gISkUjEeEzqXc9jvjKmi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrV7xAACgkQh7ZrRtnS
ejM5OAf8D5r9WxXXF9uLZS7p4KikbGCe3Wy8T+aB2xU60QAPUnZXGeAeNEWZubfU
JZLhrECS4tNv22o+KnwkIvC1TRD3J91PpzvIJsImJ3PeQvYN8WIVw5j5y5YEnoQ8
naxKTMUSjTdZBcKCFiAh889REovBkX8aXk/l+SSdmLsV0qrtqQlbxQavZZZ8LwMo
Syp0VxuT+qX3DkhBD4yDhsGqGb6mqtVbniAhvUX52U9pff7ykI0DAN7OTXnOwVG1
ilGS0aXKb1eVsG5frhkTdHKfNpUGy3H3mpB7GnzhP6mEcHf9ZfLCfqg+uOiTJAk/
eIOTVMcXMnjt/m8IIfI4J0+39FieEA==
=Txek
-----END PGP SIGNATURE-----

--LMgp3wXGSQth9gISkUjEeEzqXc9jvjKmi--


From nobody Tue Apr 17 07:08:54 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 430CF12D94E; Tue, 17 Apr 2018 07:08:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ignas Bagdonas 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152397412726.11591.16253547587352358712.idtracker@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 07:08:47 -0700
Archived-At: 
Subject: [OPSAWG] Ignas Bagdonas' No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 14:08:47 -0000

Ignas Bagdonas has entered the following ballot position for
draft-ietf-opsawg-mud-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S2.1: Valid MUD file will contain "mud" and "acls" containers - what if it does
not, especially if it does not contain an ACL container - how will the
connectivity requirement be interpreted then?

A few nits:

s/MUR-URL/MUD-URL

s/yang/YANG in the document and module description fields.

s/dns/DNS in the modules.

S1, MUD building blocks section: "A URL that is can be used"



From nobody Tue Apr 17 07:15:59 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF212D94E for ; Tue, 17 Apr 2018 07:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 NdubCnK2COv6 for ; Tue, 17 Apr 2018 07:15:54 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4148F12D948 for ; Tue, 17 Apr 2018 07:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13256; q=dns/txt; s=iport; t=1523974554; x=1525184154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NyY4c3zBZpT6o2TGp9IP4qJiUHyMoNlFN6hfFDYbF/Y=; b=IBYBE5TPPkleZkTleFbmUNCNgz1Q+x77Qf8KoLXKP+zkbaazsBUDxkUU Zu/qUtDHBJAR2i+ss3/4mQ14HeEFSZD4JyloeFuzLaTpMnghNvquV/aso eMT4jb87HI/FDD5AQ2Jw796N2ukN3c0knn5j2jG1hAacobwxJngxJKus+ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAQAyANZa/5hdJa1dGwEBAQEDAQE?= =?us-ascii?q?BCQEBAYNCgVsyg16IAo0WgwOSaBSBZAuEaQIagj4hNBgBAgEBAQEBAQJsKIU?= =?us-ascii?q?jAwMjEUMCEAIBCBoCJgICAjAVEAIEAQ0ZhHmmO4IchFeDaoIlgQmGfYITgTK?= =?us-ascii?q?CaIRAARIBH4MAMIIkAoh5h2mHBggCiCeGEoE0g12HPIcziEkCERMBgSQBHDh?= =?us-ascii?q?hcXAVOyoBghmCHxeOF40lgR+BGAEB?=
X-IronPort-AV: E=Sophos;i="5.48,463,1517875200"; d="scan'208";a="379508428"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 14:15:53 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3HEFqlA003073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2018 14:15:53 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Apr 2018 09:15:52 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 17 Apr 2018 09:15:52 -0500
From: "Douglas Gash (dcmgash)" 
To: "opsawg@ietf.org" , "aland@deployingradius.com" 
CC: Andrej Ota , Thorsten Dahm 
Thread-Topic: New Version Notification for draft-ietf-opsawg-tacacs-10.txt
Thread-Index: AQHT1H7Q2+J+Xp+Us0+DREWATIPIOqQBsJiAgAOnaYA=
Date: Tue, 17 Apr 2018 14:15:52 +0000
Message-ID: 
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
In-Reply-To: <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.229.132.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <38993589CDAEA341B9DBD4E04C54757A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 14:15:57 -0000

SGkgQWxhbiwNCg0KSSBob3BlIHRoYXQgd2UgY2FuIGFkZHJlc3MgeW91ciBjb25jZXJucy4gSSB0
aGluayB0aGUgbWFpbiBwb2ludHMgdGhhdCB5b3UgcmFpc2UgdGhlIHdlICh0aGUgYXV0aG9ycykg
bmVlZCB0byBhZGRyZXNzIGFyZToNCg0KMSkgVGhlIHNlY3VyaXR5IHNlY3Rpb24NCjIpIFJlYWN0
aXZpdHkgb2YgdGhlIGF1dGhvcnMgDQozKSBDaGFuZ2UgVHJhY2tpbmcNCg0KMSkgVGhlIFNlY3Vy
aXR5IFNlY3Rpb24NCg0KVGhlIHN0YXJ0aW5nIHBvaW50IGlzIHRoYXQgd2Uga25vdyB0aGF0IFRB
Q0FDUysgbmVlZHMgZW5oYW5jZW1lbnQgZnJvbSBzZWN1cml0eSBwZXJzcGVjdGl2ZS4gVGhhdCB3
YXMgdGhlIHJlYXNvbiB0aGF0IHRoaXMgcHJvY2VzcyB3YXMgaW5pdGlhdGVkLCB0aGUgZmlyc3Qg
ZG9jdW1lbnQgYmVpbmcgbWFpbmx5IGFuIGFkYXB0aW9uIG9mIHRoZSBvcmlnaW5hbCBkcmFmdCB3
aXRoIHNlY3VyaXR5IGZlYXR1cmVzIHBsdXMgc29tZSBtaW5vciBjbGVhbnNpbmcuIFRoaXMgcGxh
biB3YXMgZXZvbHZlZCBpbnRvIHR3byBkb2N1bWVudHMsIHRoZSBmaXJzdCwgdGhhdCB3ZSBhcmUg
aW4gcHJvY2VzcyBvZiBwcmVwYXJpbmcsIHRoYXQgY29kaWZpZXMgdGhlIHByb3RvY29sLCB0byBi
ZSBmb2xsb3dlZCBieSB0aGUgdmVyc2lvbiB3aXRoIGVuaGFuY2VkIHNlY3VyaXR5Lg0KDQpJbml0
aWFsbHkgKHVwIHRvIGFyb3VuZCB2ZXJzaW9uIDUpIHdlIGluY2x1ZGVkIGp1c3QgYSB2ZXJ5IHNp
bXBsZSBzZWN1cml0eSBzZWN0aW9uIGFkbWl0dGluZyB0aGF0IFQrIHdhcyBpbnNlY3VyZSBhbmQg
dGhhdCB0aGUgc2Vjb25kIGRvY3VtZW50IHdvdWxkIGFkZHJlc3MgdGhlIGlzc3VlLiBUaGlzIHdh
cyBkZWVtZWQgdG8gYmUgaW5zdWZmaWNpZW50LCBhbmQgaW5zdGVhZCB0aGUgV0cgY29sbGVjdGl2
ZWx5IGRldGVybWluZWQgdGhhdCBtb3JlIGRldGFpbCBzaG91bGQgYmUgYWRkZWQgdG8gZW51bWVy
YXRlIHNvbWUgb2YgdGhlIGlzc3VlcywgeW91IGtpbmRseSBjYXRhbG9ndWVkIHNvbWUgb2YgdGhl
c2UsIHByb3ZpZGluZyBhIHByb3Bvc2VkIHRleHQgd2hpY2ggd2UgdG9vayB0byBiZSBhIGdlbnVp
bmUgc3VnZ2VzdGlvbiBmb3IgdGV4dCBmb3IgdGhlIGRvY3VtZW50LiBTdWJzZXF1ZW50bHkgd2Ug
aW50ZXJwcmV0ZWQgeW91ciBwcm9wb3NhbCBtb3JlIGFjY3VyYXRlbHkgKGFzIGp1c3QgYSBzdWdn
ZXN0aW9uIG9mIHRoZSBwb2ludHMgdG8gY292ZXIpLCBhbmQgc28gd2UgbWFkZSBzdXJlIHRoYXQg
dGhlc2Ugd2VyZSBjb3ZlcmVkLCBidXQgd2l0aG91dCB2ZXJiYXRpbSByZXVzZSBvZiB0aGUgdGV4
dC4gIFdlIGhvcGUgdGhhdCB3ZSBoYXZlIGNvdmVyZWQgdGhlIHRocnVzdCBvZiB5b3VyIGlzc3Vl
cyAoYW5kIG90aGVycyksIGJ1dCB3aXRob3V0IHRoZSBwbGFnaWFyaXNtLg0KDQoyKSBSZWFjdGl2
aXR5IG9mIHRoZSBBdXRob3JzLg0KDQpBcyBmYXIgYXMgSSBrbm93LCB3ZSBoYXZlIHJlc3BvbmRl
ZCB0byBtb3N0IHBvc3RzIHJlZ2FyZGluZyB0aGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQsIHdp
dGggcG9pbnQtYnktcG9pbnQgcmVwbGllcywgYnV0IHRoZXJlIGhhcyBiZWVuLCBmb3IgdmFyaW91
cyBsb2dpc3RpYyByZWFzb25zLCBsb25nIGRlbGF5cyBpbiBzdWJtaXR0aW5nIHRoZSByZXN1bHRp
bmcgbmV3IGRvY3VtZW50cy4gSG9wZWZ1bGx5IHRoaXMgaGFzIGJlZW4gYWRkcmVzc2VzIGluIGxh
c3QgdmVyc2lvbnMgYW5kIHdlIHdpbGwgY29udGludWUgd2l0aCBtb3JlIHJhcGlkIHVwbG9hZHMg
dW50aWwgcHJvY2VzcyBjb21wbGV0ZXMgb25lIHdheSBvciBvdGhlci4NCg0KV2UgaGF2ZSBub3Qg
Z2VuZXJhbGx5IHJlc3BvbmRlZCB0byBwb3N0cyByZWdhcmRpbmcgcHJvY2VkdXJhbCBtYXR0ZXJz
LCBhbmQgd291bGQgbGVhdmUgc3VjaCBkaXNjdXNzaW9ucyB0byBtb3JlIGtub3dsZWRnZWFibGUg
c3Rld2FyZHMgb2YgdGhlIGxpc3RzIHdoZXJlIHBvc3NpYmxlLA0KDQozKSBDaGFuZ2UgVHJhY2tp
bmcNCg0KVGhlIHVwbG9hZHMgaGF2ZSBnZW5lcmFsbHkgaGFkIGV4dGVuc2l2ZSBjaGFuZ2VzIHJl
bGF0aW5nIHRvIGNvbW1lbnRzICh3aGljaCBzaG91bGQgZ2VuZXJhbGx5IGhhdmUgYmVlbiBzdW1t
YXJpemVkIGJ5IHByZXZpb3VzIGVtYWlsIHJlc3BvbnNlcyB0byBjb21tZW50cykuIEJlY2F1c2Ug
b2YgdGhpcywgdW5sZXNzIHRoZSB1cGRhdGVzIGhhdmUgYmVlbiBmb3Igc3BlY2lmaWMgcHVycG9z
ZXMgKHN1Y2ggYXMgdGhlIHJlY2VudCB1cGRhdGUgb2YgdGhlIHNlY3VyaXR5IHNlY3Rpb24pIHRo
ZW4gSSB3b3VsZCBsZWF2ZSB0aGUgY2hhbmdlcyB0byB0aGUgZGlmZiB0b29sIHdoaWNoIHdvcmtz
IHByZXR0eSBlZmZlY3RpdmVseS4NCg0KUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGFyZSBz
cGVjaWZpYyBwb2ludHMgYmVsb3cgdGhhdCB5b3XigJlkIGxpa2UgdG8gYWRkcmVzcyB3aGljaCB3
b3VsZCBub3QgYmUgY292ZXJlZCBhYm92ZS4NCg0KTWFueSB0aGFua3MsDQoNClJlZ2FyZHMsDQoN
CkRvdWcNCg0KDQogUmVzcG9uZGluZyB0bzoNCg0K4oCcSSBoYXZlIHNvbWUgY29uY2VybnMgd2l0
aCB0aGUgZG9jdW1lbnQsIGFuZCB3aXRoIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHdlJ3ZlIGdvdHRl
biBoZXJlLg0KDQogIExldCBtZSByZWNhcCBzb21lIGhpc3RvcnkuICBUaGVyZSdzIGEgbG90IHRv
IHRha2UNCmluLCBzbyBJJ2xsIHByZXNlbnQgY29uY2VybnMgaW4gcG9pbnQgZm9ybS4NCg0KICBG
aXJzdCwgdGhlIGRvY3VtZW50Lg0KDQoqIG15ICJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgdGV4
dCB3YXMgZmlyc3QgcGxhZ2FyaXNlZCBpbiBkcmFmdC0wNiwNCg0KKiB3aGVuIEkgcG9pbnRlZCB0
aGlzIG91dCAoTWF5IDksIDIwMTcpLCB0aGVyZSB3YXMgbm8gcmVwbHkgdG8gbXkNCiAgbWVzc2Fn
ZSBieSB0aGUgYXV0aG9ycywgYW5kIG5vIGNoYW5nZSB3YXMgbWFkZSB0byB0aGUgZG9jdW1lbnQu
DQoNCiogdGhlIEFEcyBkaWQgcmVzcG9uZCwgYW5kIGluZGljYXRlZCB0aGF0IHRoZXkgaGFkIHRh
bGtlZCB0byB0aGUNCiAgYXV0aG9ycyBhYm91dCB0aGUgaXNzdWUsIGFuZCB0aGF0IGl0IHdhcyBh
IHNpbXBsZSBtaXN1bmRlcnN0YW5kIGFuZA0KICB3b3VsZCBiZSBmaXhlZC4NCg0KKiBBIHllYXIg
bGF0ZXIsIEkgcmFpc2VkIHRoZSBpc3N1ZSBhZ2FpbiAoTWFyY2ggMjAxOCkuICBUaGVyZSBhcyBu
bw0KICByZXBseSB0byBteSBjb25jZXJucyBieSB0aGUgYXV0aG9ycywgYW5kIG5vIGNoYW5nZSB3
YXMgbWFkZSB0byB0aGUNCiAgZG9jdW1lbnQuDQoNCiogaW4gYWxsLCA0IHNlcGFyYXRlIHJldmlz
aW9ucyBvZiB0aGUgZG9jdW1lbnQgcGxhZ2FyaXplZCBteSB0ZXh0LCBmb3INCiAgb3ZlciBhIHll
YXIsIHNvbWV0aW1lcyB3aXRoIG1pbm9yIGVkaXRzLCBkZXNwaXRlIHJlcGVhdGVkIHJlcXVlc3Rz
DQogIHRvIGFkZHJlc3MgdGhlIGlzc3VlLg0KDQogIFRob3NlIGlzc3VlcyBhbG9uZSBhcmUgc3Vy
cHJpc2luZy4NCg0KKiBUaGUgdGV4dCB3aGljaCB3YXMgZ29vZCBlbm91Z2ggdG8gcGxhZ2FyaXpl
IHdhcyB0aGVuIGNsYWltZWQgdG8gaGF2ZQ0KICBkZWZpY2llbmNpZXMNCg0KKiBubyBvbmUgaW4g
dGhlIFdHIGhhZCBub3RlZCBhbnkgdGVjaG5pY2FsIGlzc3VlcyB3aXRoIHRoZSB0ZXh0DQoNCiog
dGhlIG9ubHkgaXNzdWVzIHdlcmUgd2l0aCBhdHRyaWJ1dGlvbiwgbm90IHdpdGggdGhlIHRleHQg
aW4gdGhlDQogIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24NCg0KKiB0aGVyZSBpcyBu
b3cgYSAtMTAsIHdoaWNoIGhhcyBlc3NlbnRpYWxseSB0aGUgc2FtZSBwb2ludHMgYXMgdGhlDQog
IHByZXZpb3VzIHRleHQsIGp1c3QgcmV3b3JkZWQNCg0KDQoNCg0KDQoNCiAgSSBzaG91bGQgcG9p
bnQgb3V0IHRoYXQgdGhlIFJGQyBwcm9jZXNzIGlzIHN1cHBvc2VkIHRvIGJlIGFib3V0DQpjb250
ZW50LCBub3QgYXV0aG9yc2hpcC4gIFRoZXJlIGFyZSBtYW55IFJGQ3MgaXNzdWVkIHdpdGggdGV4
dCB3cml0dGVuDQpieSBtdWx0aXBsZSBwZW9wbGUuICBXaGVyZSB0aGUgYXV0aG9ycyBjYW5ub3Qg
YWxsIGJlIGFja25vd2xlZGdlZCBvbg0KdGhlIGZpcnN0IHBhZ2UsIHRoZSBwcmltYXJ5IGVkaXRv
ciBjYW4gYmUgbGlzdGVkIHdpdGggdGhlIChFZC4pDQpzdWZmaXgsIHRvIGluZGljYXRlIGVkaXRv
cnNoaXAuICBPdGhlciBhdXRob3JzIGNhbiBiZSBuYW1lZCBhcyBhdXRob3JzDQpvbiB0aGUgZmly
c3QgcGFnZSwgb3IgaW4gdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4NCg0KICBTZWNvbmQs
IGNvbmNlcm5zIHdpdGggZW5nYWdlbWVudCB3aXRoIHRoZSBXRy4gIEl0IGNvbnRpbnVlcy4NCg0K
KiBtdWx0aXBsZSBwZW9wbGUgaW4gdGhlIFdHIGhhdmUgcmVxdWVzdGVkIHRoZSBhdXRob3JzIGVu
Z2FnZSB3aXRoIHRoZQ0KICBXb3JraW5nIEdyb3VwLiAgTW9zdCBub3RhYmx5LCBtYW55IG1lc3Nh
Z2VzIGluIE1heSAyMDE3Lg0KDQoqIG11bHRpcGxlIHBlb3BsZSBpbiB0aGUgV0cgaGF2ZSByZXF1
ZXN0ZWQgdGhlIGF1dGhvcnMgZXhwbGFpbiB3aGF0J3MNCiAgY2hhbmdlZCBpbiBlYWNoIG5ldyBy
ZXZpc2lvbiwgb3IgcGVyaGFwcyB0byBhY2tub3dsZWdlIGNvbW1lbnRzIGFuZA0KICByZXZpZXdz
IChNYXkgMjAxNyBhZ2FpbiwgYW1vbmcgb3RoZXIgdGltZXMpLg0KDQoqIFRoaXMgZW5nYWdlbWVu
dCBoYXMgYmVlbiBtaW5pbWFsLCBkZXNwaXRlIG11bHRpcGxlIHJldmlzaW9ucyBvZg0KICB0aGUg
ZG9jdW1lbnQgYmVpbmcgcHVibGlzaGVkIGFmdGVyIHRoZXNlIFdHIHJlcXVlc3RzLg0KDQoqIG5l
dyByZXZpc2lvbnMgaGF2ZSBtb3N0IG9mdGVuIGJlZW4gInRocm93biBvdmVyIHRoZSB3YWxsIiB3
aXRoDQogIG1pbmltYWwgKG9yIG5vKSBleHBsYW5hdGlvbiBhcyB0byB3aGF0IGNoYW5nZWQsIGFu
ZCB3aHkuDQoNCiogdGhpcyBuZXcgZHJhZnQgaXMgbm8gZGlmZmVyZW50LCBpLmUuIGl0ICJyZXZp
c2VkIHRoZSBzZWN1cml0eQ0KICBzZWN0aW9uIi4gIFdoeT8gIEhvdz8gIFdoYXQgY2hhbmdlZD8g
IFdoYXQgd2VyZSBhbnkgYWxsZWdlZA0KICAiZGVmaWNpZW5jaWVzIj8NCg0KKiB0aGUgYXV0aG9y
IGhhdmUgc3RhdGVkIGFnYWluIHRoYXQgdGhleSAid2lsbCBlbmRlYXZvciB0byBiZSBtdWNoDQog
IG1vcmUgcmVhY3RpdmUgdG8gY29tbWVudHMiLg0KDQoqIHRoaXMgc3RhdGVtZW50IG9yIHNpbWls
YXIgb25lcyBoYXZlIGJlZW4gcmVwZWF0ZGx5LCB3aXRoIGxpdHRsZQ0KICBjaGFuZ2UgaW4gb2Jz
ZXJ2YWJsZSBiZWhhdmlvci4NCg0KKiBUaGUgYXV0aG9ycyByZXF1ZXN0IChhZ2FpbikgdGhhdCB0
aGUgV0cgcmV2aWV3IHRoaXMgbmV3IGRvY3VtZW50DQogIHdob2xlc2FsZS4NCg0KICBTcGVha2lu
ZyBvZiByZXZpZXdzLCBsZXQncyBjb250aW51ZSB3aXRoIHRoaXJkLCByZXNwb25zZXMgdG8NCnJl
dmlld3MuDQoNCiogSSBoYXZlIGdpdmVuIG11bHRpcGxlIGxpbmUtYnktbGluZSByZXZpZXdzIG9m
IHRoZSBlbnRpcmUgZG9jdW1lbnQsDQogIGZvciBtdWx0aXBsZSByZXZpc2lvbnMgb2YgdGhlIGRv
Y3VtZW50Lg0KDQoqIGFzIG5vdGVkIGFib3ZlLCB0aGVzZSByZXZpZXdzIGhhdmUgZ2VuZXJhbGx5
IGJlZW4gaWdub3JlZC4NCg0KKiBhcyBub3RlZCBhYm92ZSwgbmV3IHZlcnNpb25zIG9mIHRoZSBk
b2N1bWVudCBoYXZlIGFwcGVhcmVkIHdoaWNoIG1heQ0KICBvciBtYXkgbm90IGhhdmUgYWRkcmVz
c2VkIHRoZXNlIHJldmlld3MuDQoNCiogR2l2ZW4gdGhlIGxhY2sgb2YgZmVlZGJhY2sgb24gdGhl
IHJldmlld3MgYmVmb3JlIGEgbmV3IGRyYWZ0IGlzDQogIGlzc3VlZCwgaXQgaXMgdW5jbGVhciB3
aGV0aGVyIHRoZSByZXZpZXcgY29tbWVudHMgaGF2ZSBiZWVuDQogIGFkZHJlc3NlZC4NCg0KKiBk
dWUgdG8gdGhlc2UgaXNzdWVzLCBJIGhhdmUgc3RvcHBlZCByZXZpZXdpbmcgdGhlIGRvY3VtZW50
LCBhcyBpdA0KICBpcyBub3QgcHJvZHVjdGl2ZS4NCg0KICBUaGVyZSBhcmUgb3RoZXIgaXNzdWVz
IHdpdGggdGhlIGxhcmdlciBjb21tdW5pdHkuICBJJ2xsIGNvbnRpbnVlLg0KDQoqIHRoZXJlIHdh
cyBicm9hZCBzdXBwb3J0IGZvciBwdWJsaWNhdGlvbiBvZiBlYXJseSByZXZpc2lvbnMgb2YgdGhl
DQogIGRvY3VtZW50LCBkZXNwaXRlIGl0IGNsZWFybHkgbm90IGRlc2NyaWJpbmcgdGhlIHByb3Rv
Y29sIGluIGEgd2F5DQogIHRoYXQgcGVybWl0cyBpbnRlci1vcGVyYWJsZSBpbXBsZW1lbnRhdGlv
bnMNCg0KKiB0aGUgcGVvcGxlIHdobyBzdXBwb3J0ZWQgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGFz
IGEgV0cgZG9jdW1lbnQNCiAgaGF2ZSBnZW5lcmFsbHkgbm90IHJldmlld2VkIG9yIGNvbW1lbnRl
ZCBvbiBpdA0KDQoqIGV4aXN0aW5nIGltcGxlbWVudG9ycyBvZiBUQUNBQ1MrIGhhdmUgbm90IHJl
dmlld2VkIG9yIGNvbW1lbnRlZCBvbg0KICB0aGUgZG9jdW1lbnQgKEFsZXggQ2xvdXRlcidzIHJl
dmlldyB3YXMgZG9uZSBhcyBwYXJ0IG9mIGEgYnJhbmQtbmV3DQogIGltcGxlbWVudGF0aW9uKQ0K
DQoqIHdlIGhhdmUgdGhlcmVmb3JlIG5vIGlkZWEgd2hldGhlciBvciBub3QgdGhpcyBkb2N1bWVu
dCBkZXNjcmliZXMNCiAgYW55dGhpbmcgdGhhdCBhbnlvbmUgaGFzIGltcGxlbWVudGVkDQoNCiAg
SW4gb3JkZXIgZm9yIHRoZSBkb2N1bWVudCB0byBiZSBwdWJsaXNoZWQsIHdlIHNob3VsZCBoYXZl
IChhdCB0aGUNCm1pbmltdW0pIHN0YXRlbWVudHMgZnJvbSBtdWx0aXBsZSBpbXBsZW1lbnRvcnMg
dGhhdCB0aGUgZHJhZnQgbWF0Y2hlcw0KdGhlaXIgaW1wbGVtZW50YXRpb25zLg0KDQogIEZvdXJ0
aCwgdGhlcmUgYXJlIHByb2Nlc3MgaXNzdWVzLCB0b28uICBJJ2xsIGNvbnRpbnVlLg0KDQoqIHRo
ZSBJRVRGIGhhcyB0cmFkaXRpb25hbGx5IHN0YXJ0ZWQgYSBuZXcgV0cgdG8gc3RhbmRhcmRpemUg
bmV3DQogIG1hbmFnZW1lbnQgcHJvdG9jb2xzIChpLmUuIGEgcHJvdG9jb2wgbmV3IHRvIHRoZSBJ
RVRGKQ0KDQoqIGV4YW1wbGVzIGluY2x1ZGUgdGhlIHByb3RvY29scyBkZXNjcmliZWQgaW4gUkZD
IDY2MzIuICBUaGVzZQ0KICBwcm90b2NvbHMgaGF2ZSBoYWQgdGhlaXIgb3duIHdvcmtpbmcgZ3Jv
dXBzLCBnb2luZyBiYWNrIHRvIGF0IGxlYXN0DQogIDE5OTYsIGFuZCBjb250aW51aW5nIHRvIHRo
ZSBwcmVzZW50DQoNCiogd29ya2luZyBvbiBhIG5ldyAoYW5kIGV2ZW50dWFsbHkgc3RhbmRhcmRz
IHRyYWNrKSBkb2N1bWVudCBpbiB0aGUNCiAgT1BTIGFyZWEgaXMgdGhlcmVmb3JlIGEgbmV3IHN0
ZXAgZm9yIHRoZSBJRVRGDQoNCiogSSBoYXZlIHJhaXNlZCBhbGwgb2YgdGhlIGNvbmNlcm5zIG1l
bnRpb25lZCBoZXJlaW4gd2l0aCB0aGUgY2hhaXJzDQogIGFuZCBBRHMgaW4gcHJpdmF0ZSBlbWFp
bCwgcHVibGljIGVtYWlsIG9uIHRoZSBsaXN0LCBhbmQgaW4gcGVyc29uIGF0DQogIG11bHRpcGxl
IG1lZXRpbmdzDQoNCiogVGhlcmUgZG9lcyBub3QgYXBwZWFyIHRvIGJlIGFueSBhY3Rpb24gdGFr
ZW4gYXMgYSByZXN1bHQuDQoNCiogTWVzc2FnZXMgdG8gdGhlIGxpc3QgcmFpc2luZyB0aGVzZSBp
c3N1ZXMgaGF2ZSBsYXJnZWx5IGJlZW4NCiAgdW5hZGRyZXNzZWQNCg0KICBJdCBpcyBnZW5lcmFs
IElFVEYgcHJhY3RpY2UgZm9yIGRvY3VtZW50IGF1dGhvcnMgdG8gaW50ZXJhY3Qgd2l0aA0KdGhl
IFdHLiBBbmQsIHRvIHJlc3BvbmQgdG8gV0cgcmV2aWV3cyBhbmQgY29tbWVudHMuICBTZWUgdGhl
IG1hbnkNCmNvbW1lbnRzIGluIHRoZSBPUFNBV0cgYXJjaGl2ZXMgaW4gTWF5IDIwMTcgZm9yIGJy
b2FkIFdHIHN1cHBvcnQgb2YNCnRoaXMgcG9zaXRpb24uDQoNCiAgQXMgdGhlIGF1dGhvcnMgaGF2
ZSBsYXJnZWx5IGlnbm9yZWQgdGhlIFdHIGNvbW1lbnRzLCB0aGUgY2hhaXJzIGFuZA0KQURzIHNo
b3VsZCBoYXZlIHRha2VuIHN0ZXBzIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4gIEFzIG9mIHRoaXMN
CndyaXRpbmcsIGl0IGFwcGVhcnMgdG8gYmUgdGhlIHNhbWUgInN0YXR1cyBxdW8iIG9mIHRoZSBw
YXN0IGZldyB5ZWFycy4NCg0KICBJIGRvbid0IHRoaW5rIHRoZXNlIGNvbW1lbnRzIGFyZSB1bnJl
YXNvbmFibGUuICBJZiB3ZSB0cnVseSBkb24ndA0KY2FyZSBhYm91dCB0aGUgV0cgb3Bpbmlvbiwg
dGhlbiB0aGUgY2hhaXJzIGFuZCBBRCBjYW46DQoNCiogbWFrZSBhIHB1YmxpYyBzdGF0ZW1lbnQg
c2F5aW5nIHRoYXQgV0cgZmVlZGJhY2sgY2FuIGJlIGlnbm9yZWQNCg0KKiBzdGF0ZSB0aGF0IHRo
YXQgdGhlIGRvY3VtZW50IGNhbiBiZSBwdWJsaXNoZWQgaW4gd2hhdGV2ZXIgZm9ybSB0aGUNCiAg
YXV0aG9ycyBjaG9vc2UNCg0KKiBwdWJsaXNoIHRoZSBkb2N1bWVudCBldmVuIGlmIGl0IGRvZXMg
bm90IGRlc2NyaWJlIHRoZSBwcm90b2NvbCBpbg0KICBzdWZmaWNpZW50IGRldGFpbCB0byBjcmVh
dGUgaW50ZXItb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQogIEkgZG9uJ3QgdGhpbmsgdGhh
dCdzIHRoZSByaWdodCBhcHByb2FjaCwgb2YgY291cnNlLiAgQnV0IGl0J3MNCmxhcmdlbHkgd2hh
dCdzIGJlZW4gaGFwcGVuaW5nIGR1ZSB0byBzaWxlbmNlIGFuZC9vciBpbmFjdGlvbiBvZiB0aGUN
CnBhcnRpZXMgaW52b2x2ZWQuDQoNCiAgSSBzZWUgbm8gcG9pbnQgaW4gZnVydGhlciByZXZpZXdp
bmcgdGhlIGRvY3VtZW50LiAgSSBhZ2FpbiBvcHBvc2UNCnB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j
dW1lbnQgdW50aWwgc3VjaCB0aW1lIGFzIGFsbCBvZiB0aGUgV0cgaXNzdWVzDQpoYXZlIGJlZW4g
YWRkcmVzc2VkLg0KDQogIElmIHdlIGRvIGFjdHVhbGx5IGNhcmUgYWJvdXQgd2hhdCdzIGluIHRo
ZSBkb2N1bWVudCwgdGhlbiBJIHN1Z2dlc3QNCmZpbmFsbHkgdGhlIGZvbGxvd2luZyBzdGVwcyBi
ZSB0YWtlbiB0byBhZGRyZXNzIHRoZSBvbmdvaW5nIGNvbmNlcm5zOg0KDQoqIHRoZSBkb2N1bWVu
dCBzaG91bGQgbm90IGJlIHB1Ymxpc2hlZCB1bnRpbCBzdWNoIHRpbWUgYXMgbXVsdGlwbGUNCiAg
aW1wbGVtZW50b3JzIGhhdmUgYWdyZWVkIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gbWF0Y2hlcyB0
aGVpcg0KICBpbXBsZW1lbnRhdGlvbi4NCg0KKiB0aGUgY2hhaXJzIGFuZCBBRHMgc2hvdWxkIGlu
c2lzdCB0aGF0IHRoZSBhdXRob3JzIGFkZHJlc3MgdGhlDQogIG91dHN0YW5kaW5nIFdHIGNvbmNl
cm5zIGFib3V0IHRoaXMgZG9jdW1lbnQNCg0KKiB0aGUgY2hhaXJzIGFuZCBBRHMgc2hvdWxkIGlu
c2lzdCB0aGF0IGF1dGhvcnMgZm9sbG93IGVzdGFibGlzaGVkDQogIHByYWN0aWNlIG9mICppbnRl
cmFjdGluZyogd2l0aCB0aGUgV0csIGluY2x1ZGluZyByZXNwb25kaW5nIHRvDQogIGZ1dHVyZSBy
ZXZpZXdzIGFuZCBjb21tZW50cy4NCg0KKiB0aGUgY2hhaXJzIGFuZCBBRHMgc2hvdWxkIGluc2lz
dCB0aGF0IG5ldyByZXZpc2lvbnMgb2YgdGhlIGRvY3VtZW50DQogIGFyZSBhY2NvbXBhbmllZCBi
eSBhbiBleHBsYW5hdGlvbiBvZiB3aGF0IGNoYW5nZWQsIGFuZCB3aHkNCg0KKiB0aGF0IGlmIHRo
ZSBhdXRob3JzIGRvIG5vdCBmb2xsb3cgdGhlc2Ugc3RlcHMgKGFzIHRoZXkgaGF2ZSBub3Qgc28N
CiAgZmFyKSwgdGhhdCB0aGUgY2hhaXJzIGFuZCBBRHMgc2hvdWxkIHJlcGxhY2UgdGhlbSB3aXRo
IG90aGVyIFdHDQogIG1lbWJlcihzKSB3aG8gd2lsbCBmb2xsb3cgdGhlIElFVEYgcHJvY2Vzcy4N
Cg0KICBBbGFuIERlS29rLg0KDQrigJ0gICAgDQogICAgICAgIA0KICAgIA0KICAgIA0KDQo=


From nobody Tue Apr 17 08:07:16 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820D1242F7 for ; Tue, 17 Apr 2018 08:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 gHc6DesWw5ie for ; Tue, 17 Apr 2018 08:07:12 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE551200C5 for ; Tue, 17 Apr 2018 08:07:12 -0700 (PDT)
Received: from [192.168.20.43] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 6CFED480; Tue, 17 Apr 2018 15:07:11 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok 
In-Reply-To: 
Date: Tue, 17 Apr 2018 11:07:09 -0400
Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com> 
To: "Douglas Gash (dcmgash)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 15:07:15 -0000

On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash)  =
wrote:
> Initially (up to around version 5) we included just a very simple =
security section admitting that T+ was insecure and that the second =
document would address the issue. This was deemed to be insufficient, =
and instead the WG collectively determined that more detail should be =
added to enumerate some of the issues, you kindly catalogued some of =
these, providing a proposed text which we took to be a genuine =
suggestion for text for the document.

  Which it was.

  The point I've been trying to make for over a year is apparently still =
unclear.

  There was no excuse for plagiarizing the text in the first place.  =
Using it verbatim was fine, so long as attribution was given.

  There was no excuse for ignoring every single email I made to the list =
asking about this issue.

  There was no excuse for *continuing* to plagiarize the text for over a =
year, across four separate revisions of the document.

> Subsequently we interpreted your proposal more accurately (as just a =
suggestion of the points to cover), and so we made sure that these were =
covered, but without verbatim reuse of the text.  We hope that we have =
covered the thrust of your issues (and others), but without the =
plagiarism.

  I have no idea.  Because at this point, I'm pretty much done reviewing =
the document.

> 2) Reactivity of the Authors.
>=20
> As far as I know, we have responded to most posts regarding the =
content of the document, with point-by-point replies,

  No.

  See the list archives, especially May 2017.  There are multiple people =
suggesting that you have *not* done this, and that you *should* do this.

  See line-by-line reviews done by me, which were generally ignored.  =
Despite that, I did *multiple* such reviews, until such time as it =
became clear that such reviews were entirely unproductive.

> but there has been, for various logistic reasons, long delays in =
submitting the resulting new documents. Hopefully this has been =
addresses in last versions and we will continue with more rapid uploads =
until process completes one way or other.

  The issue isn't rapid uploads.  The issue is engagement.  It's not =
productive to ignore the messages on the mailing list for 6 months, and =
then to issue a new release saying "we fixed stuff".

> We have not generally responded to posts regarding procedural matters, =
and would leave such discussions to more knowledgeable stewards of the =
lists where possible,

  You haven't responded to posts where I ask about the plagiarism.  A =
simple reply of "oops, sorry, I'll fix it ASAP" has taken over a year to =
write.

> 3) Change Tracking
>=20
> The uploads have generally had extensive changes relating to comments =
(which should generally have been summarized by previous email responses =
to comments).=20

  Which I admit did happen sometimes, but not nearly as often as it =
should have.  Again, see mailing list archives from May 2017.  I'm not =
the only person who holds this opinion.  I'm just the main one pushing =
the point.

> Because of this, unless the updates have been for specific purposes =
(such as the recent update of the security section) then I would leave =
the changes to the diff tool which works pretty effectively.

  The diff tool lets us know what changed in the document.  It doesn't =
let us know if those changes addressed issues raise on the mailing list.

  To summarize:

* we have no idea if this revision of the document addresses multiple WG =
reviews

* we have no idea if the document even describes TACACS+ as currently =
implemented

  As such, it should not be put into working group last call, or much =
less published until such time as those issues are addressed.

  Alan DeKok.


From nobody Tue Apr 17 08:12:57 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D42126C2F; Tue, 17 Apr 2018 08:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 UZhLXsPHNWCP; Tue, 17 Apr 2018 08:12:55 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6872D1200C5; Tue, 17 Apr 2018 08:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3172; q=dns/txt; s=iport; t=1523977972; x=1525187572; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=OxGXgxxlXR7k5wtH9q/8or2yz5m2spqnml1puGAiMPc=; b=m59RC9X8/4LJbC8NYVuk+4JvL6dTSXfdP8p3SYJ2R+cP+FWDlLui9dR/ szltpS/ivbGrjFdS6bTUOZ4cyvPLMQaPLrhGsiUR1ESkyKLpUgkGfLQGN 3RXppgZui9XhZrvql21KztLKt8AJ70gP3DJ3ghnciUKMPOvEphEXEFLqp Q=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,464,1517875200"; d="asc'?scan'208"; a="3240269"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 15:12:49 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3HFCnlC021466; Tue, 17 Apr 2018 15:12:49 GMT
To: Ignas Bagdonas , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152397412726.11591.16253547587352358712.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: 
Date: Tue, 17 Apr 2018 17:12:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152397412726.11591.16253547587352358712.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1KnbrDekNtFYZMvPNKiNdMbGWMlQocfTl"
Archived-At: 
Subject: Re: [OPSAWG] Ignas Bagdonas' No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 15:12:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1KnbrDekNtFYZMvPNKiNdMbGWMlQocfTl
Content-Type: multipart/mixed; boundary="SQN7y6lSAEaoNPF8S9g4rHZbbw5xDTE5E";
 protected-headers="v1"
From: Eliot Lear 
To: Ignas Bagdonas , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: 
Subject: Re: Ignas Bagdonas' No Objection on draft-ietf-opsawg-mud-20: (with
 COMMENT)
References: <152397412726.11591.16253547587352358712.idtracker@ietfa.amsl.com>
In-Reply-To: <152397412726.11591.16253547587352358712.idtracker@ietfa.amsl.com>

--SQN7y6lSAEaoNPF8S9g4rHZbbw5xDTE5E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Ignas,


On 17.04.18 16:08, Ignas Bagdonas wrote:
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-opsawg-mud-20: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> S2.1: Valid MUD file will contain "mud" and "acls" containers - what if=
 it does
> not, especially if it does not contain an ACL container - how will the
> connectivity requirement be interpreted then?

I proposed the following to EKR to clarify:
>
> A valid MUD file MUST contain a "mud" container and MAY contain an
> optional access-lists container that will be present whenever access
> controls are to be requested.

>
> A few nits:
>
> s/MUR-URL/MUD-URL
>
> s/yang/YANG in the document and module description fields.
>
> s/dns/DNS in the modules.
>
> S1, MUD building blocks section: "A URL that is can be used"
>
>

All corrected, thanks!

Eliot




--SQN7y6lSAEaoNPF8S9g4rHZbbw5xDTE5E--

--1KnbrDekNtFYZMvPNKiNdMbGWMlQocfTl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrWDvAACgkQh7ZrRtnS
ejPmJAgAuUhNDADK7kQFdU+4WCrGgH581DK2ndWDWU0fb01Oh25UMVm/rEy6++kx
KDwGGI96Ols0BqsuRQAI2vRZjzGf68fPzBBaGUO+nWis+gaSaIGXY5yQcHBdWAf6
sQx/8ziNyyVyXfvqnb1bZ9oPsKNz1rvtRy3ChTnHKJfpWykJ7DbMickZNaueVVNS
ESd2IMrU4OP8cct1OKSTrWi5buHPqz1vSOvOHqKAJ8t6UnLFm0HYshFI8ScAPPYa
5Xa+yWxVrOoREddlvtT9LBCnBK/4kWrs4yWnn3QqDvxN8jHts6TBsYJSXnWyhIcc
5yq5qnKrH3t0sGfcuYLVQMdhYh/73g==
=zjC5
-----END PGP SIGNATURE-----

--1KnbrDekNtFYZMvPNKiNdMbGWMlQocfTl--


From nobody Tue Apr 17 08:31:02 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FB312DA02; Tue, 17 Apr 2018 08:31:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152397906070.11507.221821272669427536.idtracker@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 08:31:00 -0700
Archived-At: 
Subject: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 15:31:01 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hopefully this will be an easy DISCUSS to clear.

Partially guided by some of the discussion that has already happened, it seems
like there are three places where authentication/identity validation occurs in
the MUD flow: the (CMS) signature alongside the MUD file, the TLS connection
used to retrieve the MUD file, and the binding between the MUD URL and the
device itself.  The last one seems pretty important, especially given some of
the points in Ekr's DISCUSS about limiting damage in case of
compromised/malicious device.  The security considerations already give some
coverage in the first paragraph, but basically limited to the "manufacturer"
groupings, and only covers the usage of the certificate extension for binding a
MUD URL to a specific device.  There's also some related text when considering
what to do if the MUD URL for a given MAC address changes, but I didn't see any
coverage for the general case.  The entity using the MUD contents needs to be
aware of the provenance of the URL and the risks of using a "spoofed" MUD from
an attacker.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's pretty exciting to have the prospect of getting this kind of information
out there in a standard, machine-readable format.  That said ... there's been a
decent amount of talk of "still getting feet wet", "need to get experience how
this unfolds", etc., so I have to ask: are we confident that this is better as
Proposed Standard than Experimental?

Adding the ability to use DNS names in ACL 'match' patterns should probably be
accompanied by some note about the (lack of) veracity of DNS information.  This
is not a DISCUSS since the DNS name is expected to be what the Thing actually
attempts to use, and the DNS resolver used by the Thing is likely to be the
same one as used by the network, so in that sense the ACL will still "work as
intended" even in the face of spoofed DNS.  But we can probably mention that
it's still a risk.

I echo Ekr's question about CMS vs. JWS.

Please consider using the BCP 14/RFC8174 boilerplate.

Other comments (in document order, sorry about the interspersed nits).

Section 1

   o  Substantially reduce the threat surface on a device entering a
      network to those communications intended by the manufacturer.

Comma after 'network'?

Section 1.5

      [...] The DHCP server may take further actions,
      such as retrieve the URL or otherwise pass it along to network
      management system or controller.

Retrieve the resource from the URL?

Section 1.7

   my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits.

I'm probably just being dumb, but I am failing to parse what this
means.

Section 1.8

   The information returned by the MUD file server (a web server) is
   valid for the duration of the Thing's connection, or as specified in
   the description.  Thus if the Thing is disconnected, any associated
   configuration in the switch can be removed.  Similarly, from time to
   time the description may be refreshed, based on new capabilities or
   communication patterns or vulnerabilities.

This feels slightly internally inconsistent about valid/refreshed.

Section 12.2

"Prior to retrieving a MUD file [...] validating the signature
across the MUD file" is internally inconsistent.  Perhaps the first
pargaraph is stale, since the second paragraph basically duplicates
it?

Also,
   [...] For another, what is more important
   is the accountability of the recommendation, and not the
   cryptographic relationship between the device and the file.
seems not really true.

   An example:

   % openssl cms -verify -in mudfile.p7s -inform DER -content
   % mudfile

   Note the additional step of verifying the common trust root.

The additional step that's not included in the example?  Maybe it
could be included?

Section 15

Lots of tiny comments, so I'll quote and put inline.

% Based on how a MUD URL is emitted, a Thing may be able to lie about

s/emitted/conveyed to the network/?

% what it is, thus gaining additional network access.  There are

s/thus/potentially/
And maybe clarify ", based on the (false) MUD that is claimed"?

% several means to limit risk in this case.  The most obvious is to
% only believe Things that make use of certificate-based authentication
% such as IEEE 802.1AR certificates.  When those certificates are not
% present, Things claiming to be of a certain manufacturer SHOULD NOT
% be included in that manufacturer grouping without additional
% validation of some form.  This will occur when it makes use of

"occur" sounds more like it refers to the validation than the
"claiming to be of a certain manufacturer"; maybe "be relevant"?

% primitives such as "manufacturer" for the purpose of accessing Things
% of a particular type.  Similarly, network management systems may be
% able to fingerprint the Thing.  In such cases, the MUD URL can act as
% a classifier that can be proven or disproven.  Fingerprinting may
% have other advantages as well: when 802.1AR certificates are used,
% because they themselves cannot change, fingerprinting offers the
% opportunity to add artificats to the MUD URL.  The meaning of such

typo                 ^^^^^^^^^^
This is the "reserved" field in the MUD URL?  Maybe best to say so
explicitly.

% artifacts is left as future work.
%
% Network management systems SHOULD NOT accept a usage description for
% a Thing with the same MAC address that has indicated a change of
% authority without some additional validation (such as review by a
% network administrator).  New Things that present some form of

This sentence could probably be tightened up.

% unauthenticated MUD URL SHOULD be validated by some external means
% when they would be otherwise be given increased network access.

I'd suggest replacing "otherwise" with a more concrete condition.

% It may be possible for a rogue manufacturer to inappropriately
% exercise the MUD file parser, in order to exploit a vulnerability.
% There are three recommended approaches to address this threat.  The
% first is to validate the signature of the MUD file.  The second is to

How does this help -- can't a rogue manufacturer sign whatever
malformed blob it wants?

% have a system do a primary scan of the file to ensure that it is both
% parseable and believable at some level.  MUD files will likely be
% relatively small, to start with.  The number of ACEs used by any
% given Thing should be relatively small as well.  It may also be
% useful to limit retrieval of MUD URLs to only those sites that are
% known to have decent web or domain reputations.
%
[...]
%
% The release of a MUD URL by a Thing reveals what the Thing is, and
% provides an attacker with guidance on what vulnerabilities may be
% present.

It also seems to be permitted for the manufacturer to give Things
unique MUD URLs and perform (e.g., location) tracking based on
accesses to that URL...

% While the MUD URL itself is not intended to be unique to a specific
% Thing, the release of the URL may aid an observer in identifying
% individuals when combined with other information.  This is a privacy
% consideration.

...even though you disclaim that intent.  I suspect that any
normative guidance on making MUD URLs non-identifying would not
really be enforcable, but it may be worth mentioning this
consideration earlier in the document (e.g., in Sections 5 and 10).
Also, it's not necessarily just the "release" of the MUD URL, but
the actual accesses by the MUD controller, that give the MUD URL's
origin server real data about where the device being tracked is
located/used.

% In addressing both of these concerns, implementors should take into
% account what other information they are advertising through
% mechanisms such as mDNS[RFC6872], how a Thing might otherwise be
% identified, perhaps through how it behaves when it is connected to
% the network, whether a Thing is intended to be used by individuals or
% carry personal identifying information, and then apply appropriate
% data minimization techniques.  One approach is to make use of TEAP
% [RFC7170] as the means to share information with authorized
% components in the network.  Network elements may also assist in
% limiting access to the MUD URL through the use of mechanisms such as
% DHCPv6-Shield [RFC7610].
[...]

Appendix C

   In this sample extension we augment the core MUD model to indicate
   whether the device implements DETNET.  If a device later attempts to
   make use of DETNET, an notification or exception might be generated.

Presumably this should say that if a device *claims to not use
DETNET* but then later does?



From nobody Tue Apr 17 08:49:19 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C478C124319; Tue, 17 Apr 2018 08:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 KYTwI_OxkMcG; Tue, 17 Apr 2018 08:49:00 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7716C1200FC; Tue, 17 Apr 2018 08:49:00 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 0887D3A6DC; Tue, 17 Apr 2018 15:49:00 +0000 (UTC)
Date: Tue, 17 Apr 2018 15:49:00 +0000
From: heasley 
To: li zhenqiang , "rtg-dir@ietf.org" , "gen-art@ietf.org" , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" ,  "ietf@ietf.org" , opsawg 
Message-ID: <20180417154859.GA59765@shrubbery.net>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>  <20180416232930.GB47095@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180416232930.GB47095@shrubbery.net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 15:49:03 -0000

Why is there IPR on this draft?  Is this because of section 3?  A section
that is unnecessary and could be entirely removed without affecting the
draft in any manner?

Otherwise, I think it absolutely absurd that there is IPR on this document.


From nobody Tue Apr 17 10:54:22 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8D512783A; Tue, 17 Apr 2018 10:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.709
X-Spam-Level: 
X-Spam-Status: No, score=-12.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, TVD_PH_BODY_META_ALL=1.8, T_DKIMWL_WL_MED=-0.01, 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
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 7NDK5HgqJY9s; Tue, 17 Apr 2018 10:54:13 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4AD1270FC; Tue, 17 Apr 2018 10:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39091; q=dns/txt; s=iport; t=1523987652; x=1525197252; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=MQvCL3ZvAXCi4A6PHpq/tV9ZJ5lh5mApQk9RMS9C6yg=; b=nIjKizy8YkuXBIPjT0tPHYQ8OkfYQlQIyATx2c0vkiOEiFikLPDB+OkI w6AV43yDwH8Yeh/CGPy6Oez+QTv8gVkQDa5B0PGv+uEbyA+Y73D/nZqLm /JoY6KyNrYHfV2V0/83pHGJRAuzrdz5GieOFnUVrraH0UDsuVzp0qESz/ 0=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.48,464,1517875200";  d="asc'?scan'208,217";a="3196076"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 17:54:10 +0000
Received: from [10.61.91.30] (ams3-vpn-dhcp6943.cisco.com [10.61.91.30]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3HHs93x004310; Tue, 17 Apr 2018 17:54:09 GMT
To: Benjamin Kaduk , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org, EKR 
References: <152397906070.11507.221821272669427536.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <8f6ae301-07c6-2dbb-35dc-22c514eab6c6@cisco.com>
Date: Tue, 17 Apr 2018 19:54:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152397906070.11507.221821272669427536.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MbVw7qrYy0ZAZ2EzKpePeg6CB91xXFmqw"
Archived-At: 
Subject: Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 17:54:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MbVw7qrYy0ZAZ2EzKpePeg6CB91xXFmqw
Content-Type: multipart/mixed; boundary="4ew7u3k52iPbj1yMn4RMzuOHgBybemzTJ";
 protected-headers="v1"
From: Eliot Lear 
To: Benjamin Kaduk , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org, EKR 
Message-ID: <8f6ae301-07c6-2dbb-35dc-22c514eab6c6@cisco.com>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with
 DISCUSS and COMMENT)
References: <152397906070.11507.221821272669427536.idtracker@ietfa.amsl.com>
In-Reply-To: <152397906070.11507.221821272669427536.idtracker@ietfa.amsl.com>

--4ew7u3k52iPbj1yMn4RMzuOHgBybemzTJ
Content-Type: multipart/alternative;
 boundary="------------5F8DB66B0B8B6E232BD189B2"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------5F8DB66B0B8B6E232BD189B2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ben,

Maybe we can swat two birds with one stone here, so to speak.=C2=A0 I thi=
nk
both EKR and I have been ruminating on the right text, and hopefully
between the three of us, and perhaps others from the community we can
zero in on what is needed.=C2=A0=C2=A0


On 17.04.18 17:31, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Hopefully this will be an easy DISCUSS to clear.
>
> Partially guided by some of the discussion that has already happened, i=
t seems
> like there are three places where authentication/identity validation oc=
curs in
> the MUD flow: the (CMS) signature alongside the MUD file, the TLS conne=
ction
> used to retrieve the MUD file, and the binding between the MUD URL and =
the
> device itself.  The last one seems pretty important, especially given s=
ome of
> the points in Ekr's DISCUSS about limiting damage in case of
> compromised/malicious device.  The security considerations already give=
 some
> coverage in the first paragraph, but basically limited to the "manufact=
urer"
> groupings, and only covers the usage of the certificate extension for b=
inding a
> MUD URL to a specific device.  There's also some related text when cons=
idering
> what to do if the MUD URL for a given MAC address changes, but I didn't=
 see any
> coverage for the general case.  The entity using the MUD contents needs=
 to be
> aware of the provenance of the URL and the risks of using a "spoofed" M=
UD from
> an attacker.

I think EKR's last statement jibes well with what you are saying.=C2=A0 I=

propose an amended first paragraph of the security considerations
section, to address that last point as follows:
> Devices emitting MUD URLs that are not signed by someone else may lie,
> potentially gaining additional network access by pretending to be
> something it is not.=C2=A0 In these cases, while we describe some
> mitigations below, a risk of lying remains in some circumstances,
> particularly when a device may masquerade as another device that has
> already been approved to be on the network, but it isn't currently
> connected.=C2=A0 There are two overarching mitigations for this case:
>
> =C2=A0* Best mitigation: devices should migrate to the use of=C2=A0 802=
=2E1AR
> certificate.
> =C2=A0* 2nd best mitigation: do not grant such devices access to critic=
al
> =C2=A0=C2=A0 resources, recognizing that attackers may be masquerading =
as
> =C2=A0=C2=A0 them.
>
> In addition, even those=C2=A0=C2=A0 =C2=A0devices=C2=A0=C2=A0 =C2=A0tha=
t do=C2=A0=C2=A0 =C2=A0have manufacturer
> certificates
> may be attackers.=C2=A0 MUD managers=C2=A0=C2=A0 =C2=A0that do=C2=A0=C2=
=A0 =C2=A0not recognize a=C2=A0=C2=A0
> =C2=A0signer MUST
> seek approval of the administrator prior to further processing.
>
> Additional mitigations are described below.
>
> When certificates are not present, Things claiming to be of a certain
> manufacturer SHOULD NOT be included in that manufacturer grouping
> without additional validation of some form.=C2=A0

--

The LLDP and DHCP options are not nothing.=C2=A0 In the context of a
physically secure environment they can go a long way and at least deter
if not stop a fair amount of nonsense.=C2=A0 But they are by no means per=
fect.

With this having been said, I hope you would both be comfortable with
the above text, or perhaps with some additional suggestions.


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> It's pretty exciting to have the prospect of getting this kind of infor=
mation
> out there in a standard, machine-readable format.  That said ... there'=
s been a
> decent amount of talk of "still getting feet wet", "need to get experie=
nce how
> this unfolds", etc., so I have to ask: are we confident that this is be=
tter as
> Proposed Standard than Experimental?

There's good reason to get to proposed.=C2=A0 We will never get enough
manufacturers to get the operational experience we need to get to the
next stage if it is not.=C2=A0 Vendors in this arena simply don't move on=

experimental work.

> Adding the ability to use DNS names in ACL 'match' patterns should prob=
ably be
> accompanied by some note about the (lack of) veracity of DNS informatio=
n.  This
> is not a DISCUSS since the DNS name is expected to be what the Thing ac=
tually
> attempts to use, and the DNS resolver used by the Thing is likely to be=
 the
> same one as used by the network, so in that sense the ACL will still "w=
ork as
> intended" even in the face of spoofed DNS.  But we can probably mention=
 that
> it's still a risk.
>
> I echo Ekr's question about CMS vs. JWS.

Please see my response in that context.

>
> Please consider using the BCP 14/RFC8174 boilerplate.

I propose to make that change.

>
> Other comments (in document order, sorry about the interspersed nits).
>
> Section 1
>
>    o  Substantially reduce the threat surface on a device entering a
>       network to those communications intended by the manufacturer.
>
> Comma after 'network'?

I propose to trim this to:

=C2=A0* Substantially reduce the threat surface on a device to those
=C2=A0=C2=A0 communications intended by the manufacturer.

> Section 1.5
>
>       [...] The DHCP server may take further actions,
>       such as retrieve the URL or otherwise pass it along to network
>       management system or controller.
>
> Retrieve the resource from the URL?

I propose the following:

> The DHCP server may take further actions, such as
> =C2=A0=C2=A0 act as the MUD manager or otherwise pass it along to the M=
UD manager.

>
> Section 1.7
>
>    my-controller:  Devices associated with the MUD URL of a device that=

>       the administrator admits.
>
> I'm probably just being dumb, but I am failing to parse what this
> means.

Would the following be clearer?

> Devices intended to serve as controllers for the MUD-URL that=C2=A0=C2=A0=
 =C2=A0the
> thing emitted.

>
> Section 1.8
>
>    The information returned by the MUD file server (a web server) is
>    valid for the duration of the Thing's connection, or as specified in=

>    the description.  Thus if the Thing is disconnected, any associated
>    configuration in the switch can be removed.  Similarly, from time to=

>    time the description may be refreshed, based on new capabilities or
>    communication patterns or vulnerabilities.
>
> This feels slightly internally inconsistent about valid/refreshed.

There are two concepts at play here:

  * When the device goes away or is unplugged
  * When the MUD file itself has been updated.

We am attempting to capture both.=C2=A0 Apparently badly.

How about the following:

> The information returned by the MUD file server is valid for as long
> as the Thing is connected.=C2=A0 There is no expiry.=C2=A0 However, if =
the MUD
> manager has detected that the MUD file for a Thing has changed, it
> SHOULD update the policy expeditiously, taking into account whatever
> approval flow is required in a deployment.=C2=A0 In this way, new
> recommendations from the manufacturer can be processed in a timely
> fashion.


>
> Section 12.2
>
> "Prior to retrieving a MUD file [...] validating the signature
> across the MUD file" is internally inconsistent.  Perhaps the first
> pargaraph is stale, since the second paragraph basically duplicates
> it?

Totally.=C2=A0 I propose to remove the SHOULD and leave the MUST, as foll=
ows:
> Prior to retrieving a MUD file the MUD manager MUST retrieve the MUD
> signature file by retrieving the value of "mud-signature" and
> validating the signature across the MUD file.=C2=A0 A MUD manager MUST
> cease processing of that file it cannot validate the chain of trust to
> a known trust anchor until an administrator has given approval.


>
> Also,
>    [...] For another, what is more important
>    is the accountability of the recommendation, and not the
>    cryptographic relationship between the device and the file.
> seems not really true.
>
>    An example:
>
>    % openssl cms -verify -in mudfile.p7s -inform DER -content
>    % mudfile
>
>    Note the additional step of verifying the common trust root.
>
> The additional step that's not included in the example?  Maybe it
> could be included?

That essentially means installing a trust anchor for this purpose.=C2=A0 =
Let
me see what I can do.


>
> Section 15
>
> Lots of tiny comments, so I'll quote and put inline.
>
> % Based on how a MUD URL is emitted, a Thing may be able to lie about
>
> s/emitted/conveyed to the network/?

I believe this text is about to change.
>
> % what it is, thus gaining additional network access.  There are
>
> s/thus/potentially/
> And maybe clarify ", based on the (false) MUD that is claimed"?

Assuming this text remains...=C2=A0 edited as follows:
> =C2=A0Thing may be able
> to lie about what it is, potentially gaining additional network access
> by pretending to be something it is not.


>
> % several means to limit risk in this case.  The most obvious is to
> % only believe Things that make use of certificate-based authentication=

> % such as IEEE 802.1AR certificates.  When those certificates are not
> % present, Things claiming to be of a certain manufacturer SHOULD NOT
> % be included in that manufacturer grouping without additional
> % validation of some form.  This will occur when it makes use of
>
> "occur" sounds more like it refers to the validation than the
> "claiming to be of a certain manufacturer"; maybe "be relevant"?

ok.
>
> % primitives such as "manufacturer" for the purpose of accessing Things=

> % of a particular type.  Similarly, network management systems may be
> % able to fingerprint the Thing.  In such cases, the MUD URL can act as=

> % a classifier that can be proven or disproven.  Fingerprinting may
> % have other advantages as well: when 802.1AR certificates are used,
> % because they themselves cannot change, fingerprinting offers the
> % opportunity to add artificats to the MUD URL.  The meaning of such
>
> typo                 ^^^^^^^^^^
> This is the "reserved" field in the MUD URL?  Maybe best to say so
> explicitly.

ok: propose

> =C2=A0Fingerprinting may have
> other advantages as well: when 802.1AR certificates are used, because
> they themselves cannot change, fingerprinting offers the opportunity
> to add artifacts to the MUD URL in the form of the reserved field
> discussed in {{dhcpopt}}.

>
> % artifacts is left as future work.
> %
> % Network management systems SHOULD NOT accept a usage description for
> % a Thing with the same MAC address that has indicated a change of
> % authority without some additional validation (such as review by a
> % network administrator).  New Things that present some form of
>
> This sentence could probably be tightened up.

Will try with small edits.

>
> % unauthenticated MUD URL SHOULD be validated by some external means
> % when they would be otherwise be given increased network access.
>
> I'd suggest replacing "otherwise" with a more concrete condition.

I think the best way to deal with this is to delete "otherwise".

>
> % It may be possible for a rogue manufacturer to inappropriately
> % exercise the MUD file parser, in order to exploit a vulnerability.
> % There are three recommended approaches to address this threat.  The
> % first is to validate the signature of the MUD file.  The second is to=

>
> How does this help -- can't a rogue manufacturer sign whatever
> malformed blob it wants?

Let's restate that:

The first is to validate that the signer of the MUD file is known to and
trusted by the MUD manager.

>
> % have a system do a primary scan of the file to ensure that it is both=

> % parseable and believable at some level.  MUD files will likely be
> % relatively small, to start with.  The number of ACEs used by any
> % given Thing should be relatively small as well.  It may also be
> % useful to limit retrieval of MUD URLs to only those sites that are
> % known to have decent web or domain reputations.
> %
> [...]
> %
> % The release of a MUD URL by a Thing reveals what the Thing is, and
> % provides an attacker with guidance on what vulnerabilities may be
> % present.
>
> It also seems to be permitted for the manufacturer to give Things
> unique MUD URLs and perform (e.g., location) tracking based on
> accesses to that URL...

It's not the best method.=C2=A0 For one thing, the MUD manager may be now=
here
near where the device is.=C2=A0 For another, if the device can communicat=
e
with the manufacturer at all, it can directly convey that information
without going through MUD.=C2=A0 But it might be possible.=C2=A0 It can a=
lso be
remediated, as it happens.=C2=A0 See below.
>
> % While the MUD URL itself is not intended to be unique to a specific
> % Thing, the release of the URL may aid an observer in identifying
> % individuals when combined with other information.  This is a privacy
> % consideration.
>
> ...even though you disclaim that intent.  I suspect that any
> normative guidance on making MUD URLs non-identifying would not
> really be enforcable, but it may be worth mentioning this
> consideration earlier in the document (e.g., in Sections 5 and 10).
> Also, it's not necessarily just the "release" of the MUD URL, but
> the actual accesses by the MUD controller, that give the MUD URL's
> origin server real data about where the device being tracked is
> located/used.

I propose to (a) list this risk and (b) propose the following
remediations to address this sort of release:

There is the risk of the MUD manager itself being spied
on to determine what things are connected=C2=A0=C2=A0=C2=A0 to the networ=
k.=C2=A0 To address
this risk, MUD managers=C2=A0=C2=A0=C2=A0 may choose to make use of TLS p=
roxies that
they trust that would aggregate other information.

>
> % In addressing both of these concerns, implementors should take into
> % account what other information they are advertising through
> % mechanisms such as mDNS[RFC6872], how a Thing might otherwise be
> % identified, perhaps through how it behaves when it is connected to
> % the network, whether a Thing is intended to be used by individuals or=

> % carry personal identifying information, and then apply appropriate
> % data minimization techniques.  One approach is to make use of TEAP
> % [RFC7170] as the means to share information with authorized
> % components in the network.  Network elements may also assist in
> % limiting access to the MUD URL through the use of mechanisms such as
> % DHCPv6-Shield [RFC7610].
> [...]
>
> Appendix C
>
>    In this sample extension we augment the core MUD model to indicate
>    whether the device implements DETNET.  If a device later attempts to=

>    make use of DETNET, an notification or exception might be generated.=

>
> Presumably this should say that if a device *claims to not use
> DETNET* but then later does?
>
>
>
Righto.

Thanks!

Eliot

--------------5F8DB66B0B8B6E232BD189B2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Ben,

    
Maybe we can swat two birds with one stone here, so to speak.=C2=A0=
 I
      think both EKR and I have been ruminating on the right text, and
      hopefully between the three of us, and perhaps others from the
      community we can zero in on what is needed.=C2=A0=C2=A0 

    

    

    
On 17.04.18 17:31, Benjamin Kaduk
      wrote:

    

    

      
Benjamin Kaduk has entered the following ballot posi=
tion for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/st=
atement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-mud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hopefully this will be an easy DISCUSS to clear.

Partially guided by some of the discussion that has already happened, it =
seems
like there are three places where authentication/identity validation occu=
rs in
the MUD flow: the (CMS) signature alongside the MUD file, the TLS connect=
ion
used to retrieve the MUD file, and the binding between the MUD URL and th=
e
device itself.  The last one seems pretty important, especially given som=
e of
the points in Ekr's DISCUSS about limiting damage in case of
compromised/malicious device.  The security considerations already give s=
ome
coverage in the first paragraph, but basically limited to the "manufactur=
er"
groupings, and only covers the usage of the certificate extension for bin=
ding a
MUD URL to a specific device.  There's also some related text when consid=
ering
what to do if the MUD URL for a given MAC address changes, but I didn't s=
ee any
coverage for the general case.  The entity using the MUD contents needs t=
o be
aware of the provenance of the URL and the risks of using a "spoofed" MUD=
 from
an attacker.

    

    

    I think EKR's last statement jibes well with what you are saying.=C2=A0=
 I
    propose an amended first paragraph of the security considerations
    section, to address that last point as follows:

    
Devices emitting MUD URLs that are not
      signed by someone else may lie,

      potentially gaining additional network access by pretending to be
      something it is not.=C2=A0 In these cases, while we describe some
      mitigations below, a risk of lying remains in some circumstances,
      particularly when a device may masquerade as another device that
      has

      already been approved to be on the network, but it isn't currently<=
br>
      connected.=C2=A0 There are two overarching mitigations for this cas=
e:

      

      =C2=A0* Best mitigation: devices should migrate to the use of=C2=A0=
 802.1AR
      certificate.

      =C2=A0* 2nd best mitigation: do not grant such devices access to
      critical

      =C2=A0=C2=A0 resources, recognizing that attackers may be masquerad=
ing as

      =C2=A0=C2=A0 them.

      

      In addition, even those=C2=A0=C2=A0 =C2=A0devices=C2=A0=C2=A0 =C2=A0=
that do=C2=A0=C2=A0 =C2=A0have manufacturer
      certificates

      may be attackers.=C2=A0 MUD managers=C2=A0=C2=A0 =C2=A0that do=C2=A0=
=C2=A0 =C2=A0not recognize a=C2=A0=C2=A0
      =C2=A0signer MUST

      seek approval of the administrator prior to further processing.
=

      

      Additional mitigations are described below.

      

      When certificates are not present, Things claiming to be of a
      certain

      manufacturer SHOULD NOT be included in that manufacturer grouping
      without additional validation of some form.=C2=A0

    

    
--

    
The LLDP and DHCP options are not nothing.=C2=A0 In the context of=
 a
      physically secure environment they can go a long way and at least
      deter if not stop a fair amount of nonsense.=C2=A0 But they are by =
no
      means perfect. 

    

    
With this having been said, I hope you would both be comfortable
      with the above text, or perhaps with some additional suggestions.
    


    

    

      


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's pretty exciting to have the prospect of getting this kind of informa=
tion
out there in a standard, machine-readable format.  That said ... there's =
been a
decent amount of talk of "still getting feet wet", "need to get experienc=
e how
this unfolds", etc., so I have to ask: are we confident that this is bett=
er as
Proposed Standard than Experimental?


    

    

    There's good reason to get to proposed.=C2=A0 We will never get enoug=
h
    manufacturers to get the operational experience we need to get to
    the next stage if it is not.=C2=A0 Vendors in this arena simply don't=

    move on experimental work.

    

    

      
Adding the ability to use DNS names in ACL 'match' patterns should probab=
ly be
accompanied by some note about the (lack of) veracity of DNS information.=
  This
is not a DISCUSS since the DNS name is expected to be what the Thing actu=
ally
attempts to use, and the DNS resolver used by the Thing is likely to be t=
he
same one as used by the network, so in that sense the ACL will still "wor=
k as
intended" even in the face of spoofed DNS.  But we can probably mention t=
hat
it's still a risk.

I echo Ekr's question about CMS vs. JWS.

    

    

    Please see my response in that context.

    

    

      

Please consider using the BCP 14/RFC8174 boilerplate.

    

    

    I propose to make that change.

    

    

      

Other comments (in document order, sorry about the interspersed nits).

Section 1

   o  Substantially reduce the threat surface on a device entering a
      network to those communications intended by the manufacturer.

Comma after 'network'?


    

    

    I propose to trim this to:

    

    =C2=A0* Substantially reduce the threat surface on a device to those<=
br>
    =C2=A0=C2=A0 communications intended by the manufacturer.

    

    

      
Section 1.5

      [...] The DHCP server may take further actions,
      such as retrieve the URL or otherwise pass it along to network
      management system or controller.

Retrieve the resource from the URL?

    

    

    I propose the following:

    

    
The DHCP server may take further actions,
      such as

      =C2=A0=C2=A0 act as the MUD manager or otherwise pass it along to t=
he MUD
      manager.

    

    

      

Section 1.7

   my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits.

I'm probably just being dumb, but I am failing to parse what this
means.

    

    

    Would the following be clearer?

    

    
Devices intended to serve as controllers fo=
r
      the MUD-URL that=C2=A0=C2=A0 =C2=A0the thing emitted.

    

    

      

Section 1.8

   The information returned by the MUD file server (a web server) is
   valid for the duration of the Thing's connection, or as specified in
   the description.  Thus if the Thing is disconnected, any associated
   configuration in the switch can be removed.  Similarly, from time to
   time the description may be refreshed, based on new capabilities or
   communication patterns or vulnerabilities.

This feels slightly internally inconsistent about valid/refreshed.

    

    

    There are two concepts at play here:

    
    
      
  • When the device goes away or is unplugged
    • 
      
  • When the MUD file itself has been updated.
    • 
    

    
We am attempting to capture both.=C2=A0 Apparently badly.

    
How about the following:

    

      
The information returned by the MUD file
        server is valid for as long

        as the Thing is connected.=C2=A0 There is no expiry.=C2=A0 Howeve=
r, if the
        MUD

        manager has detected that the MUD file for a Thing has changed,
        it

        SHOULD update the policy expeditiously, taking into account
        whatever

        approval flow is required in a deployment.=C2=A0 In this way, new=


        recommendations from the manufacturer can be processed in a
        timely

        fashion.

      

    

    


    

    

      

Section 12.2

"Prior to retrieving a MUD file [...] validating the signature
across the MUD file" is internally inconsistent.  Perhaps the first
pargaraph is stale, since the second paragraph basically duplicates
it?

    

    

    Totally.=C2=A0 I propose to remove the SHOULD and leave the MUST, as
    follows:

    
Prior to retrieving a MUD file the MUD
      manager MUST retrieve the MUD

      signature file by retrieving the value of "mud-signature" and

      validating the signature across the MUD file.=C2=A0 A MUD manager M=
UST

      cease processing of that file it cannot validate the chain of
      trust to

      a known trust anchor until an administrator has given approval.
    

    

    

      

Also,
   [...] For another, what is more important
   is the accountability of the recommendation, and not the
   cryptographic relationship between the device and the file.
seems not really true.

   An example:

   % openssl cms -verify -in mudfile.p7s -inform DER -content
   % mudfile

   Note the additional step of verifying the common trust root.

The additional step that's not included in the example?  Maybe it
could be included?

    

    

    That essentially means installing a trust anchor for this purpose.=C2=
=A0
    Let me see what I can do.

    

    

    

      

Section 15

Lots of tiny comments, so I'll quote and put inline.

% Based on how a MUD URL is emitted, a Thing may be able to lie about

s/emitted/conveyed to the network/?

    

    

    I believe this text is about to change.

    

      

% what it is, thus gaining additional network access.  There are

s/thus/potentially/
And maybe clarify ", based on the (false) MUD that is claimed"?

    

    

    Assuming this text remains...=C2=A0 edited as follows:

    
=C2=A0Thing may be able

      to lie about what it is, potentially gaining additional network
      access

      by pretending to be something it is not.

    

    

    

      

% several means to limit risk in this case.  The most obvious is to
% only believe Things that make use of certificate-based authentication
% such as IEEE 802.1AR certificates.  When those certificates are not
% present, Things claiming to be of a certain manufacturer SHOULD NOT
% be included in that manufacturer grouping without additional
% validation of some form.  This will occur when it makes use of

"occur" sounds more like it refers to the validation than the
"claiming to be of a certain manufacturer"; maybe "be relevant"?

    

    

    ok.

    

      

% primitives such as "manufacturer" for the purpose of accessing Things
% of a particular type.  Similarly, network management systems may be
% able to fingerprint the Thing.  In such cases, the MUD URL can act as
% a classifier that can be proven or disproven.  Fingerprinting may
% have other advantages as well: when 802.1AR certificates are used,
% because they themselves cannot change, fingerprinting offers the
% opportunity to add artificats to the MUD URL.  The meaning of such

typo                 ^^^^^^^^^^
This is the "reserved" field in the MUD URL?  Maybe best to say so
explicitly.

    

    

    ok: propose

    

    
=C2=A0Fingerprinting may have

      other advantages as well: when 802.1AR certificates are used,
      because

      they themselves cannot change, fingerprinting offers the
      opportunity

      to add artifacts to the MUD URL in the form of the reserved field
      discussed in {{dhcpopt}}.

    

    

      

% artifacts is left as future work.
%
% Network management systems SHOULD NOT accept a usage description for
% a Thing with the same MAC address that has indicated a change of
% authority without some additional validation (such as review by a
% network administrator).  New Things that present some form of

This sentence could probably be tightened up.

    

    

    Will try with small edits.

    

    

      

% unauthenticated MUD URL SHOULD be validated by some external means
% when they would be otherwise be given increased network access.

I'd suggest replacing "otherwise" with a more concrete condition.

    

    

    I think the best way to deal with this is to delete "otherwise".

    

    

      

% It may be possible for a rogue manufacturer to inappropriately
% exercise the MUD file parser, in order to exploit a vulnerability.
% There are three recommended approaches to address this threat.  The
% first is to validate the signature of the MUD file.  The second is to

How does this help -- can't a rogue manufacturer sign whatever
malformed blob it wants?

    

    

    Let's restate that:

    

    The first is to validate that the signer of the MUD file is known to
    and trusted by the MUD manager.

    

    

      

% have a system do a primary scan of the file to ensure that it is both
% parseable and believable at some level.  MUD files will likely be
% relatively small, to start with.  The number of ACEs used by any
% given Thing should be relatively small as well.  It may also be
% useful to limit retrieval of MUD URLs to only those sites that are
% known to have decent web or domain reputations.
%
[...]
%
% The release of a MUD URL by a Thing reveals what the Thing is, and
% provides an attacker with guidance on what vulnerabilities may be
% present.

It also seems to be permitted for the manufacturer to give Things
unique MUD URLs and perform (e.g., location) tracking based on
accesses to that URL...

    

    

    It's not the best method.=C2=A0 For one thing, the MUD manager may be=

    nowhere near where the device is.=C2=A0 For another, if the device ca=
n
    communicate with the manufacturer at all, it can directly convey
    that information without going through MUD.=C2=A0 But it might be
    possible.=C2=A0 It can also be remediated, as it happens.=C2=A0 See b=
elow.

    

      

% While the MUD URL itself is not intended to be unique to a specific
% Thing, the release of the URL may aid an observer in identifying
% individuals when combined with other information.  This is a privacy
% consideration.

=2E..even though you disclaim that intent.  I suspect that any
normative guidance on making MUD URLs non-identifying would not
really be enforcable, but it may be worth mentioning this
consideration earlier in the document (e.g., in Sections 5 and 10).
Also, it's not necessarily just the "release" of the MUD URL, but
the actual accesses by the MUD controller, that give the MUD URL's
origin server real data about where the device being tracked is
located/used.

    

    

    I propose to (a) list this risk and (b) propose the following
    remediations to address this sort of release:

    

    There is the risk of the MUD manager itself being spied

    on to determine what things are connected=C2=A0=C2=A0=C2=A0 to the ne=
twork.=C2=A0 To
    address

    this risk, MUD managers=C2=A0=C2=A0=C2=A0 may choose to make use of T=
LS proxies
    that

    they trust that would aggregate other information.

    

    

      

% In addressing both of these concerns, implementors should take into
% account what other information they are advertising through
% mechanisms such as mDNS[RFC6872], how a Thing might otherwise be
% identified, perhaps through how it behaves when it is connected to
% the network, whether a Thing is intended to be used by individuals or
% carry personal identifying information, and then apply appropriate
% data minimization techniques.  One approach is to make use of TEAP
% [RFC7170] as the means to share information with authorized
% components in the network.  Network elements may also assist in
% limiting access to the MUD URL through the use of mechanisms such as
% DHCPv6-Shield [RFC7610].
[...]

Appendix C

   In this sample extension we augment the core MUD model to indicate
   whether the device implements DETNET.  If a device later attempts to
   make use of DETNET, an notification or exception might be generated.

Presumably this should say that if a device *claims to not use
DETNET* but then later does?





    

    Righto.

    

    Thanks!

    

    Eliot

  


--------------5F8DB66B0B8B6E232BD189B2--

--4ew7u3k52iPbj1yMn4RMzuOHgBybemzTJ--

--MbVw7qrYy0ZAZ2EzKpePeg6CB91xXFmqw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrWNMAACgkQh7ZrRtnS
ejNt2Qf/f3Ek2FDZ+se//HPurXOFdItdRPk8yIXq0RogH4zr1CtWpfcNwWYri0SY
bxkIEYsVw+3LuKytB8mQCCxYXPICMWT2n8/J7ZvY4MbC7Hgs6s3paHRLpkEjpe06
phQ6NcXbz5vb+xAHtyuOeD+temQttW2ovQiN8VfgI/hI2wW6NLyMd3urg5hFx7+k
vli9MQ7stAcH+YM85iUZMNKp4fApJEDtLKG5CiP2Wmg/S2iwNvmQ665ZMPAX9HYr
g8mlug4jPWS1MWqOBUtzXOHDHb6vzbW8BxF8MQKLea5kyopMNGUQ/ycqKKWbB4GP
WxyrT7qGgy1YgiKutKLyBz3g7CraDw==
=jNya
-----END PGP SIGNATURE-----

--MbVw7qrYy0ZAZ2EzKpePeg6CB91xXFmqw--


From nobody Tue Apr 17 13:52:23 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DBC126DCA for ; Tue, 17 Apr 2018 13:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 4nB8m3UY-CYH for ; Tue, 17 Apr 2018 13:52:19 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7402A126DC2 for ; Tue, 17 Apr 2018 13:52:19 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id h3so26483820wrh.5 for ; Tue, 17 Apr 2018 13:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=81E8QKWuB3acXxxRO/0HVbouf7SqRT2mUuYHOG4oA1g=; b=svbI3f9KrbnfTWXojKThXDfsoqj/UGajBzQQr1Ym80kLD4mZwYvcToNHeDmsj52eme vhjmLvzEaDfU4shNZz/lOrChQkv7vH8w82cxbn7OO3wyG9qZFxXAAcQUxEj4o9hGcHbB Juscbv8Za+8useB0QG8ail6PP0q4mFV1EzVlbtbfOalcFP0Cs4KgximNH4Uo6C4KK8ds klfSzzOjLqotOKikwh6BeyAVrMWngaMD06EDhHbLbN+uq1Pk4CIXWAwGNZ7Xf/cdhNUC C4VF2Nv1d4FjXFXM7E3Rvn3oMX5OhaaTWObCsynM4pOE9BCNry3EMiC7XEJKcuUCJwYT dVIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=81E8QKWuB3acXxxRO/0HVbouf7SqRT2mUuYHOG4oA1g=; b=m/wBZVbw6uJE743557BPO2hPwU8eVLSgus4XvJZXihQeUPfJRiBDE/f+YSomX+L4OA M9kRbColSTSIA5YUeG5tpxOsUlgQtbRalKKiAbY3ML3qKCZl2HPycoDmJqlYlZW8J5Ga xnLkj+durM2XLkFmK1jQnRXQ0qSHqcRrPxWkdTgKYUUPfFZrCK7t6XG/KUZDf2YnV3Y9 ViB5KwBbMWlNCBY9dR+LP7ePpQXYExu/4SwticpJSYZdJwCUHfgbF/okWuAOLePK2CZN pMQsUHkhNdOTgWNjo4XBruMB5Zfj1R4kw+fQG3tAU6cci7ZztPsmkjWX3yG5YPTmdy4/ 3RQw==
X-Gm-Message-State: ALQs6tAz4+lwUm7qUbXo8NLEHBGIoskCX/NaaH+tICnVHJqtQYhGjEh0 dajPv8EX2dT+b6yuOI7SaM7l3TLA0dFoXxL4zwZ1PtDw6nQ=
X-Google-Smtp-Source: AIpwx48fO0moahq8jcwDDpmmsUABmfqvzJm+VGdMgDwPFMCnmn4f4QSIVLiom70wDOLmb+dDi9xWThmG4aW3st9fr6w=
X-Received: by 10.28.139.18 with SMTP id n18mr2025737wmd.26.1523998337202; Tue, 17 Apr 2018 13:52:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.197.138 with HTTP; Tue, 17 Apr 2018 13:51:36 -0700 (PDT)
In-Reply-To: <944d2973-6d1a-c6f7-aec7-79fd60eb4f6e@joelhalpern.com>
References: <6fc59353-a600-ebf8-d525-c4a026cb82bf@joelhalpern.com>  <944d2973-6d1a-c6f7-aec7-79fd60eb4f6e@joelhalpern.com>
From: Warren Kumari 
Date: Tue, 17 Apr 2018 16:51:36 -0400
Message-ID: 
To: "Joel M. Halpern" 
Cc: Tianran Zhou , "opsawg@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 20:52:22 -0000

Noting that I am not the responsible AD for this....

The IPR had been disclosed shortly after the call for adoption, and so
the WG was "aware" of it when the WGLC occurred -- however, it is very
easy to forget that there is IPR during the WGLC, which is why RFC7602
says (emphasis mine):

"The chairs *might* also wish to include a reminder about
 the importance of IPR disclosures in any WGLC message communicated to
 the working group.  (Note: If IPR disclosure statements have been
 filed, the chairs *might* wish to include a link in the WGLC message to
 ensure that the consensus call reflects this information.)"

Section 6 of this also says: "WG chairs and ADs are not expected to
enforce IPR disclosure rules, and this document does not suggest that
they take on such a role.", however, RFC8179 says:
"The IETF policies about Intellectual Property Rights (IPR), such as
   patent rights, relative to technologies developed in the IETF are
   designed to ensure that IETF working groups and participants have as
   much information as possible about any IPR constraints on a technical
   proposal as early as possible in the development process. "
and
"5.4.2. Updating IPR Disclosures

   Those who disclose IPR should be aware that as Internet-Drafts
   evolve, text may be added or removed, and it is recommended that they
   keep this in mind when composing text for disclosures.

   A. Unless sufficient information to identify the issued patent was
      disclosed when the patent application was disclosed, an IPR
      disclosure must be updated or a new disclosure made promptly after
      any of the following has occurred: (1) the publication of a
      previously unpublished patent application, (2) the abandonment of
      a patent application, (3) the issuance of a patent on a previously
      disclosed patent application, or (4) a material change to the IETF
      Document covered by the Disclosure that causes the Disclosure to
      be covered by additional IPR.  If the patent application was
      abandoned, then the new IPR disclosure must explicitly withdraw
      any earlier IPR disclosures based on the application.  IPR
      disclosures against a particular Contribution are assumed to be
      inherited by revisions of the Contribution and by any RFCs that
      are published from the Contribution unless the disclosure has been
      updated or withdrawn."


Again noting that I am not currently the responsible AD for the WG, I
was when the WGLC occurred. So, I think that I'm within my rights to
suggest that the chairs:
1: Suggest that the author who originally had the disclosure made
(thank you, this was the right thing to do!) remind their lawyers of
the requirement in RFC8179 Section 5.4.2
2: As you are raising concerns about whether everyone was aware (and
state that at least one person wasn't) that the chairs ask if anyone
who previously expressed support for progressing the document has
changed their views **because** they were not aware of the existence
of the IPR disclosure.
before sending it to the IESG.


Please please also keep in mind that:
"(a) The IETF will make no determination about the validity of any
       particular IPR claim.

   (b) The IETF, following normal processes, can decide to use
       technology for which IPR disclosures have been made if it decides
       that such a use is warranted."

(and everything else in RFC8129, RFC2026, BCP79, etc).

W





On Tue, Apr 17, 2018 at 8:41 AM, Joel M. Halpern  wrote:
> As far as I can tell, the formal IPR disclosure with IPR terms was not filed
> until several days after that request.
> Thus, the WG can not have considered it in the light of the actual terms.
>
> When I asked one WG participant, he was quite surprised by the terms.
>
> Given the difficulty both Huawei and Ericsson have gotten from IETF
> participants over similar terms, I do not think this can be ignored.
>
> Yours,
> Joel
>
> On 4/17/18 1:12 AM, Tianran Zhou wrote:
>>
>> Hi Joel,
>>
>> Thanks for reminding this important information.
>> Yes, we did the IPR poll when it became a WG draft. The IPR was disclosed
>> then. Please see
>> https://www.ietf.org/mail-archive/web/opsawg/current/msg04792.html
>> We did not received any objection based on this.
>>
>> Thanks,
>> Tianran
>>>
>>> -----Original Message-----
>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> Sent: Tuesday, April 17, 2018 8:25 AM
>>> To: opsawg-chairs@ietf.org
>>> Subject: regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
>>>
>>> Is the working group aware of the IPR disclosure China Mobile made
>>> against
>>> this document?  Specifically, that the IPR disclosure says that a license
>>> may be required?
>>>
>>> Normally, I would not even comment on that, and as you can see, I am not
>>> commenting on the list about it.
>>>
>>> But I note that this is a case where there is a clear workaround (just
>>> don't
>>> do this).  So I would expect that the shepherd report, whenever that is
>>> produced, will need to discuss the IPR disclosure.
>>>
>>> Yours,
>>> Joel
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



-- 
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


From nobody Tue Apr 17 16:00:26 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855A4127010; Tue, 17 Apr 2018 16:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 RaHJE8tPT1c0; Tue, 17 Apr 2018 16:00:23 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 C811C126C89; Tue, 17 Apr 2018 16:00:23 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8AEC7F4BB3BF2; Wed, 18 Apr 2018 00:00:19 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 00:00:21 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 07:00:07 +0800
From: Tianran Zhou 
To: heasley , li zhenqiang , draft-ietf-opsawg-ipfix-bgp-community.all , opsawg 
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT0zX1x60GZaZE206pZAQJbOzf56QBe9sAgAAGZYCAAgbAAIABEawAgAD+jzU=
Date: Tue, 17 Apr 2018 23:00:07 +0000
Message-ID: 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>  <20180416232930.GB47095@shrubbery.net>, <20180417154859.GA59765@shrubbery.net>
In-Reply-To: <20180417154859.GA59765@shrubbery.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A6D64432NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 23:00:25 -0000

--_000_BBA82579FD347748BEADC4C445EA0F21A6D64432NKGEML515MBXchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SSB0aGluayBpdCB3b3J0aCB0aGUgYXV0aG9ycyBjYW4gZGlzY3VzcyBhYm91dCB0aGlzIElQUiBp
biB0aGUgV0cgYmVmb3JlIHNlbmRpbmcgdGhlIGRyYWZ0IHRvIElFU0cuDQoNClRpYW5yYW4NCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VudCBmcm9tIFdlTGluaw0KDQq3
orz+yMujuiBoZWFzbGV5DQrK1bz+yMujuiBsaSB6aGVucWlhbmc8bGlfemhlbnFpYW5nQGhvdG1h
aWwuY29tPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+PjtydGctZGlyPHJ0Zy1kaXJA
aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PjtnZW4tYXJ0PGdlbi1hcnRAaWV0Zi5v
cmc8bWFpbHRvOmdlbi1hcnRAaWV0Zi5vcmc+PjtkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3At
Y29tbXVuaXR5LmFsbDxkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LmFsbEBp
ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS5hbGxA
aWV0Zi5vcmc+PjtpZXRmPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+PjtvcHNh
d2c8b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+Pg0K1vfM4qO6IFJlOiBS
dGdkaXIgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5p
dHktMDYNCsqxvOSjuiAyMDE4LTA0LTE3IDIzOjQ5OjE2DQoNCldoeSBpcyB0aGVyZSBJUFIgb24g
dGhpcyBkcmFmdD8gIElzIHRoaXMgYmVjYXVzZSBvZiBzZWN0aW9uIDM/ICBBIHNlY3Rpb24NCnRo
YXQgaXMgdW5uZWNlc3NhcnkgYW5kIGNvdWxkIGJlIGVudGlyZWx5IHJlbW92ZWQgd2l0aG91dCBh
ZmZlY3RpbmcgdGhlDQpkcmFmdCBpbiBhbnkgbWFubmVyPw0KDQpPdGhlcndpc2UsIEkgdGhpbmsg
aXQgYWJzb2x1dGVseSBhYnN1cmQgdGhhdCB0aGVyZSBpcyBJUFIgb24gdGhpcyBkb2N1bWVudC4N
Cg==

--_000_BBA82579FD347748BEADC4C445EA0F21A6D64432NKGEML515MBXchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











I think it worth the=
 authors can discuss about this IPR in the WG before sending the draft to I=
ESG.



Tianran







Sent from WeLink








=B7=A2=BC=FE=C8=CB=A3=BA heasley


=CA=D5=BC=FE=C8=CB=A3=BA li zhenqiang<li_zhenqiang@hotmail.com>;rtg-dir<rtg-dir@ietf.org>;gen-art<gen-art@ietf.org>;draft-ietf-opsawg-ipfix-=
bgp-community.all<draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>;=
ietf<ietf@ietf.org>;opsawg<opsawg@ietf.org>


=D6=F7=CC=E2=A3=BA Re: Rtgdir early review of draft-ietf-opsawg=
-ipfix-bgp-community-06


=CA=B1=BC=E4=A3=BA 2018-04-17 23:49:16









Why is there IPR on this draft?  Is this beca=
use of section 3?  A section

that is unnecessary and could be entirely removed without affecting the

draft in any manner?



Otherwise, I think it absolutely absurd that there is IPR on this document.=








--_000_BBA82579FD347748BEADC4C445EA0F21A6D64432NKGEML515MBXchi_--


From nobody Tue Apr 17 19:13:59 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771C2124217 for ; Tue, 17 Apr 2018 19:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 4dJ0xoTwvp_A for ; Tue, 17 Apr 2018 19:13:56 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 C4E76120047 for ; Tue, 17 Apr 2018 19:13:55 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D358BDEEBA603 for ; Wed, 18 Apr 2018 03:13:51 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 03:13:52 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 10:13:50 +0800
From: Tianran Zhou 
To: Warren Kumari , "Joel M. Halpern" 
CC: "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
Thread-Index: AQHT1eKXM+Now+Ib2USAufxIh7OTxKQEWghQgAAG1wCAAIj/AIAA2nZg
Date: Wed, 18 Apr 2018 02:13:50 +0000
Message-ID: 
References: <6fc59353-a600-ebf8-d525-c4a026cb82bf@joelhalpern.com>  <944d2973-6d1a-c6f7-aec7-79fd60eb4f6e@joelhalpern.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 02:13:58 -0000

DQpUaGFua3MgV2FycmVuIHZlcnkgbXVjaCBmb3IgdGhlIHN1Z2dlc3Rpb25zIGZyb20gdGhlIEFE
IHNpZGUuDQpCYXNlIG9uIEFEIHN1Z2dlc3Rpb25zLCBJIHdpdGggdGhlIFdHIENoYWlyIHJvbGUs
IHdvdWxkIGxpa2UgdG86DQoxLiBMZXQgdGhlIGF1dGhvcnMgdG8gZGlzY3VzcyB0aGUgcmVsYXRp
b24gYmV0d2VlbiB0aGUgSVBSIGFuZCB0aGUgZHJhZnQsIGFuZCBnZXQgd2lkZXIgV0cgYXdhcmVu
ZXNzLiANCjIuIEJhc2Ugb24gdGhlIGFib3ZlLCBzZWUgaWYgdGhlIGF1dGhvcnMgbmVlZCB0byB1
cGRhdGUgdGhlIElQUiBkaXNjbG9zdXJlLg0KMy4gQXNrIHRoZSBjb25zZW5zdXMgYWdhaW4gYmVm
b3JlIHNlbmRpbmcgdG8gSUVTRy4NCg0KVGhhbmtzLA0KVGlhbnJhbiANCg0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1
bWFyaS5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTggNDo1MiBBTQ0KPiBU
bzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiBDYzogVGlhbnJhbiBa
aG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgb3BzYXdnQGlldGYub3JnDQo+IFN1YmplY3Q6
IFJlOiBbT1BTQVdHXSByZWdhcmRpbmcgZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11
bml0eTogSVBSDQo+IGNhbGwNCj4gDQo+IE5vdGluZyB0aGF0IEkgYW0gbm90IHRoZSByZXNwb25z
aWJsZSBBRCBmb3IgdGhpcy4uLi4NCj4gDQo+IFRoZSBJUFIgaGFkIGJlZW4gZGlzY2xvc2VkIHNo
b3J0bHkgYWZ0ZXIgdGhlIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgc28gdGhlDQo+IFdHIHdhcyAi
YXdhcmUiIG9mIGl0IHdoZW4gdGhlIFdHTEMgb2NjdXJyZWQgLS0gaG93ZXZlciwgaXQgaXMgdmVy
eSBlYXN5IHRvDQo+IGZvcmdldCB0aGF0IHRoZXJlIGlzIElQUiBkdXJpbmcgdGhlIFdHTEMsIHdo
aWNoIGlzIHdoeSBSRkM3NjAyIHNheXMgKGVtcGhhc2lzDQo+IG1pbmUpOg0KPiANCj4gIlRoZSBj
aGFpcnMgKm1pZ2h0KiBhbHNvIHdpc2ggdG8gaW5jbHVkZSBhIHJlbWluZGVyIGFib3V0ICB0aGUg
aW1wb3J0YW5jZQ0KPiBvZiBJUFIgZGlzY2xvc3VyZXMgaW4gYW55IFdHTEMgbWVzc2FnZSBjb21t
dW5pY2F0ZWQgdG8gIHRoZSB3b3JraW5nIGdyb3VwLg0KPiAoTm90ZTogSWYgSVBSIGRpc2Nsb3N1
cmUgc3RhdGVtZW50cyBoYXZlIGJlZW4gIGZpbGVkLCB0aGUgY2hhaXJzICptaWdodCogd2lzaA0K
PiB0byBpbmNsdWRlIGEgbGluayBpbiB0aGUgV0dMQyBtZXNzYWdlIHRvICBlbnN1cmUgdGhhdCB0
aGUgY29uc2Vuc3VzIGNhbGwNCj4gcmVmbGVjdHMgdGhpcyBpbmZvcm1hdGlvbi4pIg0KPiANCj4g
U2VjdGlvbiA2IG9mIHRoaXMgYWxzbyBzYXlzOiAiV0cgY2hhaXJzIGFuZCBBRHMgYXJlIG5vdCBl
eHBlY3RlZCB0byBlbmZvcmNlDQo+IElQUiBkaXNjbG9zdXJlIHJ1bGVzLCBhbmQgdGhpcyBkb2N1
bWVudCBkb2VzIG5vdCBzdWdnZXN0IHRoYXQgdGhleSB0YWtlIG9uDQo+IHN1Y2ggYSByb2xlLiIs
IGhvd2V2ZXIsIFJGQzgxNzkgc2F5czoNCj4gIlRoZSBJRVRGIHBvbGljaWVzIGFib3V0IEludGVs
bGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUiksIHN1Y2ggYXMNCj4gICAgcGF0ZW50IHJpZ2h0
cywgcmVsYXRpdmUgdG8gdGVjaG5vbG9naWVzIGRldmVsb3BlZCBpbiB0aGUgSUVURiBhcmUNCj4g
ICAgZGVzaWduZWQgdG8gZW5zdXJlIHRoYXQgSUVURiB3b3JraW5nIGdyb3VwcyBhbmQgcGFydGlj
aXBhbnRzIGhhdmUgYXMNCj4gICAgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBhYm91dCBh
bnkgSVBSIGNvbnN0cmFpbnRzIG9uIGEgdGVjaG5pY2FsDQo+ICAgIHByb3Bvc2FsIGFzIGVhcmx5
IGFzIHBvc3NpYmxlIGluIHRoZSBkZXZlbG9wbWVudCBwcm9jZXNzLiAiDQo+IGFuZA0KPiAiNS40
LjIuIFVwZGF0aW5nIElQUiBEaXNjbG9zdXJlcw0KPiANCj4gICAgVGhvc2Ugd2hvIGRpc2Nsb3Nl
IElQUiBzaG91bGQgYmUgYXdhcmUgdGhhdCBhcyBJbnRlcm5ldC1EcmFmdHMNCj4gICAgZXZvbHZl
LCB0ZXh0IG1heSBiZSBhZGRlZCBvciByZW1vdmVkLCBhbmQgaXQgaXMgcmVjb21tZW5kZWQgdGhh
dCB0aGV5DQo+ICAgIGtlZXAgdGhpcyBpbiBtaW5kIHdoZW4gY29tcG9zaW5nIHRleHQgZm9yIGRp
c2Nsb3N1cmVzLg0KPiANCj4gICAgQS4gVW5sZXNzIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8g
aWRlbnRpZnkgdGhlIGlzc3VlZCBwYXRlbnQgd2FzDQo+ICAgICAgIGRpc2Nsb3NlZCB3aGVuIHRo
ZSBwYXRlbnQgYXBwbGljYXRpb24gd2FzIGRpc2Nsb3NlZCwgYW4gSVBSDQo+ICAgICAgIGRpc2Ns
b3N1cmUgbXVzdCBiZSB1cGRhdGVkIG9yIGEgbmV3IGRpc2Nsb3N1cmUgbWFkZSBwcm9tcHRseSBh
ZnRlcg0KPiAgICAgICBhbnkgb2YgdGhlIGZvbGxvd2luZyBoYXMgb2NjdXJyZWQ6ICgxKSB0aGUg
cHVibGljYXRpb24gb2YgYQ0KPiAgICAgICBwcmV2aW91c2x5IHVucHVibGlzaGVkIHBhdGVudCBh
cHBsaWNhdGlvbiwgKDIpIHRoZSBhYmFuZG9ubWVudCBvZg0KPiAgICAgICBhIHBhdGVudCBhcHBs
aWNhdGlvbiwgKDMpIHRoZSBpc3N1YW5jZSBvZiBhIHBhdGVudCBvbiBhIHByZXZpb3VzbHkNCj4g
ICAgICAgZGlzY2xvc2VkIHBhdGVudCBhcHBsaWNhdGlvbiwgb3IgKDQpIGEgbWF0ZXJpYWwgY2hh
bmdlIHRvIHRoZSBJRVRGDQo+ICAgICAgIERvY3VtZW50IGNvdmVyZWQgYnkgdGhlIERpc2Nsb3N1
cmUgdGhhdCBjYXVzZXMgdGhlIERpc2Nsb3N1cmUgdG8NCj4gICAgICAgYmUgY292ZXJlZCBieSBh
ZGRpdGlvbmFsIElQUi4gIElmIHRoZSBwYXRlbnQgYXBwbGljYXRpb24gd2FzDQo+ICAgICAgIGFi
YW5kb25lZCwgdGhlbiB0aGUgbmV3IElQUiBkaXNjbG9zdXJlIG11c3QgZXhwbGljaXRseSB3aXRo
ZHJhdw0KPiAgICAgICBhbnkgZWFybGllciBJUFIgZGlzY2xvc3VyZXMgYmFzZWQgb24gdGhlIGFw
cGxpY2F0aW9uLiAgSVBSDQo+ICAgICAgIGRpc2Nsb3N1cmVzIGFnYWluc3QgYSBwYXJ0aWN1bGFy
IENvbnRyaWJ1dGlvbiBhcmUgYXNzdW1lZCB0byBiZQ0KPiAgICAgICBpbmhlcml0ZWQgYnkgcmV2
aXNpb25zIG9mIHRoZSBDb250cmlidXRpb24gYW5kIGJ5IGFueSBSRkNzIHRoYXQNCj4gICAgICAg
YXJlIHB1Ymxpc2hlZCBmcm9tIHRoZSBDb250cmlidXRpb24gdW5sZXNzIHRoZSBkaXNjbG9zdXJl
IGhhcyBiZWVuDQo+ICAgICAgIHVwZGF0ZWQgb3Igd2l0aGRyYXduLiINCj4gDQo+IA0KPiBBZ2Fp
biBub3RpbmcgdGhhdCBJIGFtIG5vdCBjdXJyZW50bHkgdGhlIHJlc3BvbnNpYmxlIEFEIGZvciB0
aGUgV0csIEkgd2FzDQo+IHdoZW4gdGhlIFdHTEMgb2NjdXJyZWQuIFNvLCBJIHRoaW5rIHRoYXQg
SSdtIHdpdGhpbiBteSByaWdodHMgdG8gc3VnZ2VzdCB0aGF0DQo+IHRoZSBjaGFpcnM6DQo+IDE6
IFN1Z2dlc3QgdGhhdCB0aGUgYXV0aG9yIHdobyBvcmlnaW5hbGx5IGhhZCB0aGUgZGlzY2xvc3Vy
ZSBtYWRlICh0aGFuayB5b3UsDQo+IHRoaXMgd2FzIHRoZSByaWdodCB0aGluZyB0byBkbyEpIHJl
bWluZCB0aGVpciBsYXd5ZXJzIG9mIHRoZSByZXF1aXJlbWVudCBpbg0KPiBSRkM4MTc5IFNlY3Rp
b24gNS40LjINCj4gMjogQXMgeW91IGFyZSByYWlzaW5nIGNvbmNlcm5zIGFib3V0IHdoZXRoZXIg
ZXZlcnlvbmUgd2FzIGF3YXJlIChhbmQgc3RhdGUNCj4gdGhhdCBhdCBsZWFzdCBvbmUgcGVyc29u
IHdhc24ndCkgdGhhdCB0aGUgY2hhaXJzIGFzayBpZiBhbnlvbmUgd2hvIHByZXZpb3VzbHkNCj4g
ZXhwcmVzc2VkIHN1cHBvcnQgZm9yIHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudCBoYXMgY2hhbmdl
ZCB0aGVpciB2aWV3cw0KPiAqKmJlY2F1c2UqKiB0aGV5IHdlcmUgbm90IGF3YXJlIG9mIHRoZSBl
eGlzdGVuY2Ugb2YgdGhlIElQUiBkaXNjbG9zdXJlLg0KPiBiZWZvcmUgc2VuZGluZyBpdCB0byB0
aGUgSUVTRy4NCj4gDQo+IA0KPiBQbGVhc2UgcGxlYXNlIGFsc28ga2VlcCBpbiBtaW5kIHRoYXQ6
DQo+ICIoYSkgVGhlIElFVEYgd2lsbCBtYWtlIG5vIGRldGVybWluYXRpb24gYWJvdXQgdGhlIHZh
bGlkaXR5IG9mIGFueQ0KPiAgICAgICAgcGFydGljdWxhciBJUFIgY2xhaW0uDQo+IA0KPiAgICAo
YikgVGhlIElFVEYsIGZvbGxvd2luZyBub3JtYWwgcHJvY2Vzc2VzLCBjYW4gZGVjaWRlIHRvIHVz
ZQ0KPiAgICAgICAgdGVjaG5vbG9neSBmb3Igd2hpY2ggSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVl
biBtYWRlIGlmIGl0IGRlY2lkZXMNCj4gICAgICAgIHRoYXQgc3VjaCBhIHVzZSBpcyB3YXJyYW50
ZWQuIg0KPiANCj4gKGFuZCBldmVyeXRoaW5nIGVsc2UgaW4gUkZDODEyOSwgUkZDMjAyNiwgQkNQ
NzksIGV0YykuDQo+IA0KPiBXDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gVHVlLCBBcHIgMTcs
IDIwMTggYXQgODo0MSBBTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3
cm90ZToNCj4gPiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIGZvcm1hbCBJUFIgZGlzY2xvc3Vy
ZSB3aXRoIElQUiB0ZXJtcyB3YXMgbm90DQo+ID4gZmlsZWQgdW50aWwgc2V2ZXJhbCBkYXlzIGFm
dGVyIHRoYXQgcmVxdWVzdC4NCj4gPiBUaHVzLCB0aGUgV0cgY2FuIG5vdCBoYXZlIGNvbnNpZGVy
ZWQgaXQgaW4gdGhlIGxpZ2h0IG9mIHRoZSBhY3R1YWwgdGVybXMuDQo+ID4NCj4gPiBXaGVuIEkg
YXNrZWQgb25lIFdHIHBhcnRpY2lwYW50LCBoZSB3YXMgcXVpdGUgc3VycHJpc2VkIGJ5IHRoZSB0
ZXJtcy4NCj4gPg0KPiA+IEdpdmVuIHRoZSBkaWZmaWN1bHR5IGJvdGggSHVhd2VpIGFuZCBFcmlj
c3NvbiBoYXZlIGdvdHRlbiBmcm9tIElFVEYNCj4gPiBwYXJ0aWNpcGFudHMgb3ZlciBzaW1pbGFy
IHRlcm1zLCBJIGRvIG5vdCB0aGluayB0aGlzIGNhbiBiZSBpZ25vcmVkLg0KPiA+DQo+ID4gWW91
cnMsDQo+ID4gSm9lbA0KPiA+DQo+ID4gT24gNC8xNy8xOCAxOjEyIEFNLCBUaWFucmFuIFpob3Ug
d3JvdGU6DQo+ID4+DQo+ID4+IEhpIEpvZWwsDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgcmVtaW5k
aW5nIHRoaXMgaW1wb3J0YW50IGluZm9ybWF0aW9uLg0KPiA+PiBZZXMsIHdlIGRpZCB0aGUgSVBS
IHBvbGwgd2hlbiBpdCBiZWNhbWUgYSBXRyBkcmFmdC4gVGhlIElQUiB3YXMNCj4gPj4gZGlzY2xv
c2VkIHRoZW4uIFBsZWFzZSBzZWUNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo
aXZlL3dlYi9vcHNhd2cvY3VycmVudC9tc2cwNDc5Mi5odG1sDQo+ID4+IFdlIGRpZCBub3QgcmVj
ZWl2ZWQgYW55IG9iamVjdGlvbiBiYXNlZCBvbiB0aGlzLg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+
ID4+IFRpYW5yYW4NCj4gPj4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+
Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4g
Pj4+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDE4IDg6MjUgQU0NCj4gPj4+IFRvOiBvcHNh
d2ctY2hhaXJzQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiByZWdhcmRpbmcgZHJhZnQtaWV0Zi1v
cHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eTogSVBSIGNhbGwNCj4gPj4+DQo+ID4+PiBJcyB0aGUg
d29ya2luZyBncm91cCBhd2FyZSBvZiB0aGUgSVBSIGRpc2Nsb3N1cmUgQ2hpbmEgTW9iaWxlIG1h
ZGUNCj4gPj4+IGFnYWluc3QgdGhpcyBkb2N1bWVudD8gIFNwZWNpZmljYWxseSwgdGhhdCB0aGUg
SVBSIGRpc2Nsb3N1cmUgc2F5cw0KPiA+Pj4gdGhhdCBhIGxpY2Vuc2UgbWF5IGJlIHJlcXVpcmVk
Pw0KPiA+Pj4NCj4gPj4+IE5vcm1hbGx5LCBJIHdvdWxkIG5vdCBldmVuIGNvbW1lbnQgb24gdGhh
dCwgYW5kIGFzIHlvdSBjYW4gc2VlLCBJIGFtDQo+ID4+PiBub3QgY29tbWVudGluZyBvbiB0aGUg
bGlzdCBhYm91dCBpdC4NCj4gPj4+DQo+ID4+PiBCdXQgSSBub3RlIHRoYXQgdGhpcyBpcyBhIGNh
c2Ugd2hlcmUgdGhlcmUgaXMgYSBjbGVhciB3b3JrYXJvdW5kDQo+ID4+PiAoanVzdCBkb24ndCBk
byB0aGlzKS4gIFNvIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlIHNoZXBoZXJkIHJlcG9ydCwNCj4g
Pj4+IHdoZW5ldmVyIHRoYXQgaXMgcHJvZHVjZWQsIHdpbGwgbmVlZCB0byBkaXNjdXNzIHRoZSBJ
UFIgZGlzY2xvc3VyZS4NCj4gPj4+DQo+ID4+PiBZb3VycywNCj4gPj4+IEpvZWwNCj4gPg0KPiA+
DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiBPUFNBV0cgbWFpbGluZyBsaXN0DQo+ID4gT1BTQVdHQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCj4gDQo+IA0KPiANCj4gLS0NCj4g
SSBkb24ndCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlv
dXNseSBhIGJhZCBpZGVhIGluDQo+IHRoZSBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1
dHRpbmcgcmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyBy
ZWdyZXQNCj4gYXQgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMg
YW5kIHRoYXQgcGFpciBvZiBwYW50cy4NCj4gICAgLS0tbWFmDQo=


From nobody Wed Apr 18 01:26:56 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DF12711E for ; Wed, 18 Apr 2018 01:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 HFLTULGXOGnn for ; Wed, 18 Apr 2018 01:26:52 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 11EDB126D74 for ; Wed, 18 Apr 2018 01:26:52 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 95700740089E2 for ; Wed, 18 Apr 2018 09:26:47 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 09:26:48 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 16:26:38 +0800
From: Tianran Zhou 
To: Alan DeKok , "Douglas Gash (dcmgash)" 
CC: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm 
Thread-Topic: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
Thread-Index: AQHT1H7Q2+J+Xp+Us0+DREWATIPIOqQBsJiAgAOnaYD//zRogIABpoPA
Date: Wed, 18 Apr 2018 08:26:38 +0000
Message-ID: 
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>  <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
In-Reply-To: <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 08:26:55 -0000

Hi the Authors,

I remember you posted a list of Alan's comments in the mailing list, and me=
ntioned what have been addressed and how, what will be addressed later.=20
I think it's a good start. Why not continue doing this for your new revisio=
n.
It would be very helpful.

Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, April 17, 2018 11:07 PM
> To: Douglas Gash (dcmgash) 
> Cc: opsawg@ietf.org; Andrej Ota ; Thorsten Dahm
> 
> Subject: Re: [OPSAWG] New Version Notification for
> draft-ietf-opsawg-tacacs-10.txt
>=20
> On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash) 
> wrote:
> > Initially (up to around version 5) we included just a very simple secur=
ity
> section admitting that T+ was insecure and that the second document would
> address the issue. This was deemed to be insufficient, and instead the WG
> collectively determined that more detail should be added to enumerate som=
e
> of the issues, you kindly catalogued some of these, providing a proposed =
text
> which we took to be a genuine suggestion for text for the document.
>=20
>   Which it was.
>=20
>   The point I've been trying to make for over a year is apparently still
> unclear.
>=20
>   There was no excuse for plagiarizing the text in the first place.  Usin=
g
> it verbatim was fine, so long as attribution was given.
>=20
>   There was no excuse for ignoring every single email I made to the list =
asking
> about this issue.
>=20
>   There was no excuse for *continuing* to plagiarize the text for over a =
year,
> across four separate revisions of the document.
>=20
> > Subsequently we interpreted your proposal more accurately (as just a
> suggestion of the points to cover), and so we made sure that these were c=
overed,
> but without verbatim reuse of the text.  We hope that we have covered the
> thrust of your issues (and others), but without the plagiarism.
>=20
>   I have no idea.  Because at this point, I'm pretty much done reviewing =
the
> document.
>=20
> > 2) Reactivity of the Authors.
> >
> > As far as I know, we have responded to most posts regarding the content
> of the document, with point-by-point replies,
>=20
>   No.
>=20
>   See the list archives, especially May 2017.  There are multiple people
> suggesting that you have *not* done this, and that you *should* do this.
>=20
>   See line-by-line reviews done by me, which were generally ignored.  Des=
pite
> that, I did *multiple* such reviews, until such time as it became clear t=
hat
> such reviews were entirely unproductive.
>=20
> > but there has been, for various logistic reasons, long delays in submit=
ting
> the resulting new documents. Hopefully this has been addresses in last
> versions and we will continue with more rapid uploads until process compl=
etes
> one way or other.
>=20
>   The issue isn't rapid uploads.  The issue is engagement.  It's not
> productive to ignore the messages on the mailing list for 6 months, and t=
hen
> to issue a new release saying "we fixed stuff".
>=20
> > We have not generally responded to posts regarding procedural matters, =
and
> would leave such discussions to more knowledgeable stewards of the lists =
where
> possible,
>=20
>   You haven't responded to posts where I ask about the plagiarism.  A sim=
ple
> reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write.
>=20
> > 3) Change Tracking
> >
> > The uploads have generally had extensive changes relating to comments (=
which
> should generally have been summarized by previous email responses to
> comments).
>=20
>   Which I admit did happen sometimes, but not nearly as often as it shoul=
d
> have.  Again, see mailing list archives from May 2017.  I'm not the only
> person who holds this opinion.  I'm just the main one pushing the point.
>=20
> > Because of this, unless the updates have been for specific purposes (su=
ch
> as the recent update of the security section) then I would leave the chan=
ges
> to the diff tool which works pretty effectively.
>=20
>   The diff tool lets us know what changed in the document.  It doesn't le=
t
> us know if those changes addressed issues raise on the mailing list.
>=20
>   To summarize:
>=20
> * we have no idea if this revision of the document addresses multiple WG
> reviews
>=20
> * we have no idea if the document even describes TACACS+ as currently
> implemented
>=20
>   As such, it should not be put into working group last call, or much les=
s
> published until such time as those issues are addressed.
>=20
>   Alan DeKok.
>=20
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


From nobody Wed Apr 18 01:45:54 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5512711E for ; Wed, 18 Apr 2018 01:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 urFmoIjZ4yMR for ; Wed, 18 Apr 2018 01:45:49 -0700 (PDT)
Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (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 30F91124C27 for ; Wed, 18 Apr 2018 01:45:48 -0700 (PDT)
X-AuditID: d9a97918-2ebff70000004340-79-5ad705ba1216
Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 69.2F.17216.AB507DA5; Wed, 18 Apr 2018 10:45:46 +0200 (CEST)
From: Fioccola Giuseppe 
To: "xiechf.bri@chinatelecom.cn" , opsawg 
Thread-Topic: [OPSAWG] Notification of the new draft of "Coordinated Address Space Management architecture"
Thread-Index: AQHTtPJEWliiFaTqJESFGnft49uJhaQGdSLg
Date: Wed, 18 Apr 2018 08:45:46 +0000
Message-ID: <1032603df9444d259eac60051a865bf7@TELMBXB02RM001.telecomitalia.local>
References: <201803061023555998109@chinatelecom.cn>
In-Reply-To: <201803061023555998109@chinatelecom.cn>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.14.252.247]
x-ti-disclaimer: Disclaimer1
Content-Type: multipart/alternative; boundary="_000_1032603df9444d259eac60051a865bf7TELMBXB02RM001telecomit_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsXCxfdHSncX6/Uogwc/rC1WnNzMZDHj/llW ByaPe7eCPZYs+ckUwBTVwGiTmJeXX5JYkqqQklqcbKvkklmcnJOYmZtapBCSmpOanJ+rpJCZ YqtkrKRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUN lewCS1OLS/IVclOLixPT0zPzFVIT1gtmbG47xVrwwLPi6J9VTA2MU526GDk4JARMJI7+Sexi 5OQQEpjKJHFqmTqIzSZgI3Hw1Qk2EFtEIFKi8fEbVhBbWCBb4tHlCUwQ8VyJJRPXs0PYRhLb m3aA1bMIqEq8m9UFFucVCJR4+XERI8R8Y4nrNzeA1XACre3c0MsCYjMKyEpM2A1RwywgLvFi +gmwXgkBAYkle84zQ9iiEi8f/2OFsA0kti7dxwJhK0qsbp7PBGHLSCw8MpkVYk6+xLbLDxgh bhCUODnzCcsERpFZSFbMQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRfxSia W2FgolcCicnMksSczES9zJJNjMAEcnNlpcQOxu61zocYBTgYlXh4pb9dixJiTSwrrsw9xCjB wawkwrvz8ZUoId6UxMqq1KL8+KLSnNTiQ4w+wJCcyCwlmpwPTG55JfGGJhaWhsYWFkaGFmam OISVxHkd/gCNF0gHJrXs1NSC1CKYcUwcnFINjGH1pcemST7PXndiGtvKFQq17ZvO8F2wD/70 /XwLw8Hk+mun/+VemrlCJvHV37mNX7YbSna98M+OsQwsX9/2estM4U0Hv5/49GV7csQS1c5P 3V/N/uusd3aJPDPpas6381U3AtlWaH6VnFmVkrXn8pkF8q/rpYqcLF9K3r8lGlGyquwb/82n bKeVWIozEg21mIuKEwGIL09UTQMAAA==
Archived-At: 
Subject: [OPSAWG] R: Notification of the new draft of "Coordinated Address Space Management architecture"
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 08:45:53 -0000

--_000_1032603df9444d259eac60051a865bf7TELMBXB02RM001telecomit_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Chongfeng,
I have read this draft.
I think the architectural concepts and components that are introduced here a=
llows a good coordination for the address space management.
I would suggest to add an Use Cases section where it is possible to specify=
 better how CASM system integrates with a Network Operator SDN architecture=
 for the control and supervision of the network and the services.

Best Regards,

Giuseppe

Da: OPSAWG [mailto:opsawg-bounces@ietf.org] Per conto di xiechf.bri@chinatel=
ecom.cn
Inviato: marted=EC 6 marzo 2018 03:24
A: opsawg
Oggetto: [OPSAWG] Notification of the new draft of "Coordinated Address Spac=
e Management architecture"


Dear all,

We have subumitted a new draft as below,


         https://datatracker.ietf.org/doc/draft-li-opsawg-address-pool-manag=
ement-arch/

If you have comments or suggestions, pls feel free to send them.

Thank you for your attention!


Chongfeng Xie

________________________________
xiechf.bri@chinatelecom.cn

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers=
one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla=
 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne=
 immediata comunicazione al mittente e di provvedere alla sua distruzione, G=
razie. 

This e-mail and any attachments is confidential and may contain privileged i=
nformation intended for the addressee(s) only. Dissemination, copying, print=
ing or use by anybody else is unauthorised. If you are not the intended reci=
pient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_1032603df9444d259eac60051a865bf7TELMBXB02RM001telecomit_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Chongfeng=
,<=
/o:p>


I have read=
 this draft.


I think the=
 architectural concepts and components that are introduced here allows a goo=
d coordination for the address space management.


I would sugg=
est to add an Use Cases section where it is possible to specify better how C=
ASM system integrates with a Network Operator SDN architecture
 for the control and supervision of the network and the services.


 


Best Regards=
,


 =
;


Giuseppe


 <=
/o:p>






Da: OPSAWG [mailto:opsawg-bounces@ietf.org]
Per conto di xiechf.bri@chinatelecom.cn

Inviato: marted=EC 6 marzo 2018 03:24

A: opsawg

Oggetto: [OPSAWG] Notification of the new draft of "Coordinated=
 Address Space Management architecture"






 




 <=
/span>






Dear all,



We have subumitted a new draft as below,&=
nbsp;






<=
br>









    &nbs=
p;    https://datatracker.ietf.org/doc/draft-li-=
opsawg-address-pool-management-arch/



If you have comments or suggestions, pls feel free to send them. 



Thank you for your attention!






 <=
/span>






 <=
/span>






Chongfeng Xie=







 <=
/span>













	
		

			

				Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle=
 persone indicate. La diffusione, copia o qualsiasi altra azione derivante d=
alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a=
bbiate ricevuto questo documento per errore siete cortesemente pregati di da=
rne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.
				


				
					This e-mail and any attachments is confidential and may  contain privil=
eged information intended for the addressee(s) only. Dissemination, copying,=
 printing or use by anybody else is unauthorised. If you are not the intende=
d recipient, please delete this message and any attachments and advise the s=
ender by return  e-mail, Thanks.
				
				


				Rispetta l'ambiente. Non stampare questa mail se non è necessa=
rio.
					
		

	




--_000_1032603df9444d259eac60051a865bf7TELMBXB02RM001telecomit_--


From nobody Wed Apr 18 01:56:45 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C06127058 for ; Wed, 18 Apr 2018 01:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 EJ4L2HzEx_3s for ; Wed, 18 Apr 2018 01:56:39 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFD112711E for ; Wed, 18 Apr 2018 01:56:37 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.188:7177.1497762758
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.75 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 09BE22800A5; Wed, 18 Apr 2018 16:56:32 +0800 (CST)
Received: from DANGMM9A10 ([219.142.69.75]) by App0023 with ESMTP id a5a3bd0c-27ff-44dc-95e7-893d95c40e7c for giuseppe.fioccola@telecomitalia.it; Wed Apr 18 16:56:34 2018
X-filter-score: filter<0>
X-Real-From: xiechf.bri@chinatelecom.cn
X-Receive-IP: 219.142.69.75
X-MEDUSA-Status: 0
Date: Wed, 18 Apr 2018 16:56:32 +0800
From: "Chongfeng Xie" 
To: "Fioccola Giuseppe" ,  opsawg 
References: <201803061023555998109@chinatelecom.cn>,  <1032603df9444d259eac60051a865bf7@TELMBXB02RM001.telecomitalia.local>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 8, 379[cn]
Mime-Version: 1.0
Message-ID: <2018041816563172259335@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart816808687872_=----"
Archived-At: 
Subject: Re: [OPSAWG] R: Notification of the new draft of "Coordinated Address Space Management architecture"
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 08:56:43 -0000

This is a multi-part message in MIME format.

------=_001_NextPart816808687872_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkhpLCBHaXVzZXBwZQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQpXZSBmdWxs
eSBhZ3JlZSB3aXRoIHlvdSB0byBhZGQgdGhlIHVzZSBjYXNlIG9mIGludGVncmF0aW9uIENBU00g
c3lzdGVtIHdpdGggU0ROIGFyY2hpdGVjdHVyZSwgSSB0aGluayBpdCBpcyBhIHZlcnkgcHJhdGlj
YWwgb25lIGluIHRlbGVjb20gbmV0d29yay4gIFRoZSBkcmFmdCB3aWxsIGJlIHJldmlzZWQgYmFz
ZWQgb24gdGhlIGNvbW1lbnRzIGluIElFVEYgMTAxIE9QU0FXIFdHIG1lZXRpbmcgYW5kIHRoZSB1
c2UgY2FzZSB5b3UgbWVudGlvbmVkIHdpbGwgYWxzbyBiZSBhZGRlZCBiZWZvcmUgc3VibWlzc2lv
bi4gDQoNClRoYW5rIHlvdSENCg0KQ2hvbmdmZW5nDQoNCg0KDQp4aWVjaGYuYnJpQGNoaW5hdGVs
ZWNvbS5jbg0KIA0KRnJvbTogRmlvY2NvbGEgR2l1c2VwcGUNCkRhdGU6IDIwMTgtMDQtMTggMTY6
NDUNClRvOiB4aWVjaGYuYnJpQGNoaW5hdGVsZWNvbS5jbjsgb3BzYXdnDQpTdWJqZWN0OiBSOiBb
T1BTQVdHXSBOb3RpZmljYXRpb24gb2YgdGhlIG5ldyBkcmFmdCBvZiAiQ29vcmRpbmF0ZWQgQWRk
cmVzcyBTcGFjZSBNYW5hZ2VtZW50IGFyY2hpdGVjdHVyZSINCkhpIENob25nZmVuZywNCkkgaGF2
ZSByZWFkIHRoaXMgZHJhZnQuDQpJIHRoaW5rIHRoZSBhcmNoaXRlY3R1cmFsIGNvbmNlcHRzIGFu
ZCBjb21wb25lbnRzIHRoYXQgYXJlIGludHJvZHVjZWQgaGVyZSBhbGxvd3MgYSBnb29kIGNvb3Jk
aW5hdGlvbiBmb3IgdGhlIGFkZHJlc3Mgc3BhY2UgbWFuYWdlbWVudC4NCkkgd291bGQgc3VnZ2Vz
dCB0byBhZGQgYW4gVXNlIENhc2VzIHNlY3Rpb24gd2hlcmUgaXQgaXMgcG9zc2libGUgdG8gc3Bl
Y2lmeSBiZXR0ZXIgaG93IENBU00gc3lzdGVtIGludGVncmF0ZXMgd2l0aCBhIE5ldHdvcmsgT3Bl
cmF0b3IgU0ROIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGNvbnRyb2wgYW5kIHN1cGVydmlzaW9uIG9m
IHRoZSBuZXR3b3JrIGFuZCB0aGUgc2VydmljZXMuDQogDQpCZXN0IFJlZ2FyZHMsDQogDQpHaXVz
ZXBwZQ0KIA0KRGE6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBQZXIg
Y29udG8gZGkgeGllY2hmLmJyaUBjaGluYXRlbGVjb20uY24NCkludmlhdG86IG1hcnRlZMOsIDYg
bWFyem8gMjAxOCAwMzoyNA0KQTogb3BzYXdnDQpPZ2dldHRvOiBbT1BTQVdHXSBOb3RpZmljYXRp
b24gb2YgdGhlIG5ldyBkcmFmdCBvZiAiQ29vcmRpbmF0ZWQgQWRkcmVzcyBTcGFjZSBNYW5hZ2Vt
ZW50IGFyY2hpdGVjdHVyZSINCiANCiANCkRlYXIgYWxsLA0KDQpXZSBoYXZlIHN1YnVtaXR0ZWQg
YSBuZXcgZHJhZnQgYXMgYmVsb3csIA0KDQoNCiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLW9wc2F3Zy1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC1hcmNo
Lw0KDQpJZiB5b3UgaGF2ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucywgcGxzIGZlZWwgZnJlZSB0
byBzZW5kIHRoZW0uIA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgYXR0ZW50aW9uIQ0KIA0KIA0KQ2hv
bmdmZW5nIFhpZQ0KIA0KDQoNCnhpZWNoZi5icmlAY2hpbmF0ZWxlY29tLmNuDQpRdWVzdG8gbWVz
c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUg
YWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBh
bHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6
aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRv
IHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk
aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl
cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkg
YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu
Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRp
b24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jp
c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl
IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBi
eSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3Rh
bXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uIA0K

------=_001_NextPart816808687872_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable






Hello All,







We have updated the IPR Disclosures. The application number i=
s given. At present the IPR that MAY relate to this draft is a patent appli=
cation in China.







I have to say that we do the IPR Disclosures following the IETF I=
PR rules
 and procedures.  We think the disclosed patent application MAY relate=
 to this draft, so we did the IPR disclosures. Whether or not it is really =
related to this draft depends on the lawyer's judgement.












Best Regards,


Zhenqiang Li








li_zhenqiang@hotmail.com








 






=B7=A2=BC=FE=C8=CB=A3=BA Tianran Zhou


=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2018-04-18 07:00



=D6=F7=CC=E2=A3=BA RE: Rtgdir early review of draft-ietf-o=
psawg-ipfix-bgp-community-06












I think it worth the=
 authors can discuss about this IPR in the WG before sending the draft to I=
ESG.



Tianran







Sent from WeLink








=B7=A2=BC=FE=C8=CB=A3=BA heasley


=CA=D5=BC=FE=C8=CB=A3=BA li zhenqiang<li_zhenqiang@hotmail.com>;rtg-dir<rtg-dir@ietf.org>;gen-art<gen-art@ietf.org>;draft-ietf-opsawg-ipfix-=
bgp-community.all<draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>;=
ietf<ietf@ietf.org>;opsawg<opsawg@ietf.org>


=D6=F7=CC=E2=A3=BA Re: Rtgdir early review of draft-ietf-opsawg=
-ipfix-bgp-community-06


=CA=B1=BC=E4=A3=BA 2018-04-17 23:49:16









Why is there IPR on this draft?  Is this beca=
use of section 3?  A section

that is unnecessary and could be entirely removed without affecting the

draft in any manner?



Otherwise, I think it absolutely absurd that there is IPR on this document.=













--_000_SINPR0601MB18056406ADDD40B5AEF9ABCBFCB50SINPR0601MB1805_--


From nobody Thu Apr 19 02:40:04 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21D12D7EA; Thu, 19 Apr 2018 02:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 B-CRfNrZTCna; Thu, 19 Apr 2018 02:39:52 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039E4124C27; Thu, 19 Apr 2018 02:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7407; q=dns/txt; s=iport; t=1524130792; x=1525340392; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=S39XzRbN2CXIORsqaAR1rT7Ta8HQKfIqc2AwdsH9Vk4=; b=gcOiVRglaXu+ze2o4Y7fn7C3noRM1SXwcSbRdH8ENjUr21E2uXAQZQVe ujvS4doflpu2BhsaOVp6ltRfZlpjqKI2Wn2iPckAH3XPZ6+3oC/k4kVxW I0wmDefoBIpTKqYmHucXy7FhXwgNczF4x9wkFsQKy21GLg7al+xa2VOtV c=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,468,1517875200"; d="asc'?scan'208"; a="3230082"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 09:39:49 +0000
Received: from [10.61.210.190] ([10.61.210.190]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3J9dmgJ004514; Thu, 19 Apr 2018 09:39:49 GMT
To: Adam Roach , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
Date: Thu, 19 Apr 2018 11:39:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LBcLU0wyLqkun2lEfAG8x1OQmQ1AQBsYf"
Archived-At: 
Subject: Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 09:39:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LBcLU0wyLqkun2lEfAG8x1OQmQ1AQBsYf
Content-Type: multipart/mixed; boundary="qTMmeb5jJ5wrRPmrHXhdDnytQDQ7d2dSU";
 protected-headers="v1"
From: Eliot Lear 
To: Adam Roach , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
Subject: Re: Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>
In-Reply-To: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>

--qTMmeb5jJ5wrRPmrHXhdDnytQDQ7d2dSU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Adam,


On 19.04.18 07:36, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I would like to thank everyone who worked on this document, and the aut=
hors in
> particular for clear, easy-to-read prose. The described mechanism seems=
 quite useful.
>
> -----------------------------------------------------------------------=
----
>
> =C2=A71.3:
>
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>  document are to be interpreted as described in [RFC2119].
> This document also uses lowercase forms of these words. Consider using =
the
> boilerplate from RFC 8174.

I propose to include this change.
>
> -----------------------------------------------------------------------=
----
>
> =C2=A71.6:
>
>>  Section 5.3.2) containing "application/mud+json", an "Accept-
>>  Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
>>  header ([RFC7231], Section 5.5.3).
> s/header/header field/ (three times)

ACK
>
> -----------------------------------------------------------------------=
----
>
> =C2=A71.7:
>
>>  JSON is used as a serialization for compactness and readability,
> Perhaps cite RFC 7159 here?

Now 8259.

>
> -----------------------------------------------------------------------=
----
>
> =C2=A73.5:
>
>>  A MUD controller MAY still periodically check for updates.
> I'm surprised to see this as a "MAY" rather than a "SHOULD." For exampl=
e, even
> an unsupported device may be the subject of a CERT security advisory, a=
nd the
> manufacturer would presumably (if possible) take whatever mitigating st=
eps would
> make sense.

I think this is definitional.=C2=A0 The idea in the preceding text really=
 is
that once the vendor sets this, they really have no intention of
updating even CERT-based issues.=C2=A0 This is another instance where
operational experience could provide us guidance between MAY and SHOULD.
>
> -----------------------------------------------------------------------=
----
>
> =C2=A78:
>
>>                    "ietf-acldns:src-dnsname": "test.com",
> The domain "test.com" is registered by an entity known as TESTCOM Inc. =
It's
> probably best to avoid its use in an example. I would propose "test.exa=
mple.org"
> or something else reserved by RFC 6761.

Good catch!
>
> (This applies to three other locations in the document as well)
>
> -----------------------------------------------------------------------=
----
>
> =C2=A79:
>
>>   reserved =3D 1*( CHAR ) ; from [RFC5234]
> Is there a reason to restrict this to be only 7 bits?

It's mostly fear of the unknown.=C2=A0 We don't know how this stuff will =
be
carried.=C2=A0 But since the URL can be 8 bits wide, I suppose this issue=

will have to be solved anyway, so.... OCTET then?

>
> -----------------------------------------------------------------------=
----
>
> =C2=A711:
>
>>  The LLDP vendor specific frame has the following format:
>>
>>  +--------+--------+----------+---------+--------------
>>  |TLV Type|  len   |   OUI    |subtype  | MUD URL
>>  |  =3D127  |        |=3D 00 00 5E|  =3D 1    |
>>  |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
>>  +--------+--------+----------+---------+--------------
> Should this final field be a MUD URL? Or should it be the (extensible)
> MUDstring defined in =C2=A79?

Leftover.=C2=A0 Good catch.=C2=A0 Changed to MUDString.
>
> -----------------------------------------------------------------------=
----
>
> =C2=A712.2:
>
>>  Prior to retrieving a MUD file the MUD controller SHOULD retrieve the=

>>  MUD signature file by retrieving the value of "mud-signature" and
>>  validating the signature across the MUD file.
> I'm really confused about how this works.=20

Propose changed to... "Prior to processing the rest of the MUD file..."=C2=
=A0
Earlier versions of the draft had an implicit file for the signature.=C2=A0=

We changed that based on feedback from mnot, but this text didn't get
caught.


> -----------------------------------------------------------------------=
----
>
> =C2=A712.2:
>
> I'm surprised to see no discussion in here of duration of signature val=
idity. I
> presume these will typically be cached by the MUD controller.

I think the choices here are limited, and in particular, if a device is
set to unsupported and the signature becomes invalid, you don't want to
just delete the policy.=C2=A0 The same thing occurs if you don't have
Internet connectivity and can't refresh easily.=C2=A0 Deleting the policy=

would violate principle of least astonishment.=C2=A0 Should we say that?

>
> -----------------------------------------------------------------------=
----
>
> =C2=A716.4:
>
>>   o Security considerations: See Security Considerations
>>     of this document.
> Ideally, this would also cite [[RFC 8259]], section 12.
>
>
>

So edited in my copy.

Thanks!

Eliot


--qTMmeb5jJ5wrRPmrHXhdDnytQDQ7d2dSU--

--LBcLU0wyLqkun2lEfAG8x1OQmQ1AQBsYf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrYY+QACgkQh7ZrRtnS
ejPl8AgAmCezQ++5FHcpz4DLdkeFRA09184sNtPesP+pFQGNtNoUFenHWLXai3bL
vcbXZ2RdqL9lPunOy2KOfjSh8hmysGHKmwaAMMjdp+DK4HDQfgqnXu3W3cAJQYwU
+LS/ewAlvTkD5t0aD6+PXNzvDjsbti1hFlzOPFi66QBrRJUNSxzuLOE8hO+FKZg9
moScI7vJ6ZW2MSbwg+Oo89hutAzWstakhH+Pm/k1JF59EmQq2xBOeWzg03CYqS1P
RKGfqnjEGWz8K2W60SzFnwkpAJOObb8tobR9yqWJ4EmYudwmwvX7A9z+mfVaFXM2
3OFIyYsiyU78+XoV9Ok88ILFz1UACw==
=1om2
-----END PGP SIGNATURE-----

--LBcLU0wyLqkun2lEfAG8x1OQmQ1AQBsYf--


From nobody Thu Apr 19 02:45:23 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4BB12D82F; Thu, 19 Apr 2018 02:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 jub3qnrPoEQl; Thu, 19 Apr 2018 02:45:15 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB8C127058; Thu, 19 Apr 2018 02:45:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4196; q=dns/txt; s=iport; t=1524131115; x=1525340715; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fYtwZphaXLav0H6WFt/SZBIvv1yfJS91rPUwuPvNIzE=; b=dVfRGLnc6cnDABz/h64bfb03Xd5jCsFRLiFDXxW4To127S/7C2+3nqbM 8V2cCQ1r5Q78JZJ7htkEUen6mnK7Erc42x2ehfjRsjmbgKKnZ5W1V2K1o raYVlWG8lSRHk+w2WLUi+VW1AmYvYNH5OKM5JiYPftoaGPWJcoh2KgVkr g=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,468,1517875200"; d="asc'?scan'208"; a="3275275"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 09:45:12 +0000
Received: from [10.61.210.190] ([10.61.210.190]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3J9jBYh011361; Thu, 19 Apr 2018 09:45:12 GMT
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152406066529.941.10912493457057076569.idtracker@ietfa.amsl.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: 
Date: Thu, 19 Apr 2018 11:45:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152406066529.941.10912493457057076569.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lkI06NIL6USIp8wqLwABADXYhTq5ihfgQ"
Archived-At: 
Subject: Re: [OPSAWG]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-op?= =?utf-8?q?sawg-mud-20=3A_=28with_COMMENT=29?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 09:45:17 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lkI06NIL6USIp8wqLwABADXYhTq5ihfgQ
Content-Type: multipart/mixed; boundary="v6BLTuSGSpb3e5xF4t0KtwGLVePoOVwvk";
 protected-headers="v1"
From: Eliot Lear 
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= ,
 The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: 
Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Yes_on_draft-ietf-opsawg-mud-2?=
 =?UTF-8?Q?0:_=28with_COMMENT=29?=
References: <152406066529.941.10912493457057076569.idtracker@ietfa.amsl.com>
In-Reply-To: <152406066529.941.10912493457057076569.idtracker@ietfa.amsl.com>

--v6BLTuSGSpb3e5xF4t0KtwGLVePoOVwvk
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Mirja,


On 18.04.18 16:11, Mirja K=C3=BChlewind wrote:
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Minor comments:
>
> 1) "is-supported" confused me a bit at the beginning. Maybe "is-maintai=
ned" could be a better name?

I suspect this may just be a tech-language issue, but I view the two as
synonymous.=C2=A0 The description does try to define the term.

>
> 2) Why does the MUD file contain the MUD URL? Is this meant to be used =
as an identifier?
>
>

Oh good question!=C2=A0 Without it, the MUD file itself is not
self-identifying.=C2=A0 This URL provides a means by which one could use
alternative resolution mechanisms.=C2=A0 A good example would be that a M=
UD
file and signature have been uploaded manually.=C2=A0 The file can inform=
 MUD
manager as to what it is intended to be used for.

I propose to include 2nd and 3rd sentences.

> 3) Given this document talks quite often about possible future extensio=
ns, I'm
> also wondering if this should be Experimental. However, I assume the
> framework/architecture that is defined in this doc is not suppoed to ch=
ange and
> as such PS might be good as well.

This isn't intended to be an experiment, but rather that we make
incremental progress on how we build out this capability.=C2=A0 Also
manufacturers really won't code up to an experiment.=C2=A0 This costs the=
m
real COGS to do, and without them, we can't gain necessary experience.

>
> 4) I understand that the use of YANG is quite convinent for ACLs, howev=
er, I'm
> wondering if it is still the right choice if the MUD File would be used=
 to
> describe more detailed behavior/traffic patterns. However, that should =
probably
> not be changed now, but might be another reason to go for experimental.=

> Annother solution would be to further separate the architecture from th=
e MUD
> file format (maybe into different doc?) and include a versioning mechan=
ism in
> the MUD URL.

Welcome to my pain.=C2=A0 The reason we went with JSON + YANG is that the=

basic capability an access list.=C2=A0 Other capabilities will follow, an=
d
the perfect way to do that is by referring to another file.=C2=A0 This ha=
ving
been said, we should leave room for the possibility that the format WILL
change over time, but I expect the timescales to be quite great.

Eliot


--v6BLTuSGSpb3e5xF4t0KtwGLVePoOVwvk--

--lkI06NIL6USIp8wqLwABADXYhTq5ihfgQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrYZScACgkQh7ZrRtnS
ejMu4AgAjMrKTEIFRWacwXD39xQdTqkP5skrDzuJ9nyFN+MIMPHjVm6bC/tvSpEu
1SkLfwr14M72cdJzNU0oT+NvkpEBC9ihq0co65ON1AwR6KitqI40620LBRV1R6y+
mPenS7l8q3uDmZkMn7VfIWYW7I7mweNQPuduZ5JfzOJk0OLe+Hye/fFTaTBaFdr8
xga/2zszQXpwO3yUvUF73/BdMUwGGWnizqDlHIIOYPuDDUmD0+fXDUpWzTeKjS9K
JsCt6vSy1DjMPY1scyMwxumZlnLSETW6615p30HF2WAKmmhmvMs3QIKTUc4mFl8d
lQxmUEjEQzyPgNBFY5EMCa1vzzCExw==
=eKE/
-----END PGP SIGNATURE-----

--lkI06NIL6USIp8wqLwABADXYhTq5ihfgQ--


From nobody Thu Apr 19 05:14:22 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC71A12D956; Thu, 19 Apr 2018 05:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ozYvfIU606ki; Thu, 19 Apr 2018 05:14:18 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431C31271FD; Thu, 19 Apr 2018 05:14:18 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id u4-v6so13407423wrg.10; Thu, 19 Apr 2018 05:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=bRM/B97TLVF6hLgZsriYieyCn1GwDI8hEh7ATDwFdLQ=; b=N02Zi9o8LALP6HI8605I3PNUEDr6LCBcMvjakbvaYfA9iAxJz/ucHw+awcd5igIyxf 4PPxIOhtIdl0w99glZogryMpvM8dbhk2Pe50Sdt16F4nfoRf+KdN+zIAolqPocLC+So2 gKm4xGZrXcckB9kcU/taBlPeQO9MncdjBrr4xmLHYoPx79Gsmbnjk7LtxiT7hy9crLVj mel1CoQfmoQCKCcCMAbSK0h5VIeK5MBb2cRoYdtsMaeGDTA+ud21bNraBWGZpXVylNu7 jhCG4GXphVxpmhorLH/fKxt91A6dAWW/oNAT6LzieZkrnEpufGVgGTxW8ADpkZbtabQx vjHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bRM/B97TLVF6hLgZsriYieyCn1GwDI8hEh7ATDwFdLQ=; b=oXARdxn23dF1dn5AAUitHrCJBqJ1WmnRuagxpO64NXJPBxpO8uIk6z25Zl68pfzoIQ GRWRLuhFKkkcdiUBiVztuvndyFw3724+837hooDdljAMsXZjS+Ahwh8jEH5P+vQpv7T5 KmeJjbnovNrb0/PQutAQI9KEeHfugwDQnga3+4eDt/k2nB7Y1GcZ3ITAmKuDJ7gPk3jl cT9aXrYlFpYx4HGsaMKvkEpEARV3jV5ZD8nIKT8LlhGtX0reLZnxfF2P+z4LieSJbyXL Ir4+Gy5iiBk3lg2l2t1rqmzVrEvlmNlbJNVYdqM2tNmluQ0LK2OMm4aCNUF24jFiBzqV m5YA==
X-Gm-Message-State: ALQs6tDyyJ/F/kh4TnqC75VvcbSMF+MFqNjyBusgBFrM0aEPJnFxh+qz tqr6JQLd2+xtAif9Sg5NWBTHgSHP
X-Google-Smtp-Source: AIpwx4/BJwLTuIknzf9rZR2klf0iQ6ttLjLgcwzxkT9MwHwQdLTzqrydRLyn9+p9otxy4nBtkmeVDQ==
X-Received: by 2002:adf:9cc5:: with SMTP id h5-v6mr4474530wre.11.1524140056522;  Thu, 19 Apr 2018 05:14:16 -0700 (PDT)
Received: from [10.129.51.218] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id 58-v6sm7205263wrv.41.2018.04.19.05.14.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 05:14:15 -0700 (PDT)
To: li zhenqiang , Zhoutianran , heasley , "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" , opsawg 
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>  <20180415160956.GC66082@shrubbery.net>  <20180416232930.GB47095@shrubbery.net> <20180417154859.GA59765@shrubbery.net>  
From: Ignas Bagdonas 
Message-ID: <57512281-f190-916b-60f5-d27ee2cd37a1@gmail.com>
Date: Thu, 19 Apr 2018 13:14:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F4D3E3092DF760058B9B2797"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OPSAWG]  =?utf-8?b?5Zue5aSNOiBSRTogUnRnZGlyIGVhcmx5IHJldmlldyBv?= =?utf-8?q?f_draft-ietf-opsawg-ipfix-bgp-community-06?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 12:14:21 -0000

This is a multi-part message in MIME format.
--------------F4D3E3092DF760058B9B2797
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Could you provide any more details on what specifically is being 
patented? Given that the document does not define new protocol mechanics 
and only adds in codepoints and element encodings, what can be 
practically patented there?

Ignas



On 19/04/2018 10:14, li zhenqiang wrote:
> Hello All,
>
> We have updated the IPR Disclosures. The application number is given. 
> At present the IPR that MAY relate to this draft is a patent 
> application in China.
>
> I have to say that we do the IPR Disclosures following the IETF IPR 
> rules and procedures.  We think the disclosed patent application MAY 
> relate to this draft, so we did the IPR disclosures. Whether or not it 
> is really related to this draft depends on the lawyer's judgement.
>
>
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------
> li_zhenqiang@hotmail.com
>
>     *发件人：* Tianran Zhou 
>     *发送时间：* 2018-04-18 07:00
>     *收件人：* heasley ; li zhenqiang
>     ;
>     draft-ietf-opsawg-ipfix-bgp-community.all
>     ;
>     opsawg 
>     *主题：* RE: Rtgdir early review of
>     draft-ietf-opsawg-ipfix-bgp-community-06
>     I think it worth the authors can discuss about this IPR in the WG
>     before sending the draft to IESG.
>
>     Tianran
>
>
>     ------------------------------------------------------------------------
>     Sent from WeLink
>
>     *发件人： *heasley
>     *收件人： *li zhenqiang     >;rtg-dir     >;gen-art     >;draft-ietf-opsawg-ipfix-bgp-community.all     >;ietf     >;opsawg     >
>     *主题： *Re: Rtgdir early review of
>     draft-ietf-opsawg-ipfix-bgp-community-06
>     *时间： *2018-04-17 23:49:16
>
>     Why is there IPR on this draft? Is this because of section 3?  A
>     section
>     that is unnecessary and could be entirely removed without
>     affecting the
>     draft in any manner?
>
>     Otherwise, I think it absolutely absurd that there is IPR on this
>     document.
>


--------------F4D3E3092DF760058B9B2797
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Could you provide any more details on what specifically is being
      patented? Given that the document does not define new protocol
      mechanics and only adds in codepoints and element encodings, what
      can be practically patented there? 

    

    
Ignas

    


    

    

    
On 19/04/2018 10:14, li zhenqiang
      wrote:

    

    

      
      
      
      
Hello All,

      


      

      
We
          have updated the IPR Disclosures. The application number is
          given. At present the IPR that MAY relate to this draft is a
          patent application in China.

      


        

      
I
          have to say that we do the IPR Disclosures following the
          IETF IPR rules and procedures.  We think the disclosed patent
          application MAY relate to this draft, so we did the IPR
          disclosures. Whether or not it is really related to this draft
          depends on the lawyer's judgement.

      


        

      


        

      
Best Regards,

      
Zhenqiang Li

      

      
      

        
 

        

          

            
发件人： Tianran Zhou

            
发送时间： 2018-04-18 07:00

            
            
主题： RE: Rtgdir early review of
              draft-ietf-opsawg-ipfix-bgp-community-06

          

        

        

          

            

              
I
                think it worth the authors can discuss about this IPR in
                the WG before sending the draft to IESG.

                

                Tianran

                

                

                

                Sent from WeLink

                

              

              

                
发件人： heasley

                
收件人： li zhenqiang<li_zhenqiang@hotmail.com>;rtg-dir<rtg-dir@ietf.org>;gen-art<gen-art@ietf.org>;draft-ietf-opsawg-ipfix-bgp-community.all<draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>;ietf<ietf@ietf.org>;opsawg<opsawg@ietf.org>

                
主题： Re: Rtgdir early review of
                  draft-ietf-opsawg-ipfix-bgp-community-06

                
时间： 2018-04-17 23:49:16

                

              

            

            
                
Why is there IPR on this draft? 
                  Is this because of section 3?  A section

                  that is unnecessary and could be entirely removed
                  without affecting the

                  draft in any manner?

                  

                  Otherwise, I think it absolutely absurd that there is
                  IPR on this document.

                

              

        

      

    

    

  


--------------F4D3E3092DF760058B9B2797--


From nobody Thu Apr 19 07:51:26 2018
Return-Path: 
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8090412741D; Thu, 19 Apr 2018 07:51:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: 
Cc: opsawg@ietf.org, ipr-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152414947951.28841.9598605604132660173@ietfa.amsl.com>
Date: Thu, 19 Apr 2018 07:51:19 -0700
Archived-At: 
Subject: [OPSAWG] IPR Disclosure China Mobile Communications Corporation's Statement about IPR related to draft-ietf-opsawg-ipfix-bgp-community
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 14:51:19 -0000

Dear Zhenqiang Li, Rong Gu, Jie Dong:


An IPR disclosure that pertains to your Internet-Draft entitled "Export
BGP community information in IP Flow Information Export (IPFIX)"
(draft-ietf-opsawg-ipfix-bgp-community) was submitted to the IETF Secretariat
on  and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/3165/). The title of the IPR
disclosure is "China Mobile Communications Corporation's Statement about
IPR related to draft-ietf-opsawg-ipfix-bgp-community"


Thank you

IETF Secretariat


From nobody Thu Apr 19 08:51:39 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56212D86E; Thu, 19 Apr 2018 08:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 YxFmtJTIMJ6T; Thu, 19 Apr 2018 08:51:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072AD120227; Thu, 19 Apr 2018 08:51:33 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3JFpOnp081091 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Apr 2018 10:51:26 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Eliot Lear , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com> <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
From: Adam Roach 
Message-ID: <50453d3a-5bd7-5c28-d37b-efd76709fb4b@nostrum.com>
Date: Thu, 19 Apr 2018 10:51:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 15:51:34 -0000

On 4/19/18 04:39, Eliot Lear wrote:
> I think this is definitional.  The idea in the preceding text really is
> that once the vendor sets this, they really have no intention of
> updating even CERT-based issues.  This is another instance where
> operational experience could provide us guidance between MAY and SHOULD.


My experience includes situations such as Microsoft officially 
discontinuing support of Windows XP in 2014, and yet releasing a 
security patch for it last year. While this is exceptional, it's not 
unheard of. If you want to define "support" to mean something in this 
document other than the way major vendors do, I suggest including a 
clear definition in this document, as readers are likely to make the 
same inferences as I did.

/a


From nobody Thu Apr 19 09:04:58 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B3126BF3; Thu, 19 Apr 2018 09:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 KkZk4m2y8rQz; Thu, 19 Apr 2018 09:04:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EB6124E15; Thu, 19 Apr 2018 09:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2622; q=dns/txt; s=iport; t=1524153887; x=1525363487; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7Gx+dRAKVPkKb37Q+vx+Daw9gMtD2Vzm60aCvLKjINI=; b=F/pkyQiHxvrvmzs3HVMCsNbkFuat94GNafUo9wm/2xoyv/Ne7bKCtWNQ Tu85g/TKvmtS6GAac1+nufEn7/tI+NQq75HBxbk9d/vlLEKO7GrsFft3u ZqLsNhU5gMX0za2H9WFOb4E3q6h2dWksLjpMuQRV0CY+RzQiRyyGbYXbH 4=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,469,1517875200"; d="asc'?scan'208"; a="3282938"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 16:04:44 +0000
Received: from [10.61.210.190] ([10.61.210.190]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3JG4iXU021994; Thu, 19 Apr 2018 16:04:45 GMT
To: Adam Roach , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke , opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com> <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com> <50453d3a-5bd7-5c28-d37b-efd76709fb4b@nostrum.com>
From: Eliot Lear 
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <8b635941-5fac-984e-9604-9c05b5e317b5@cisco.com>
Date: Thu, 19 Apr 2018 18:04:44 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <50453d3a-5bd7-5c28-d37b-efd76709fb4b@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EZPkVdD1T3tH1XAXnsH62ilXkE3miZUj2"
Archived-At: 
Subject: Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 16:04:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EZPkVdD1T3tH1XAXnsH62ilXkE3miZUj2
Content-Type: multipart/mixed; boundary="lO8z2ZPs3Onvl5P3fQqp1nLs6FwsZhcj0";
 protected-headers="v1"
From: Eliot Lear 
To: Adam Roach , The IESG 
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke ,
 opsawg-chairs@ietf.org, opsawg@ietf.org
Message-ID: <8b635941-5fac-984e-9604-9c05b5e317b5@cisco.com>
Subject: Re: Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>
 <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
 <50453d3a-5bd7-5c28-d37b-efd76709fb4b@nostrum.com>
In-Reply-To: <50453d3a-5bd7-5c28-d37b-efd76709fb4b@nostrum.com>

--lO8z2ZPs3Onvl5P3fQqp1nLs6FwsZhcj0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Ok, I'll work on it.


On 19.04.18 17:51, Adam Roach wrote:
> On 4/19/18 04:39, Eliot Lear wrote:
>> I think this is definitional.=C2=A0 The idea in the preceding text rea=
lly is
>> that once the vendor sets this, they really have no intention of
>> updating even CERT-based issues.=C2=A0 This is another instance where
>> operational experience could provide us guidance between MAY and SHOUL=
D.
>
>
> My experience includes situations such as Microsoft officially
> discontinuing support of Windows XP in 2014, and yet releasing a
> security patch for it last year. While this is exceptional, it's not
> unheard of. If you want to define "support" to mean something in this
> document other than the way major vendors do, I suggest including a
> clear definition in this document, as readers are likely to make the
> same inferences as I did.
>
> /a
>
>



--lO8z2ZPs3Onvl5P3fQqp1nLs6FwsZhcj0--

--EZPkVdD1T3tH1XAXnsH62ilXkE3miZUj2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlrYvhwACgkQh7ZrRtnS
ejMeHQf+NY1aIAQAv7fFuhzo+BFGi3DwDJQne18VUXD7KOOdJzucm7VQpXzN+vJz
6vtlbgpAPOXxSjBrm6cqA0o6aMxmXhyAE98StDRebb8JK4xYdKc4UqY8S+VOGVCk
ZsWryTxh4GHAIodID21KxTeE0yk2zp/uDHlDaEbhyNRCWDL09UkkM82cNIMw2SXq
hlkTYu4JDXo/LZc+M4e1AjF3C6KtAyotJ9afJYA6H0hE8aNC+mME8RDjQi/+bgJd
5tWBA181ZHo5qYrKqPzSv7IEfew9MPPgDhRPekPrmRQH3rDja4xgpKTaQK8wdceZ
ZMJ/pnM+YLTXuRmNUYgBK25GtxQgJw==
=gqBn
-----END PGP SIGNATURE-----

--EZPkVdD1T3tH1XAXnsH62ilXkE3miZUj2--


From nobody Thu Apr 19 12:55:30 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1C12DA6F for ; Thu, 19 Apr 2018 12:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level: 
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 pSqt9NyjHsgw for ; Thu, 19 Apr 2018 12:55:26 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FE912DA6E for ; Thu, 19 Apr 2018 12:55:26 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 3BDBF3AB3F; Thu, 19 Apr 2018 19:55:25 +0000 (UTC)
Date: Thu, 19 Apr 2018 19:55:25 +0000
From: heasley 
To: opsawg@ietf.org
Message-ID: <20180419195524.GA28874@shrubbery.net>
Reply-To: 57512281-f190-916b-60f5-d27ee2cd37a1@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
Subject: Re: [OPSAWG] ??: RE: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2018 19:55:29 -0000

> Could you provide any more details on what specifically is being 
> patented? Given that the document does not define new protocol mechanics 
> and only adds in codepoints and element encodings, what can be 
> practically patented there?

Indeed.

Please just withdraw the IPR.  Or, shall we write another without the IPR?

* I'd have read the patent application, but the registration form on the
  CN patent search page does not appear to work.
  http://www.pss-system.gov.cn/sipopublicsearch/inportal/i18n.shtml?params=902F004CA61084A284089435EAAEA94F59CC921A916ADCEB


From nobody Fri Apr 20 01:16:16 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2B1204DA for ; Fri, 20 Apr 2018 01:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl
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 5KXxq6Vf_SSB for ; Fri, 20 Apr 2018 01:16:12 -0700 (PDT)
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B81812704A for ; Fri, 20 Apr 2018 01:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed;  h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent:mime-version:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=I42briBoiNmAwXaPBhkRZAsZ6SHm7JZJFYp9bFK03ts=; b=wH20cfm39mMtGdmS4lxzQw3/kLsjP7Wl2ThZBg6L0PL0GJumpxkuJPVGSRi0HLE438hA8Vx+aUUgfrI3BGEF3c7MeZG0+lwbPYQTZVkNJ/Oq3TSbnMtt/WJexgzZcb1aldM6rP3FQgpw5VGY6M4P6uBdbDoNH9NMi7tjxQBRDrnA2jx+ng8IuUI8by6wEG2U4fQWIH98cHgnErfKevstQh3E2WX9TtYASAWVWLoq5CcIn6y5r8AtTB+RabqWJr60c/XrtnZFhbh05u7OwecHol4z6tryGsrzJI+eQzboFjlDPAYtWvpX6t25MUW5ukN8y00zV/GVsxC8T0BMC7rukw==
Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by ede1-kamx.sidn.nl  with ESMTP id w3K8G97m022128-w3K8G97o022128 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Fri, 20 Apr 2018 10:16:09 +0200
Received: from MacBook-Air-MD.local (94.198.159.144) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 20 Apr 2018 10:16:08 +0200
To: 
From: "Marco Davids (IETF IMAP)" 
Openpgp: preference=signencrypt
Autocrypt: addr=marco.davids@sidn.nl; prefer-encrypt=mutual; keydata= xsDiBEXLdiERBACNEXdo92LDnSxpwjI50+Hi+F64BgeLzkfjUWR4GNZV5QoKm9J/OuI2QHDt sEprMR12wmFMmiNzOKnVAbP2hsgTKQMU+FpqzN0F3DGOKVKuE6DmpMUsTJqTMhu/hja8nvEE 4CbNrnYzYTmJflnu5zruvQJefrGtWYfkj9ug0SVSpwCgvoeH3srMuFQekamauojeuQKnUIkD /jRal+9+PPf2IvIuZQ2p7372ZzuJVUJCICI1BNmHBCECQYIG7z9AYanJLiI/Wcyvsiy+zN9v l+c3bc5dkBcgyWC1lL3Vd9Wku3KkjIHL+4FyAYC/nT21msezgGf/gDuB03MwzcCYuGn1r8UA 9+TOcLB90QWPGgTqLNAYcHHWYFYOA/9V1BnNn+DPB8I5Yk3rFwKFT7Gjz5+GnuLejOyQavwc 8u1DkEv4tsCUGAFyJ6poBN+bxXhiVtEya6HN+16dHNJT46PepWvhMHil4dk8PK7KbRWVwGtg DgwERRlH6cVGyZywoCvwvLd5TL43g7KbEYHOFC+SDbFC8NF9fFuIOr9P680jTWFyY28gRGF2 aWRzIDxtYXJjby5kYXZpZHNAc2lkbi5ubD7CYAQTEQIAIAUCRct2IQIbAwYLCQgHAwIEFQII AwQWAgMBAh4BAheAAAoJENHb8hifeBtSzkcAn3cBSMEPvO5DgsX291u0IZnvtfKIAKCLCO+y vc/3aKlH9HrXDq6h2Guxps7BTQRFy3ZEEAgAiP8orlwfurnOHt77v/6oZ8maAwF2ZNiuz2st fn6+lKMPlaaoa+Myub79mq5FoLtEXVFQt+ewB2ULC7QKHN6CNH7azuL7HfoxR/rDZUwwC8Ns 5Pz0es15ug8c/jx6ddS1KANvq2b1wDGiK0Kk1S035wA61yXNmdO7oYJqHbb0+Q7bh5SSVwA7 DjAUTuaWpO0DBMRANnedfUZQsGMFSNMRpeDbuckg3duBOmz2I1JK3lWHnAYx6MBfDpASJx8a yHX5HwipY3JWeRVYTPu6THuOoDGzGeZySsT4fMagz9b8ms1V5+qhDrJFmJ0Iizl7bD5O81Id JVP0FbzKAyFwoLIAqwADBQf/QN7HhNzzemYUoAYdmV157wVHGnvRhh9A+fCP0ar3icUt2cd1 G3wWXTM5PHc33cUtdWyjgN+mOhE9IlMhi8wyei5usYk1OvvjKgmo3EOkDi35D2xXSguuv+FI zhTO5ym9yM1VY+nm/du56DDT2KGUGT3yrZO1DJaR4DBFfNErmWUuhSOwJ6sT21Jgqbynnmz+ 0XqLBT831Fcq7Tr0HMNYMCaG84a1xDD2kjM+bp1KJC4Yc/75VW3pESYo08H7EOggqwZSwKPj KPVgyoWnIS59xANHPq41HT8WkH5xbbUr2igUW1pR3DAqmyS0OS+UU5V45mL93AXZ2R9WpIHJ xZKPQsJJBBgRAgAJBQJFy3ZEAhsMAAoJENHb8hifeBtSaSIAn31hlP2rFeR6UdDSsn0hJFdb 3qG/AKCUO2aaeBeWxeOVC3NYan4kiKq5+Q==
Message-ID: <517454b6-23c3-4cc6-db61-34260ffbfbd1@sidn.nl>
Date: Fri, 20 Apr 2018 10:16:03 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.159.144]
X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx02.SIDN.local (192.168.2.178)
X-FEAS-SPF: 2 / 2, ip=94.198.159.144, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl
Authentication-Results: ede1-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.144 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl
Archived-At: 
Subject: [OPSAWG] Early release of MUD parser in Lua.
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2018 08:16:15 -0000

In case you're interested;

SIDN Labs (Jelte) is working on a MUD parser in Lua.

https://github.com/SIDN/lua-mud

"A Manufacturer Usage Description (MUD) library in Lua"

This is a very, very early version; it can parse a subset of MUD
specification (draft-20), and find a policy action given IP addresses,
domain names and ports.

It is also added to Luarocks.

-- 
Marco


From nobody Fri Apr 20 04:26:55 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1A126C0F for ; Fri, 20 Apr 2018 04:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: does not support hash algorithm 'sha256')" header.d=ota.si
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 UKTQmNFKAIay for ; Fri, 20 Apr 2018 04:26:50 -0700 (PDT)
Received: from mta2.toshio.eu (mta2.toshio.eu [212.18.48.35]) by ietfa.amsl.com (Postfix) with ESMTP id 494D3126BFD for ; Fri, 20 Apr 2018 04:26:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mta2.toshio.eu (Postfix) with ESMTP id 4A64D16EDF; Fri, 20 Apr 2018 11:26:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ota.si; h= message-id:references:content-transfer-encoding:date:date :in-reply-to:from:from:subject:subject:mime-version:content-type :content-type:received; s=toshio; t=1524223576; x=1526037977; bh=800F55wdAMYTwIuwSeNHNiTM+6GAxT/Qma0e8JeEmrw=; b=VHozEgiQ6wd2 WMg3Rrgz3ShfW9PBcwUG+PD3GzFjcJ2cS+wfN9xkN9nXTUhdDQfGjmkBpS+53d8l s5Hnkk8Lqe1eZbY5rCpJb+6LT60t/4kM2FsMJJZbHCRHKBhtBhQjESyHfgqat+JX OxG5gdAZUKFQhJP5mWsumnpRoo06pkU=
X-Virus-Scanned: amavisd-new at toshio.org
Received: from mta2.toshio.eu ([212.18.48.35]) by localhost (srv-fe-3.dom.ota.si [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EXAv1avG-tCQ; Fri, 20 Apr 2018 11:26:16 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Andrej Ota 
In-Reply-To: <057F06CD-875F-440F-9BF8-EBA3250F2AA5@deployingradius.com>
Date: Fri, 20 Apr 2018 12:26:05 +0100
Cc: Douglas Gash , Thorsten Dahm ,  opsawg@ietf.org
Content-Transfer-Encoding: quoted-printable
References: <20180418184951.0506116A73@mta2.toshio.eu> <057F06CD-875F-440F-9BF8-EBA3250F2AA5@deployingradius.com>
To: Alan DeKok 
Message-Id: <20180420112616.55FE416EDA@mta2.toshio.eu>
Archived-At: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2018 11:26:53 -0000

Hi Alan and everyone in the WG,


Thank you for extending us a helping hand and keeping it extended.


>=20
>> A year's worth of changes is a round number and -06 was also the =
version where we misread Alan's intention and made the mistake of =
including his text verbatim.
>=20
>  The message I sent yesterday said *explicitly* that including the =
text verbatim was fine, so long as attribution was given.
>=20
>  The message from Scott Bradner to the list last year also said this:
>=20
> https://www.ietf.org/mail-archive/web/opsawg/current/msg04835.html
>=20
>  The issue is *not* including the text verbatim.  The issue is the =
failure to acknowledge authorship.

On the topic of the current authorship acknowledgment:

We have added the acknowledgment in -08 in section 10 which currently =
(revision -10) reads:
"The authors would like to thank the following reviewers whose comments =
and contributions made considerable improvements to the document: Alan =
DeKok, Alexander Clouter, Chris Janicki, Tom Petch, Robert Drake, among =
many others.

The authors would particularly like to thank Alan DeKok, who provided =
significant insights and recommendations on all aspects of the document =
and the protocol. Alan DeKok has dedicated considerable effort to =
identify weaknesses and provide remedies to help improve the document."

We tried to capture the full extent of your contributions in the =
acknowledgment section. If it seems to you that we still missed the =
mark, give us some more guidance and we'll amend it.

In a separate mail you also noted that the document was out there for a =
full year without any acknowledgment of your work while that was =
actually part of the document. I do feel we wronged you by this, but I =
do not know how can we remedy this for already "archived" publications =
of the draft.


>=20
>  I fail to understand how this point has been misunderstood.


I'm providing an explanation here. Please do not take it as an excuse =
but rather as what we see to be an honest and certainly not a flattering =
sequence of our choices. I hope to save others from repeating our =
mistakes in future.

We (the authors) have made a series of decisions immediately preceding =
-06 and following -06 which lead to breakdown in communication and =
generated significant frustration in others. The ones I'm aware of are:
 1) We used the text you suggested verbatim in -06 without adding an =
attribution at the same time. This was a big negligence on our part. We =
thought this would show responsiveness by aggregating verbiage of =
others, but in this we neglected that any significant addition requires =
and equally significant acknowledgment.
 2) By the time of Scott's mail, we already committed ourselves to do =
more research into vulnerabilities to expand on what you already =
provided and for that reason we left the mail unanswered at the time.
 3) The work proved to be more time consuming than we expected and this =
was reflected in barely keeping up with expiration deadlines. There was =
only -07 in August and -08, the first version which included an =
attribution, last February. Almost a full year after -06. I can only =
imagine how your frustration must have been growing as months were =
passing while we were completely unresponsive and acknowledgment nowhere =
to be seen. This was another big negligence on our part.
 6) In the meantime we neglected to update the WG with information on:
   6.a) What work we were doing. This robbed the WG of the chance to set =
us on a better course of action.
   6.b) What were the intermediate results of the work even if not yet =
captured in a draft update.
   6.c) Overall progress of the work related to the draft between the =
sparse updates.

Even for this list I do not claim a perfect hindsight. If I missed more =
mistakes that we've made along the way, it would be good to repeat what =
it was even if it's probably frustrating to repeat what was already said =
or written.

  =20

>=20
>> I do not wish to ignore the metaphorical elephant in the room. =
However, I wish to split technical and organizational conversations into =
their separate threads to avoid confusing the two. While I'll be =
describing changes in the "technical" conversation, I and the rest of =
the authors will continue listening and responding to Alan's =
organizational criticism, past and future, in what we believe is the =
most constructive way: improving in the areas where we were found =
wanting.
>=20
>  The goal *is* to have a specification after all.
>=20
>  I am, however, deeply concerned at the miscommunication.  The =
messages could not have been more clear for the past year, and they are =
*still* being misunderstood.

I think we've got to the point where acknowledgment is in section 10 =
since February (added in revision -08, expanded on in -10).

Separate thread of mails is/will_be dealing with the changes to the =
document. That I think is the first step towards getting us back on =
track and in line with what is an expected standard of communicating. I =
think this was a big part of the problem that we caused and you were =
rightfully pointing it out.

I'm sure there are other ways we can do better and I'm still in the =
process of canvasing through mailing list archives to find what else I =
personally missed. But I think the lack of acknowledgment for your work =
and lack of communication are the top two issues to address ASAP and =
ones I think we're now visibly addressing.

If I am still missing something, I am at a loss. I honestly *think* that =
we're now visibly and openly addressing the two major issues we've =
caused.


Andrej Ota.=


From nobody Fri Apr 20 06:38:32 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBF912751F for ; Fri, 20 Apr 2018 06:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 jzZt4mFtg1dd for ; Fri, 20 Apr 2018 06:38:28 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 97B69127136 for ; Fri, 20 Apr 2018 06:38:28 -0700 (PDT)
Received: from [192.168.20.48] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 3E88A198F; Fri, 20 Apr 2018 13:38:27 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok 
In-Reply-To: <20180420112616.55FE416EDA@mta2.toshio.eu>
Date: Fri, 20 Apr 2018 09:38:26 -0400
Cc: Douglas Gash , Thorsten Dahm ,  opsawg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20180418184951.0506116A73@mta2.toshio.eu> <057F06CD-875F-440F-9BF8-EBA3250F2AA5@deployingradius.com> <20180420112616.55FE416EDA@mta2.toshio.eu>
To: Andrej Ota 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2018 13:38:31 -0000

On Apr 20, 2018, at 7:26 AM, Andrej Ota  wrote:
> On the topic of the current authorship acknowledgment:
>=20
> We have added the acknowledgment in -08 in section 10 which currently =
(revision -10) reads:

  That's nice, thanks.

> I'm providing an explanation here. Please do not take it as an excuse =
but rather as what we see to be an honest and certainly not a flattering =
sequence of our choices. I hope to save others from repeating our =
mistakes in future.
>=20
> We (the authors) have made a series of decisions immediately preceding =
-06 and following -06 which lead to breakdown in communication and =
generated significant frustration in others. The ones I'm aware of are:
> 1) We used the text you suggested verbatim in -06 without adding an =
attribution at the same time. This was a big negligence on our part. We =
thought this would show responsiveness by aggregating verbiage of =
others, but in this we neglected that any significant addition requires =
and equally significant acknowledgment.

  What I saw was no response by the authors to my message.  It doesn't =
really matter what else is going on, a simple message of "oops, we're =
sorry" shouldn't take a year to write.

  As for showing responsiveness, a simple 5-minute email would be best.  =
Ignoring multiple messages for a year demonstrates total =
unresponsiveness to the issue.

> 2) By the time of Scott's mail, we already committed ourselves to do =
more research into vulnerabilities to expand on what you already =
provided and for that reason we left the mail unanswered at the time.

  That's not a valid reason for failing to respond to my message.  I'm =
surprised that this would be presented as an excuse, to be honest.

  As for additional research, you have resources that have been ignored: =
the working group.  Perhaps there could be a *discussion* on the WG =
mailing list about the security issues?  A discussion that many people =
were requesting?  After all, that's what the WG is for.

  This attitude again shows a closed attitude towards the document.  The =
authors go off in private, do work, and update the document.  All =
without significant WG interaction.

  The worst part is that it's still clear you don't know *why* WG =
interaction is important.  Many years into the process, and after =
multiple messages telling you what to do, you still show a lack of =
awareness about it.

> 3) The work proved to be more time consuming than we expected and this =
was reflected in barely keeping up with expiration deadlines. There was =
only -07 in August and -08, the first version which included an =
attribution, last February.

  That's not true.  It acknowledged I had *reviewed* the document.  =
There was *no* acknowledgement that "Sections X through Y were written =
by Alan DeKok.

> Almost a full year after -06. I can only imagine how your frustration =
must have been growing as months were passing while we were completely =
unresponsive and acknowledgment nowhere to be seen. This was another big =
negligence on our part.

  It comes across like the document is a private document, and that the =
WG opinions and reviews are completely unimportant.

  If you can spend time researching things, you can spend time =
interacting with the WG.  Which is the whole purpose of a WG.

  The IETF doesn't (or shouldn't) rubber-stamp documents written in =
privacy.  Yet that has been the process so far.

> 6) In the meantime we neglected to update the WG with information on:
>   6.a) What work we were doing. This robbed the WG of the chance to =
set us on a better course of action.
>   6.b) What were the intermediate results of the work even if not yet =
captured in a draft update.
>   6.c) Overall progress of the work related to the draft between the =
sparse updates.
>=20
> Even for this list I do not claim a perfect hindsight. If I missed =
more mistakes that we've made along the way, it would be good to repeat =
what it was even if it's probably frustrating to repeat what was already =
said or written.

  You were CC'd two days ago on my message saying I was OK with using =
the text, but wanted attribution.  Your response to that message =
apologized for misunderstanding my intent, that I didn't want the text =
used.

  That message could not have been more clear.  The charitable =
conclusion is that my message was simply not read.

  Which again shows the problem.

  There have been many promises over the years to "interact more with =
the WG".  It hasn't really happened.  I welcome it, if it happens.  But =
you've given me no reason to believe what you say.

  Alan DeKok.


From nobody Fri Apr 20 09:32:00 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0612D876 for ; Fri, 20 Apr 2018 09:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level: 
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 GBO9Q6g5Uy_A for ; Fri, 20 Apr 2018 09:31:56 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255094.outbound.protection.outlook.com [40.92.255.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C9A1252BA for ; Fri, 20 Apr 2018 09:31:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1eaZao1I1HadNdJry0XRQHB0J4arxXr9M+izKHRBUmw=; b=U57ihAqZGudMY2L5/EI6ILbckvKn64jcp8ETGkLbzx2+O8de7vjJYhTqI+6yZK/QdNyZQR3i4CD5L/SoDe1yi00Hw0MKBl6TGxUOy58ZZkmUm9PEyTPNWyIRnhN67f1S6srB8v5LPbrY+fT55fVg7W6x9qKByI/pgWEajoD0mDQspApI9CjkfE/nBg+d6gTtNvdsJpX8Hwh1WuKwvMx/omVF4ydDVLR7K2KP7Ubiedy80YvwEYSeHGabOTcLHT2zulOjDOdGY+IGLaV+dKd05rsAtXNEYRtyTX+bYZeimNb6iJhpE5ZGJv6OXN3iUyV5dnyQGhjrYApLTq+6UHMrbg==
Received: from HK2APC01FT041.eop-APC01.prod.protection.outlook.com (10.152.248.53) by HK2APC01HT214.eop-APC01.prod.protection.outlook.com (10.152.249.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.696.11; Fri, 20 Apr 2018 16:31:52 +0000
Received: from HKNPR0601MB1794.apcprd06.prod.outlook.com (10.152.248.57) by HK2APC01FT041.mail.protection.outlook.com (10.152.249.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.696.11 via Frontend Transport; Fri, 20 Apr 2018 16:31:52 +0000
Received: from HKNPR0601MB1794.apcprd06.prod.outlook.com ([fe80::c96f:112b:ab80:f31b]) by HKNPR0601MB1794.apcprd06.prod.outlook.com ([fe80::c96f:112b:ab80:f31b%4]) with mapi id 15.20.0696.013; Fri, 20 Apr 2018 16:31:52 +0000
From: li zhenqiang 
To: opsawg , ibagdona , heas 
Thread-Topic: Re: [OPSAWG] ??: RE: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT2MUWs7sKCEoGa0iC6B1SM1QabA==
Date: Fri, 20 Apr 2018 16:31:52 +0000
Message-ID: 
References: <20180419195524.GA28874@shrubbery.net>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:4EA4ADA78C35DB2F51B129DF181F853FACD6B11A2D7074C31D1E8DB598825CFE; UpperCasedChecksum:6E48FD24FAE4C93D489AA59562669FB61A34417E14C581D32912FCDAC0C61BC0; SizeAsReceived:7132; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [aDYbxSuvVqWJ+lI9cedOzFK850PLpMyO]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT214; 7:JSjomRlMbSfYfXvcaxJnMHdv2BunaQqwKhnGjvBGfBTlwDlzcz3N6ktw+vEZhkVCnKmixFTZEuscA1Z0cCT9jv5jsPibcbez4RaKBUT/1Ml42vyzjeQ1Fh+ErODJHVs3Qh5lt+v87j7cev/8M3j/lJPvlJiB2ayQH6JL8GkRwz5LIJGjDiPPOcper66u05xUJr3Irf1I9su5gZszy7sK+YoJRMZGGio3SufHvIDufLEMrkHClAB7M1McbD5bF1p2
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:HK2APC01HT214; 
x-ms-traffictypediagnostic: HK2APC01HT214:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT214; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT214; 
x-forefront-prvs: 0648FCFFA8
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT214; H:HKNPR0601MB1794.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; 
x-microsoft-antispam-message-info: MypifKerihOK6XLXjgZVO9kI+PuHqW4b/COL899f/PSs6GMY63tgW++yFLzvNAHT/V7c3QrbZmd2cGhv+FIOtWD3k3CxGgxc1V49dNyxrjZG4benHA9yfy2btmWO7LAa/tEDKMU3MI6FuTv8GjMEbaWVJ6pE+BGvU+1T3jo+M4FShJDEaU3TRN0+OcpmkYmn
Content-Type: multipart/alternative; boundary="_000_HKNPR0601MB1794BCAF44C23070093CDA2AFCB40HKNPR0601MB1794_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 28dd5605-c1af-4078-1c6e-08d5a6dc3896
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-Network-Message-Id: 28dd5605-c1af-4078-1c6e-08d5a6dc3896
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2018 16:31:52.3296 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT214
Archived-At: 
Subject: Re: [OPSAWG] ??: RE: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Apr 2018 16:31:59 -0000

--_000_HKNPR0601MB1794BCAF44C23070093CDA2AFCB40HKNPR0601MB1794_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Mr. Ignas Bagdonas and Heasley,

The patent application proposes a method to collect the traffic flow inform=
ation related to the  BGP community attribute. It is now a patent applicati=
on in China with application number 201510791418.3 and public disclosure nu=
mber 106713162A. You can use a patent retrival tool such as soopat to find =
this application.
Frankly speaking, I don't know if the patent application can be granted and=
 if it is really related to this draft.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com

From: heasley
Date: 2018-04-20 03:55
To: opsawg
Subject: Re: [OPSAWG] ??: RE: Rtgdir early review of draft-ietf-opsawg-ipfi=
x-bgp-community-06
> Could you provide any more details on what specifically is being
> patented? Given that the document does not define new protocol mechanics
> and only adds in codepoints and element encodings, what can be
> practically patented there?

Indeed.

Please just withdraw the IPR.  Or, shall we write another without the IPR?

* I'd have read the patent application, but the registration form on the
  CN patent search page does not appear to work.
  http://www.pss-system.gov.cn/sipopublicsearch/inportal/i18n.shtml?params=
=3D902F004CA61084A284089435EAAEA94F59CC921A916ADCEB

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--_000_HKNPR0601MB1794BCAF44C23070093CDA2AFCB40HKNPR0601MB1794_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <25417EAA11E2DF4184A3E4E4C0D76186@apcprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable










Dear Mr. Ignas Bagdonas and Heasley,







The patent application proposes a method to collect the traffic f=
low information related to the  BGP community attribute. It is now a p=
atent application in China with application number 201510791418.3 and&=
nbsp;public disclosure number 106713162A. You can use
 a patent retrival tool such as soopat to find this application.


Frankly speaking, I don't know if the patent application can be grante=
d and if it is really related to this draft.









Best Regards,


Zhenqiang Li








li_zhenqiang@hotmail.com








 






From: heasley

Date: 2018-04-20 03:55


To: opsawg


Subject: Re: [OPSAWG] ??: RE: Rtgdir early review of draft=
-ietf-opsawg-ipfix-bgp-community-06








> Could you provide any more details on what specifically is being =



> patented? Given that the document does not define new protocol me=
chanics 


> and only adds in codepoints and element encodings, what can be 

> practically patented there?


 


Indeed.


 


Please just withdraw the IPR.  Or, shall we write another without=
 the IPR?


 


* I'd have read the patent application, but the registration form on t=
he


  CN patent search page does not appear to work.


  http://www.pss-system.gov.cn/sipopublicsearch/inportal/i18n.sht=
ml?params=3D902F004CA61084A284089435EAAEA94F59CC921A916ADCEB


 


_______________________________________________


OPSAWG mailing list


OPSAWG@ietf.org


https://www.ietf.org/mailman/listinfo/opsawg








--_000_HKNPR0601MB1794BCAF44C23070093CDA2AFCB40HKNPR0601MB1794_--


From nobody Mon Apr 23 07:52:15 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F023A129C51 for ; Mon, 23 Apr 2018 07:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: does not support hash algorithm 'sha256')" header.d=ota.si
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 9VClG3rfPZPL for ; Mon, 23 Apr 2018 07:52:10 -0700 (PDT)
Received: from mta2.toshio.eu (unknown [IPv6:2001:470:99f7::b423]) by ietfa.amsl.com (Postfix) with ESMTP id 36E36127909 for ; Mon, 23 Apr 2018 07:52:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mta2.toshio.eu (Postfix) with ESMTP id 9980015933; Mon, 23 Apr 2018 14:51:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ota.si; h= message-id:references:content-transfer-encoding:date:date :in-reply-to:from:from:subject:subject:mime-version:content-type :content-type:received; s=toshio; t=1524495096; x=1526309497; bh=I1gVCVuzbqRd/CMafbHRSS4jXU/CHRN304qKS2QTPhM=; b=t924i6OGvybt s4iCnH2l5vRreB0/pzmJs/oPK4m69arRFtNR9GNMLGD4Sh7sLn+YBo7xfXq3x8it ii/urbZIbUiCCtCOlzoYwqrBLjtHPB19bi0sQ5pprgrQ+cgWjeGD9qdGqnzw+JBI i/25cfPlTWQI2cLTOY/ReLwHUNRpp90=
X-Virus-Scanned: amavisd-new at toshio.org
Received: from mta2.toshio.eu ([212.18.48.35]) by localhost (srv-fe-3.dom.ota.si [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SeRPd_uDd9YT; Mon, 23 Apr 2018 14:51:36 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Andrej Ota 
In-Reply-To: 
Date: Mon, 23 Apr 2018 15:51:23 +0100
Cc: Douglas Gash , Thorsten Dahm 
Content-Transfer-Encoding: quoted-printable
References: <20180418184951.0506116A73@mta2.toshio.eu> <057F06CD-875F-440F-9BF8-EBA3250F2AA5@deployingradius.com> <20180420112616.55FE416EDA@mta2.toshio.eu> 
To: Alan DeKok , opsawg@ietf.org
Message-Id: <20180423145135.91C991592D@mta2.toshio.eu>
Archived-At: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2018 14:52:13 -0000

Hi Alan and everyone,


>> I'm providing an explanation here. Please do not take it as an excuse =
but rather as what we see to be an honest and certainly not a flattering =
sequence of our choices. I hope to save others from repeating our =
mistakes in future.
>>=20
>> We (the authors) have made a series of decisions immediately =
preceding -06 and following -06 which lead to breakdown in communication =
and generated significant frustration in others. The ones I'm aware of =
are:
>> 1) We used the text you suggested verbatim in -06 without adding an =
attribution at the same time. This was a big negligence on our part. We =
thought this would show responsiveness by aggregating verbiage of =
others, but in this we neglected that any significant addition requires =
and equally significant acknowledgment.
>=20
>  What I saw was no response by the authors to my message.  It doesn't =
really matter what else is going on, a simple message of "oops, we're =
sorry" shouldn't take a year to write.
>=20
>  As for showing responsiveness, a simple 5-minute email would be best. =
 Ignoring multiple messages for a year demonstrates total =
unresponsiveness to the issue.

We (all three of us) agree with you on both points.


>=20
>> 2) By the time of Scott's mail, we already committed ourselves to do =
more research into vulnerabilities to expand on what you already =
provided and for that reason we left the mail unanswered at the time.
>=20
>  That's not a valid reason for failing to respond to my message.  I'm =
surprised that this would be presented as an excuse, to be honest.

I have explicitly asked not to take this as an excuse, but as a list of =
errors that we've made. Call it a post-mortem.


>=20
>  As for additional research, you have resources that have been =
ignored: the working group.  Perhaps there could be a *discussion* on =
the WG mailing list about the security issues?  A discussion that many =
people were requesting?  After all, that's what the WG is for.

We completely agree. I have already sent out the first mail with an aim =
to try and reveve the technical discussion about the topic.

I have separately sent a list what we recognized as a negative impact on =
the technical merit of the document - not to excuse ourselves, but to =
enable WG to add more where we missed things while self-reflecting.


>=20
>  This attitude again shows a closed attitude towards the document.  =
The authors go off in private, do work, and update the document.  All =
without significant WG interaction.

We agree and we did take note of how bad this turned out to be. The list =
in the previous e-mail is an attempt to check with WG if we missed more =
than what we're already aware of (point 6.).



>=20
>  The worst part is that it's still clear you don't know *why* WG =
interaction is important.  Many years into the process, and after =
multiple messages telling you what to do, you still show a lack of =
awareness about it.

Apart from trying to reboot the technical discussion, accepting =
responsibility for the mistakes we've done, trying to list the mistakes =
that we're aware of so the WG can point out if we missed anything, =
fixing mistakes that we can fix going forward and consistently keep =
communicating with the rest of the WG, what can we further improve?


>=20
>> 3) The work proved to be more time consuming than we expected and =
this was reflected in barely keeping up with expiration deadlines. There =
was only -07 in August and -08, the first version which included an =
attribution, last February.
>=20
>  That's not true.  It acknowledged I had *reviewed* the document.  =
There was *no* acknowledgement that "Sections X through Y were written =
by Alan DeKok.

I stand corrected. Acknowledgment is not the same as attribution.

What do you think about the following:
"The authors would particularly like to thank Alan DeKok, who provided =
significant insights and recommendations on all aspects of the document =
and the protocol. Alan authored the first draft text of Sections 9.1. =
through 9.8. which served as a critical foundation of the final text =
which continues to include large parts of Alan's original work."


>=20
>> Almost a full year after -06. I can only imagine how your frustration =
must have been growing as months were passing while we were completely =
unresponsive and acknowledgment nowhere to be seen. This was another big =
negligence on our part.
>=20
>  It comes across like the document is a private document, and that the =
WG opinions and reviews are completely unimportant.
>=20
>  If you can spend time researching things, you can spend time =
interacting with the WG.  Which is the whole purpose of a WG.
>=20
>  The IETF doesn't (or shouldn't) rubber-stamp documents written in =
privacy.  Yet that has been the process so far.

We agree with all three points you have raised. I do not like to repeat =
apologies and everyone is probably tired of reading about "will do this" =
or "will do that". The only thing we can do is to let future actions =
speak for themselves.


>=20
>> 6) In the meantime we neglected to update the WG with information on:
>>  6.a) What work we were doing. This robbed the WG of the chance to =
set us on a better course of action.
>>  6.b) What were the intermediate results of the work even if not yet =
captured in a draft update.
>>  6.c) Overall progress of the work related to the draft between the =
sparse updates.
>>=20
>> Even for this list I do not claim a perfect hindsight. If I missed =
more mistakes that we've made along the way, it would be good to repeat =
what it was even if it's probably frustrating to repeat what was already =
said or written.
>=20
>  You were CC'd two days ago on my message saying I was OK with using =
the text, but wanted attribution.  Your response to that message =
apologized for misunderstanding my intent, that I didn't want the text =
used.
>=20
>  That message could not have been more clear.  The charitable =
conclusion is that my message was simply not read.
>=20
>  Which again shows the problem.

We apologized and continue to apologize for bad decisions we've made in =
the past, beginning with the decision to include your text without =
attribution.

I was thinking about the wrong decision we took in 2017 when we =
misunderstood your intent. By the time that was clarified, we were =
already in the progress of committing the next mistake. I understand how =
frustrating this must be, but we can only fix things going forward, we =
cannot make the past any nicer than what we made it.


>=20
>  There have been many promises over the years to "interact more with =
the WG".  It hasn't really happened.  I welcome it, if it happens.  But =
you've given me no reason to believe what you say.

I am happy you decided to keep communicating with us.


Andrej Ota.=


From nobody Wed Apr 25 15:59:48 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B412D88E; Wed, 25 Apr 2018 15:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 TX5uYw0i1cLL; Wed, 25 Apr 2018 15:59:39 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D1612D86E; Wed, 25 Apr 2018 15:59:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 30AE9B8109C; Wed, 25 Apr 2018 15:59:21 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, opsawg@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20180425225921.30AE9B8109C@rfc-editor.org>
Date: Wed, 25 Apr 2018 15:59:21 -0700 (PDT)
Archived-At: 
Subject: [OPSAWG] =?utf-8?q?RFC_8350_on_Alternate_Tunnel_Encapsulation_for?= =?utf-8?q?_Data_Frames_in_Control_and_Provisioning_of_Wireless_Access_Poi?= =?utf-8?q?nts_=28CAPWAP=29?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 22:59:42 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8350

        Title:      Alternate Tunnel Encapsulation for Data Frames
                    in Control and Provisioning of 
                    Wireless Access Points (CAPWAP) 
        Author:     R. Zhang,
                    R. Pazhyannur,
                    S. Gundavelli,
                    Z. Cao,
                    H. Deng,
                    Z. Du
        Status:     Experimental
        Stream:     IETF
        Date:       April 2018
        Mailbox:    zhangr@gsta.com, 
                    rpazhyan@cisco.com, 
                    sgundave@cisco.com,
                    zhencao.ietf@gmail.com, 
                    denghui02@gmail.com,
                    duzongpeng@huawei.com
        Pages:      29
        Characters: 65342
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-opsawg-capwap-alt-tunnel-12.txt

        URL:        https://www.rfc-editor.org/info/rfc8350

        DOI:        10.17487/RFC8350

Control and Provisioning of Wireless Access Points (CAPWAP) is a
protocol for encapsulating a station's data frames between the
Wireless Transmission Point (WTP) and Access Controller (AC).
Specifically, the station's IEEE 802.11 data frames can be either
locally bridged or tunneled to the AC.  When tunneled, a CAPWAP Data
Channel is used for tunneling.  In many deployments, encapsulating
data frames to an entity other than the AC (for example, to an Access
Router (AR)) is desirable.  Furthermore, it may also be desirable to
use different tunnel encapsulation modes between the WTP and the
Access Router.  This document defines an extension to the CAPWAP
protocol that supports this capability and refers to it as alternate
tunnel encapsulation.  The alternate tunnel encapsulation allows 1)
the WTP to tunnel non-management data frames to an endpoint different
from the AC and 2) the WTP to tunnel using one of many known
encapsulation types, such as IP-IP, IP-GRE, or CAPWAP.  The WTP may
advertise support for alternate tunnel encapsulation during the
discovery and join process, and the AC may select one of the
supported alternate tunnel encapsulation types while configuring the
WTP.

This document is a product of the Operations and Management Area Working Group Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


From nobody Mon Apr 30 07:25:32 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A131E1289B0 for ; Mon, 30 Apr 2018 07:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 9cyqrYTT-1IA for ; Mon, 30 Apr 2018 07:25:29 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2419B128C0A for ; Mon, 30 Apr 2018 07:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4643; q=dns/txt; s=iport; t=1525098327; x=1526307927; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fOQtLoMuRu3jQWYyCIai3Y+Db3GKCQiTgfM0/YqCQPo=; b=SyXVSS/2uU9Y5r3bqMigtCNHDBJBAOLquJ+E4MVwAbL3PWwhx1cOco8c O391uRmQKqLNV1Rrb9dD6zrRPohYrWuohHTJ31YzLFgpD0w9VIFCQiQ3v Ws726qunS57d/w11CkK13OcJ9hoOPBFK/MLEdxPgQu5I96h7yTh8AQgTs k=;
X-IronPort-AV: E=Sophos;i="5.49,346,1520899200"; d="scan'208";a="388632493"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2018 14:25:27 +0000
Received: from [10.118.87.87] (rtp-jclarke-nitro6.cisco.com [10.118.87.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w3UEPQNh032634; Mon, 30 Apr 2018 14:25:27 GMT
To: Alan DeKok , "Douglas Gash (dcmgash)" 
Cc: "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm 
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>  <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: 
Date: Mon, 30 Apr 2018 10:25:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 14:25:32 -0000

Alan, T+ authors, and opsawg,

Sorry for the noticeable absence from this thread.  I've been focused on
some dayjob projects these past couple of weeks.

I have followed the threads, though.  I want to hopefully bring some
things to closure and get us all to move forward to come to consensus on
this doc.


On 4/17/18 11:07, Alan DeKok wrote:
> On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash)  wrote:
>> Initially (up to around version 5) we included just a very simple security section admitting that T+ was insecure and that the second document would address the issue. This was deemed to be insufficient, and instead the WG collectively determined that more detail should be added to enumerate some of the issues, you kindly catalogued some of these, providing a proposed text which we took to be a genuine suggestion for text for the document.
> 
>   Which it was.
> 
>   The point I've been trying to make for over a year is apparently still unclear.
> 
>   There was no excuse for plagiarizing the text in the first place.  Using it verbatim was fine, so long as attribution was given.
> 
>   There was no excuse for ignoring every single email I made to the list asking about this issue.
> 
>   There was no excuse for *continuing* to plagiarize the text for over a year, across four separate revisions of the document.

I agree this was not handled well on many fronts, but we can only learn
and move forward.  As a co-chair, I take responsibility for our part and
apologize it took this long to get sorted.  The authors have added
attribution to your excellent contribution and apologized.

I would like to consider the matter, albeit belatedly, closed.

>> 2) Reactivity of the Authors.
>>
>> As far as I know, we have responded to most posts regarding the content of the document, with point-by-point replies,
> 
>   No.
> 
>   See the list archives, especially May 2017.  There are multiple people suggesting that you have *not* done this, and that you *should* do this.

I for one have asked for a summary of changes when I did my last review.
 I did not see it.  There was a subsequent revision that did seem to
absorb my comments, but there wasn't a response to me email.  Typically,
when authors receive feedback, they respond in line to either ack or
discuss points (typos notwithstanding).

> 
>   See line-by-line reviews done by me, which were generally ignored.  Despite that, I did *multiple* such reviews, until such time as it became clear that such reviews were entirely unproductive.
> 
>> but there has been, for various logistic reasons, long delays in submitting the resulting new documents. Hopefully this has been addresses in last versions and we will continue with more rapid uploads until process completes one way or other.
> 
>   The issue isn't rapid uploads.  The issue is engagement.  It's not productive to ignore the messages on the mailing list for 6 months, and then to issue a new release saying "we fixed stuff".

Spot on.  One needs to engage.  I am pleased with the authors' attempts
to do better these past couple of weeks.  I want to see this momentum
continue.

>> 3) Change Tracking
>>
>> The uploads have generally had extensive changes relating to comments (which should generally have been summarized by previous email responses to comments). 
> 
>   Which I admit did happen sometimes, but not nearly as often as it should have.  Again, see mailing list archives from May 2017.  I'm not the only person who holds this opinion.  I'm just the main one pushing the point.
> 
>> Because of this, unless the updates have been for specific purposes (such as the recent update of the security section) then I would leave the changes to the diff tool which works pretty effectively.
> 
>   The diff tool lets us know what changed in the document.  It doesn't let us know if those changes addressed issues raise on the mailing list.
> 
>   To summarize:
> 
> * we have no idea if this revision of the document addresses multiple WG reviews
> 
> * we have no idea if the document even describes TACACS+ as currently implemented
> 
>   As such, it should not be put into working group last call, or much less published until such time as those issues are addressed.

I'm not sure what line-item changes are still outstanding.  Authors, I'm
sure you could look back at your revisions and spot anything that needs
to be addressed here.

I will be submitting an individual review of the new security
requirements soon, and I would like to see this renewed sense of
engagement on the list.

Joe


From nobody Mon Apr 30 07:30:25 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350DA1267BB; Mon, 30 Apr 2018 07:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 yQNOohqf1gUP; Mon, 30 Apr 2018 07:30:22 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EBD124D37; Mon, 30 Apr 2018 07:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7307; q=dns/txt; s=iport; t=1525098622; x=1526308222; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=IUQaw2qdEV4mQ1kDGl1d6rTxB6VaNlDS/KfMLo7maZg=; b=XfDXQOZsPgLneQgv8WeP13lTxoMeYAq9Fgija+9JKw3G4Kv4Hk1BFJ0G zMV8KskJn6aN4yS8IdDFCluw7dDXI2w9Lejkd4G6HT3ZibV6cqtejcGXf Hu5dBH0GHgkdjF+l4+DjFneMUROSFm6BihpJR6o5+pD3SHWTRxhP4ehUd w=;
X-IronPort-AV: E=Sophos;i="5.49,346,1520899200"; d="scan'208";a="107144038"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2018 14:30:22 +0000
Received: from [10.118.87.87] (rtp-jclarke-nitro6.cisco.com [10.118.87.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w3UEULae005658; Mon, 30 Apr 2018 14:30:21 GMT
To: "Douglas Gash (dcmgash)" , "opsawg@ietf.org" 
Cc: "internet-drafts@ietf.org" , Andrej Ota , Thorsten Dahm 
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: 
Date: Mon, 30 Apr 2018 10:30:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 14:30:24 -0000

On 4/15/18 02:27, Douglas Gash (dcmgash) wrote:
> Hello Opsawg,
> 
> We have uploaded a new version of the TACACS+ informational draft which includes corrections for typos over the document as a whole, but also revised the security section. We anticipate this security section will get most comments, so it is reproduced below.
> 
> We will endeavor to be much more reactive to comments, whether on section below, or any other in rest of uploaded document.

Thank you, Douglas.  My individual comments on this new security
requirements section in line below (since you copied it to email).

> 9.1.  General Security of The Protocol
> 
>    TACACS+ protocol does not include a security mechanism that would
>    meet modern-day requirements.  Support for MD5-based crypto pad
>    encryption fails to provide any kind of transport integrity, which
>    presents at least the following risks:
> 
>       Accounting information may be modified by the man-in-the-middle
>       attacker, making such logs unsuitable and untrustable for auditing
>       purposes.
> 
>       Only the body of the request is encrypted which leaves all header
>       fields open to trivial modification by the man-in-the-middle
>       attacker.  For this reason, connections with
>       TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the
>       recommendations section.

JC: Disallowed for discouraged?  This is a doc defining a
currently-deployed protocol.  Implementations MAY allow for this to
work.  However, from a best current practice standpoint, this should be
strongly discouraged.

>    For these reasons, users deploying TACACS+ protocol in their
>    environments MUST limit access to known clients and MUST control the
>    security of the entire transmission path.  Attacks who can guess the
>    key or otherwise break the obfuscation will gain unrestricted and
>    undetected access to all TACACS+ traffic.  Ensuring that a
>    centralized AAA system like TACACS+ is deployed on a secured
>    transport is essential to managing security risk of such an attack.

JC: s/Attacks who/Attackers who/


> 9.3.  Security of Authorization Sessions
> 
>    Authorization sessions MUST be used via secure transport only as it's
>    trivial to execute a successful man-in-the-middle attacks that
>    changes well-known plaintext in either requests or responses.

JC: Your statement makes a lot of sense, but I struggle with how this
can be achieved in the current implementation of T+.  To use normative
language here, you are saying that all T+ servers and all NASes must
implement something like an IPSec tunnel to exchange authz details?
Again, I get the recommendation, but in light of existing, interoperable
implementations, I don't see this being a reality.


> 9.6.  TACACS+ Server Implementation Recommendations
> 
>    The following recommendations are made when implementing a TACACS+
>    server:
> 
>    The Server SHOULD NOT accept any connections which have the
>    TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with
>    applicable ERROR response for type of packet.
> 
>    The configuration of dedicated secret keys per individual client MUST
>    be supported by the Server implementation.  It is also recommended
>    that Servers SHOULD warn administrators if secret keys are not unique
>    per client.
> 
>    If an invalid shared secret is detected, Servers MUST NOT accept any
>    new sessions on a connection, and terminate the connection on
>    completion of any sessions previously established with a valid shared
>    secret.
> 
>    The Server implementation must allow the administrator to mandate:

JC: Should this be MUST?  I ask while still grappling with the use of
such strong language for an informational doc citing recommendations
when so many existing implementations exist in the wild.

> 
>    TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type
> 
>    TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization
> 
>    Minimum length for shared secrets.
> 
> 9.7.  TACACS+ Deployment Best Practices
> 
>    Due to above observations about the TACACS+ protocol, it is critical
>    to only deploy it using secure transport.  A secure transport for
>    TACACS+ is defined as any means that ensure privacy and integrity of
>    all data passed between clients and servers.  There are multiple
>    means of achieving this, all of them beyond the scope of this
>    document.
> 
>    Symmetric encryption key represents a possible attack vector at the
>    protocol itself.  For this reason, servers SHOULD accept only those
>    network connection attempts that arrive from known clients.  This
>    limits the exposure and prevents remote brute force attacks from
>    unknown clients.
> 
>    Due to the security deficiencies of the protocol, it is critical that
>    it be deployed in a secure manner.  The following recommendations are
>    made for those deploying and configuring TACACS+ as a solution for
>    device administration:
> 
>       Secure the Deployment: TACACS+ MUST BE deployed over networks
>       which ensure an appropriate privacy and integrity of the
>       communication.  The way this is ensured will depend upon the
>       organizational means: a dedicated and secure management network
>       where available in enterprise deployments, or IPsec where
>       dedicated networks are not available.

JC: This dedicated and restricted network, I agree with.  This is
realistic in the vast majority (if not all) of T+ implementations.  But
this dedicated network is not necessarily secure in the IPSec sense.  I
can run a physical wire from all NASes back to my T+ server, but that
doesn't mean that the transport ensures integrity or confidentiality.

JC: My (contributor) recommendation is to say MUST to this and SHOULD to
the encrypted transport given that the latter is likely not done in the
majority of deployments today (though I'm willing to hear the argument
here).


> 
>       Do not use the TAC_PLUS_UNENCRYPTED_FLAG option.
> 
>       Always configure a secret key (recommended minimum 16 characters)
>       on the server for each client.
> 
>       Consider shared secrets to be sensitive data, and manage securely
>       on server and client.
> 
>       Change secret keys at regular intervals.
> 
>       Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS
>       options.
> 
>       Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type
>       where possible.  Use other options only when unavoidable due to
>       requirements of identity/password systems.
> 
>       Require TACACS+ authentication for authorization requests (i.e.
>       TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).
> 
>       Do not use the redirection mechanism
>       (TAC_PLUS_AUTHEN_STATUS_FOLLOW).  Specifically avoid the option to
>       send secret keys in the server list.
> 
>       Take case when applying extensions to the dictionary of
>       authorization/accounting arguments.  Ensure that the client and
>       server use of new argument names are consistent.

JC: s/client and server use of/client and server uses of/

Joe


From nobody Mon Apr 30 07:35:26 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271C127876 for ; Mon, 30 Apr 2018 07:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: does not support hash algorithm 'sha256')" header.d=ota.si
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 fzMx02JuZeHn for ; Mon, 30 Apr 2018 07:35:22 -0700 (PDT)
Received: from mta2.toshio.eu (mta2.toshio.eu [212.18.48.35]) by ietfa.amsl.com (Postfix) with ESMTP id 24E17124D37 for ; Mon, 30 Apr 2018 07:35:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mta2.toshio.eu (Postfix) with ESMTP id F2C5A16B71; Mon, 30 Apr 2018 14:35:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ota.si; h= message-id:references:content-transfer-encoding:date:date :in-reply-to:from:from:subject:subject:mime-version:content-type :content-type:received; s=toshio; t=1525098843; x=1526913244; bh=0mPw2uLByjlxWWBIZdn7zxqUl0CGSZw84zCqAtmtJZo=; b=aOEL/O9Z4APN QRaTUEu4/annU5eZ6JwQ/z1winaPZ3V63/+4KP9qqS0xbul8Qd+sDtf6cA19oZtf o+rzZexFmuzBnqYGeXg7+JgLpAtPLf2jPjT3m6xTERGlDkWVVAsfBCGOD3+ccm7K mLUGMmf/4uRfK2R0vgk93THApNfVCZw=
X-Virus-Scanned: amavisd-new at toshio.org
Received: from mta2.toshio.eu ([212.18.48.35]) by localhost (srv-fe-3.dom.ota.si [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9uugRkebNa6l; Mon, 30 Apr 2018 14:34:03 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Andrej Ota 
In-Reply-To: 
Date: Mon, 30 Apr 2018 15:33:57 +0100
Cc: Alan DeKok , "Douglas Gash (dcmgash)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm 
Content-Transfer-Encoding: quoted-printable
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>  <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com> 
To: Joe Clarke 
Message-Id: <20180430143402.EC50C16B6C@mta2.toshio.eu>
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 14:35:25 -0000

Hi Joe & opsawg,


>>> 2) Reactivity of the Authors.
>>>=20
>>> As far as I know, we have responded to most posts regarding the =
content of the document, with point-by-point replies,
>>=20
>>  No.
>>=20
>>  See the list archives, especially May 2017.  There are multiple =
people suggesting that you have *not* done this, and that you *should* =
do this.
>=20
> I for one have asked for a summary of changes when I did my last =
review.
> I did not see it.  There was a subsequent revision that did seem to
> absorb my comments, but there wasn't a response to me email.  =
Typically,
> when authors receive feedback, they respond in line to either ack or
> discuss points (typos notwithstanding).

We're still going through a year's worth of archive to locate WG =
comments and link them to changes. Currently the focus is on security =
section as that one was the most contentious, but the goal is to get =
this information out in the open.

Going forward, we've done bad and we're learning+adjusting based on all =
feedback.


>=20
>>=20
>>  See line-by-line reviews done by me, which were generally ignored.  =
Despite that, I did *multiple* such reviews, until such time as it =
became clear that such reviews were entirely unproductive.
>>=20
>>> but there has been, for various logistic reasons, long delays in =
submitting the resulting new documents. Hopefully this has been =
addresses in last versions and we will continue with more rapid uploads =
until process completes one way or other.
>>=20
>>  The issue isn't rapid uploads.  The issue is engagement.  It's not =
productive to ignore the messages on the mailing list for 6 months, and =
then to issue a new release saying "we fixed stuff".
>=20
> Spot on.  One needs to engage.  I am pleased with the authors' =
attempts
> to do better these past couple of weeks.  I want to see this momentum
> continue.

We have the next e-mail for section 9 changes almost ready and we're =
taking care to be both watching and responding on the mailing list.

>=20
>>> 3) Change Tracking
>>>=20
>>> The uploads have generally had extensive changes relating to =
comments (which should generally have been summarized by previous email =
responses to comments).=20
>>=20
>>  Which I admit did happen sometimes, but not nearly as often as it =
should have.  Again, see mailing list archives from May 2017.  I'm not =
the only person who holds this opinion.  I'm just the main one pushing =
the point.
>>=20
>>> Because of this, unless the updates have been for specific purposes =
(such as the recent update of the security section) then I would leave =
the changes to the diff tool which works pretty effectively.
>>=20
>>  The diff tool lets us know what changed in the document.  It doesn't =
let us know if those changes addressed issues raise on the mailing list.
>>=20
>>  To summarize:
>>=20
>> * we have no idea if this revision of the document addresses multiple =
WG reviews
>>=20
>> * we have no idea if the document even describes TACACS+ as currently =
implemented
>>=20
>>  As such, it should not be put into working group last call, or much =
less published until such time as those issues are addressed.
>=20
> I'm not sure what line-item changes are still outstanding.  Authors, =
I'm
> sure you could look back at your revisions and spot anything that =
needs
> to be addressed here.

We're in the process of both linking changes to where they were =
suggested from while checking that we haven't missed any.

>=20
> I will be submitting an individual review of the new security
> requirements soon, and I would like to see this renewed sense of
> engagement on the list.


You can start with e-mail I've already sent that comes with commentary =
of what we changed and for what reason. There's going to be few more =
coming in to spare you from trying to diff all by yourself and spend =
time thinking about "why" something changed.



KR, Andrej.=


From nobody Mon Apr 30 07:44:01 2018
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9122112E035 for ; Mon, 30 Apr 2018 07:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 edozv6AkQv8J for ; Mon, 30 Apr 2018 07:43:41 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A468912E76A for ; Mon, 30 Apr 2018 07:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1525099421; x=1526309021; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QPo1Zd9LcWRxxhZHALE5rmbW9CrbBc/7AXxsn80gX2Y=; b=FLLAweKMJiPTpR4hqYE35n9nTFj+rOJGyh7Khb5Yk+1ijS8nTaF8tujk 9mXGSR/ezyyIBbUBuxo3y3qUQkZONy0x6nfiI/+Z2l+57RgCUSSIbeG+I Uq02lsytFRVCslFiElc1Bof3VrYqSDkCAnsBBnJpyHdKwur1PPdHQ3Wlq M=;
X-IronPort-AV: E=Sophos;i="5.49,346,1520899200"; d="scan'208";a="106637938"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2018 14:43:41 +0000
Received: from [10.118.87.87] (rtp-jclarke-nitro6.cisco.com [10.118.87.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w3UEhejj018481; Mon, 30 Apr 2018 14:43:40 GMT
To: Andrej Ota 
Cc: Alan DeKok , "Douglas Gash (dcmgash)" , "opsawg@ietf.org" , Andrej Ota , Thorsten Dahm 
References: <152377192104.19876.15168509162131379489.idtracker@ietfa.amsl.com> <3C57BD13-BD53-4048-8975-B0BDD92F2E57@cisco.com>  <75CA4B77-5606-4C39-ACB7-F1BE0BD1962A@deployingradius.com>  <20180430143402.EC50C16B6C@mta2.toshio.eu>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: 
Date: Mon, 30 Apr 2018 10:43:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180430143402.EC50C16B6C@mta2.toshio.eu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 14:43:51 -0000

On 4/30/18 10:33, Andrej Ota wrote:
> Hi Joe & opsawg,
> 
> 
>>>> 2) Reactivity of the Authors.
>>>>
>>>> As far as I know, we have responded to most posts regarding the content of the document, with point-by-point replies,
>>>
>>>  No.
>>>
>>>  See the list archives, especially May 2017.  There are multiple people suggesting that you have *not* done this, and that you *should* do this.
>>
>> I for one have asked for a summary of changes when I did my last review.
>> I did not see it.  There was a subsequent revision that did seem to
>> absorb my comments, but there wasn't a response to me email.  Typically,
>> when authors receive feedback, they respond in line to either ack or
>> discuss points (typos notwithstanding).
> 
> We're still going through a year's worth of archive to locate WG comments and link them to changes. Currently the focus is on security section as that one was the most contentious, but the goal is to get this information out in the open.
> 
> Going forward, we've done bad and we're learning+adjusting based on all feedback.

Thank you.

> 
> 
>>
>>>
>>>  See line-by-line reviews done by me, which were generally ignored.  Despite that, I did *multiple* such reviews, until such time as it became clear that such reviews were entirely unproductive.
>>>
>>>> but there has been, for various logistic reasons, long delays in submitting the resulting new documents. Hopefully this has been addresses in last versions and we will continue with more rapid uploads until process completes one way or other.
>>>
>>>  The issue isn't rapid uploads.  The issue is engagement.  It's not productive to ignore the messages on the mailing list for 6 months, and then to issue a new release saying "we fixed stuff".
>>
>> Spot on.  One needs to engage.  I am pleased with the authors' attempts
>> to do better these past couple of weeks.  I want to see this momentum
>> continue.
> 
> We have the next e-mail for section 9 changes almost ready and we're taking care to be both watching and responding on the mailing list.

Again, thanks.

> You can start with e-mail I've already sent that comes with commentary of what we changed and for what reason. There's going to be few more coming in to spare you from trying to diff all by yourself and spend time thinking about "why" something changed.

My point was that as reviews come in, keep the discussion going.  I
realize there may be delays, but let's avoid the need to keep doing
"digest" updates moving forward.

Joe