From nobody Wed Mar 1 01:37:10 2017 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 5E15D1298BA; Wed, 1 Mar 2017 01:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, 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 kLSv-FC_gF7V; Wed, 1 Mar 2017 01:37:05 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 5EDA31298A9; Wed, 1 Mar 2017 01:37:05 -0800 (PST) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v219WQnH011014; Wed, 1 Mar 2017 01:37:04 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 28wu5er2pa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Mar 2017 01:37:03 -0800 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 02:37:00 -0700 Received: from [172.27.212.166] (172.27.212.166) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 10:36:56 +0100 To: "ipfix@ietf.org" , opsawg From: PJ Aitken Message-ID: <4b14effd-0c85-84ff-36a4-914d8cee2462@brocade.com> Date: Wed, 1 Mar 2017 09:36:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.212.166] X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703010088 Archived-At: Subject: [OPSAWG] draft-aitken-ipfix-pre-defined-templates X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:37:06 -0000 FYI, I've submitted a new draft: This document specifies a way to pre-define well-known IPFIX Templates which can be pre-shared with Collectors, thus avoiding the need for Exporters to send those Templates to Collectors. This saves export bandwidth and reduces Collector complexity. https://www.ietf.org/id/draft-aitken-ipfix-pre-defined-templates-00.txt P. From nobody Wed Mar 1 10:58:44 2017 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 AC5651297F3; Wed, 1 Mar 2017 10:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 PW13wGKNC_WS; Wed, 1 Mar 2017 10:58:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0849712966A; Wed, 1 Mar 2017 10:58:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E87401E32D; Wed, 1 Mar 2017 14:04:25 -0500 (EST) Date: Wed, 1 Mar 2017 14:04:25 -0500 From: Jeffrey Haas To: idr@ietf.org, opsawg@ietf.org Message-ID: <20170301190425.GD17448@pfrc.org> References: <001201d2865a$48899340$d99cb9c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201d2865a$48899340$d99cb9c0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [OPSAWG] [Idr] FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:58:38 -0000 [Please note I am not on the opsawg list.] On Mon, Feb 13, 2017 at 07:35:45PM -0500, Susan Hares wrote: > IDR WG: > > The OPSAWG chairs are reviewing the > draft-li-opsawg-ipfix-bgp-community-02.txt for WG adoption. Please comment > on this OPSAWG list and/or IDR list if you feel this draft should be adopted > on not adopted. I see that the draft was adopted and, as someone who previously worked on flow generators, think it's a potentially useful feature. I have a few brief comments: 1. Is there long-term intent to include other types of community data, such as extended communities or large communities? 2. The density of flow records significant impacts how quickly flow collectors are able to process the information. Unless I'm missing something, the draft doesn't seem to constrain how many communities might be able to be sent as part of the flow record as part of the community list. The authors may want to discuss mechanisms or implementations wherein the number of items in the list *might* be constrained and what to do in reporting if the list is truncated or not. 2a. When it's necessary to truncate sending some of the communities, it might be worth potentially preferring the communities in the well-known space. Knowing that a flow at a given ingress is intended to be constrained downstream may help detecting leaks when performing flow correlation in a network. Aside - 3. It's well known that flow collectors on BGP edge devices that may be distributing traffic over BGP multipaths may not even consistently report BGP data such as peer-as or origin-as for the flows traversing that multipath, despite being part of the existing flow record format. In such situations, the communities are potentially of low value. -- Jeff From nobody Thu Mar 2 07:16:09 2017 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 309C2129996; Thu, 2 Mar 2017 07:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 v57NAspoXIiN; Thu, 2 Mar 2017 07:16:04 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4587C1297F1; Thu, 2 Mar 2017 07:16:04 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 73D501E32D; Thu, 2 Mar 2017 10:21:54 -0500 (EST) Date: Thu, 2 Mar 2017 10:21:54 -0500 From: Jeffrey Haas To: "lizhenqiang@chinamobile.com" Message-ID: <20170302152153.GD24913@pfrc.org> References: <7023a95c-c6a9-4d6a-b009-8f35e447aa4e@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357F4EA@NKGEML515-MBX.china.huawei.com> <2017021611151726192539@chinamobile.com> <2017021710323644287217@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2017021710323644287217@chinamobile.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Paolo Lucente , "ipfix@ietf.org" , grow , opsawg-chairs , opsawg Subject: Re: [OPSAWG] [GROW] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:16:05 -0000 My original response to IDR and opsawg missed this thread on grow. I believe most of my concerns are covered in this thread and I don't require a separate answer. :-) On Mon, Feb 20, 2017 at 04:58:32PM +0800, lizhenqiang@chinamobile.com wrote: > Thank you for you opinion. The extended and large communities will be considered after the adoption and according to the working group consensus. FWIW, I agree with your assessment that extended communities are less likely to be important to your use case. However, large communities will very quickly become just as important. > Please see the appendix in the draft for the example. bgpDestinationCommunityList is a basicList of bgpCommunity. > > If you don't like the BGP communities according to the source IP of a specific flow, you can indicate it in the templete, i.e. do not specify bgpSourceCommunityList IE in the templete set. Then the exporter will not export the information. I do believe you'll need to figure out what to do about overflow of too many communities. As suggested in my other response, please consider prioritizing the inclusion of the well-known communities. > bgpSourceCommunityList does have values in some network environments. For example, the overalll network of China Mobile consists of a backbone network and several province networks. Each component network is configured with a few communities. BGP anounces those communities among the component networks. When one province wants to know where (i.e. from which provinces) its incoming traffic comes from, it can use bgpSourceCommunityList. However, this still causes you difficulty for BGP multipath scenarios. -- Jeff From nobody Thu Mar 2 18:53:13 2017 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 2D3AF129535; Thu, 2 Mar 2017 18:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 1nmDTk6BozQ5; Thu, 2 Mar 2017 18:53:10 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0E129461; Thu, 2 Mar 2017 18:53:08 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee758b8da8dcc2-da225; Fri, 03 Mar 2017 10:53:01 +0800 (CST) X-RM-TRANSID: 2ee758b8da8dcc2-da225 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.53.237]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee758b8da8caff-01b29; Fri, 03 Mar 2017 10:53:01 +0800 (CST) X-RM-TRANSID: 2ee758b8da8caff-01b29 Date: Fri, 3 Mar 2017 10:53:25 +0800 From: "lizhenqiang@chinamobile.com" To: opsawg , opsawg-chairs References: <76CD132C3ADEF848BD84D028D243C9279358B573@NKGEML515-MBX.china.huawei.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <2017030310532477791720@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart451306230403_=----" Archived-At: Subject: Re: [OPSAWG] IPR poll on draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:53:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart451306230403_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBXRyBDaGFpcnMgYW5kIE1lbWJlcnMsDQoNCkkgYW0gYXdhcmUgb2Ygb25lIHBhdGVudCBh cHBsaWNhdGlvbiB0aGF0IG1heSAgcmVsYXRlIHRvIHRoaXMgZHJhZnQuIFRoZSBvd25lciBvZiB0 aGUgcmVsYXRlZCBwYXRlbnQgaXMgQ2hpbmEgTW9iaWxlIHdob3NlIGxlZ2FsIGRlcGFydG1lbnQg aXMgdGFraW5nIHRoZSBwcm9jZWR1cmUgdG8gZGlzY2xvc2UuDQoNCkJlc3QgUmVnYXJkcywNCg0K DQpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgVGlhbnJhbiBaaG91DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDE3IDk6MzMg QU0NClRvOiBvcHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFtPUFNBV0ddIElQUiBwb2xsIG9uIGRy YWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAyDQogDQpEZWFyIFdHIE1lbWJlcnMs DQogDQpXZSBqdXN0IGFkb3B0ZWQgdGhlIEktRCBkcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNv bW11bml0eS0wMiBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuIFdlIHdhbnQgdG8gZG8gYW4gSVBSIHBv bGwgYXQgdGhlIGVhcmx5IHN0YWdlLg0KIA0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg YXBwbGllcyB0byBkcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMi50eHQ/IA0K IA0KSWYgeW91IG93biBvciBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhl IGRyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAyIHBsZWFzZSBjbGFyaWZ5IHdo ZXRoZXIgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp bHMpLg0KIA0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJp YnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBpbiBPUFNBV0cgbWFpbGluZyBsaXN0 IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1 bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNv bnRyaWJ1dG9yLg0KIA0KSWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250 cmlidXRvciBidXQgYXJlIG9uIE9QU0FXRyBtYWlsaW5nIGxpc3QsIHRoZW4gcGxlYXNlIGV4cGxp Y2l0bHkgcmVzcG9uZCBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQogDQpUaGFu ayB5b3UgZm9yIGtpbmQgc3VwcG9ydC4NCiANClJlZ2FyZHMsDQogDQpJZ25hcyAmIFRpYW5yYW4N CiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNB V0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= ------=_001_NextPart451306230403_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A

De= ar WG Chairs,

A time slot for 5 minutes is requested to report th= e status of draft-ietf-opsawg-ipfix-bgp-community, whi= ch was recently adopted as a working group item. The abstract of this draf= t is shown below.

Thi= s draft specifies an extension to the I= PFIX information model
   defined in = ;[RFC7012] to export the BGP community [RFC1= 997]
   information.  Three information&n= bsp;elements, bgpCommunity,
   bgpSourceCommunityLi= st and bgpDestinationCommunityList, are
  &nbs= p;introduced in this document to carry the&n= bsp;BGP community information.
   bgpCommunity= , containing exactly one BGP community value= , is used to
   consist the lis= t in bgpSourceCommunityList and
   bgpDes= tinationCommunityList, which are corresponding to = ;a specific
   flow's source IP and&= nbsp;destination IP respectively.

Best Regards,
lizhenqiang@chinamobile.com

--------------------------------------=

Tianran Zhou <zhoutianran@huawei.com> Mon, 06 March 2017 05:54 UTCShow header

<= p>

Hi WG,=0AT=
he OPSAWG meeting is scheduled on Thursday, Afternoon Session I 1300-1500,=
 according to the final agenda.=0APlease send your request to the chairs f=
or your presentation.=0ABest,=0ATianran=0A
=0A

=0A ------=_001_NextPart150081003432_=------ From nobody Wed Mar 8 07:13:17 2017 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 34CC91296BC; Wed, 8 Mar 2017 07:13:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148898599119.20220.17924779101374779420@ietfa.amsl.com> Date: Wed, 08 Mar 2017 07:13:11 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:13:11 -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 of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-05.txt Pages : 40 Date : 2017-03-08 Abstract: This memo specifies the necessary components to implement manufacturer usage descriptions (MUD). This includes two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-05 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 Wed Mar 8 07:19:06 2017 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 905B41296E8 for ; Wed, 8 Mar 2017 07:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 cysovbyKcOM7 for ; Wed, 8 Mar 2017 07:19:04 -0800 (PST) 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 226FD1296F6 for ; Wed, 8 Mar 2017 07:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3288; q=dns/txt; s=iport; t=1488986328; x=1490195928; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=jD4gtUlbva7mY9bQP7jlCUpTCFGXXSTHwQj6A0nvM6A=; b=ew9nwZIyx4/ak0OI5NE4101zWeMoOuv0mZBkvDG115ba1jVm8/CN/51H 3dZAgzn67/cufGpRDrN/ceiHHvCf+XIsTB7Yv+gnBtR9famDz50FphJxa P61p1C+5UQeyJqPKEG71YzlUoFrQWNS/2RddM/EpJGEQiUxRWTt1aep4i M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzCQBZIMBY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDJ2CDYIoMc5A6H5U4gg0fC4UuSgKCfBgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQEBAwEBIUsbCxgqAgInMBMGAgEBiXsOsCeCJop+AQEBBwEBAQEBFA+IUwiCY?= =?us-ascii?q?oMXggmCOoJfBYkkkxKDeIIJdYtCgXtThFCDMYZRkz4fOD5FIhUIFxUYJ4ZVPzW?= =?us-ascii?q?KEwEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,264,1486425600"; d="asc'?scan'208";a="650269952" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 15:18:45 +0000 Received: from [10.61.175.247] ([10.61.175.247]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v28FIjLT003967 for ; Wed, 8 Mar 2017 15:18:45 GMT References: <148898599119.20220.17924779101374779420@ietfa.amsl.com> To: opsawg@ietf.org From: Eliot Lear Message-ID: Date: Wed, 8 Mar 2017 16:18:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148898599119.20220.17924779101374779420@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HOdIItBbeE3EU8AAkqM9qCdNdf7EHhkeQ" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:19:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HOdIItBbeE3EU8AAkqM9qCdNdf7EHhkeQ Content-Type: multipart/mixed; boundary="evFiferEnrjqn2qAtLuESRbuLHEN2aaLO"; protected-headers="v1" From: Eliot Lear To: opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-05.txt References: <148898599119.20220.17924779101374779420@ietfa.amsl.com> In-Reply-To: <148898599119.20220.17924779101374779420@ietfa.amsl.com> --evFiferEnrjqn2qAtLuESRbuLHEN2aaLO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This draft contains two small changes that are necessary for the parsing, and weren't caught by nits (I also updated the changes appendix). With this I hope we are close to WGLC. Eliot On 3/8/17 4:13 PM, 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 of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-05.txt > Pages : 40 > Date : 2017-03-08 > > Abstract: > This memo specifies the necessary components to implement > manufacturer usage descriptions (MUD). This includes two YANG > modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix > specification, an X.509 certificate extension and a means to sign an= d > verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-05 > > > 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 > --evFiferEnrjqn2qAtLuESRbuLHEN2aaLO-- --HOdIItBbeE3EU8AAkqM9qCdNdf7EHhkeQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwCDVAAoJEIe2a0bZ0nozT/cIANNfJ6pMoxFBbwMJj0eMlgdh UNVdeZeE8hQeMSxF6zZ3kHygCf0kJwcSeKv7qjfOeJcXATlpHRa1osvqsU0L9SIw GBx1akd1ymIBADZnTp6NOchNCJiuGoHhL0vEjAfINSH638xso09G/1kJczMsRbuY fE0Lr2HXQA/aJ2k3UKc/B6NuFRxOaYYmoCsVi+bevZq2wsriise2RytF7PVFXlA3 YBeu4od36f4QnNoHKv10tUdrXZlKpE4LIX4vbXjOe3Z8fWUaY1sxx3B3Gm+immun SG/wuKA4BEPB2w0f0q7di0fsVlb3DZKCke+mBhW+eVKzwPcmIGrz85UHWNS+LmU= =LLam -----END PGP SIGNATURE----- --HOdIItBbeE3EU8AAkqM9qCdNdf7EHhkeQ-- From nobody Fri Mar 10 03:25:26 2017 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 376B112988A; Fri, 10 Mar 2017 03:25:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148914512620.7523.16574272216512056634@ietfa.amsl.com> Date: Fri, 10 Mar 2017 03:25:26 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-bgp-community-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 11:25:26 -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 of the IETF. Title : Export BGP community information in IP Flow Information Export (IPFIX) Authors : Zhenqiang Li Rong Gu Jie Dong Filename : draft-ietf-opsawg-ipfix-bgp-community-01.txt Pages : 11 Date : 2017-03-10 Abstract: This draft specifies an extension to the IPFIX information model defined in [RFC7012] to export the BGP community [RFC1997] information. Three information elements, bgpCommunity, bgpSourceCommunityList and bgpDestinationCommunityList, are introduced in this document to carry the BGP community information. bgpCommunity, containing exactly one BGP community value, is used to consist the list in bgpSourceCommunityList and bgpDestinationCommunityList, which are corresponding to a specific flow's source IP and destination IP respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-bgp-community-01 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 Mar 11 05:38:42 2017 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 C0A9C1294D5 for ; Sat, 11 Mar 2017 05:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.622 X-Spam-Level: X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GXl-Sb34fcfa for ; Sat, 11 Mar 2017 05:38:39 -0800 (PST) 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 F3E2A12947C for ; Sat, 11 Mar 2017 05:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1494; q=dns/txt; s=iport; t=1489239506; x=1490449106; h=to:from:subject:message-id:date:mime-version; bh=erKMIItxHV+pWsx0ekaNlp6LV5BYvGKIfTFhKLpbZK8=; b=ULCCRASgPCEEVQ04AJ8T20iEMKtqpMq4F/nBhhhtjYk4ipl+lq8FveAr U5hi1pfw68UXXtpBfoN1ZDHw6Hqslo5yfjv4BXLz7eKPnNP6lDCG6F1+c lOVsOzvAXcPMANQKVmr5sHp8MHwFs1GW/AdGx+sACSGnPbPTw5txTouyN k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbCABy/MNY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDIqhECLAaYZgg4qiHsXAQIBAQEBAQEBayiFP4EzAlMMAQwIAQGJfA6?= =?us-ascii?q?xZYImimABAQEBBgEBAQEBFAoFE4hAgmqHWoJfBZxBg3iCCYw4gWMBiG6GU5NDI?= =?us-ascii?q?QI0gQQjFggXFYcZP4ouAQEB?= X-IronPort-AV: E=Sophos;i="5.36,146,1486425600"; d="asc'?scan'208";a="653194508" 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; 11 Mar 2017 13:38:23 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2BDcNNj025912; Sat, 11 Mar 2017 13:38:23 GMT To: "opsawg@ietf.org" , mud-interest@external.cisco.com From: Eliot Lear Message-ID: <3b6f10b2-40d0-53e2-51a5-61309d378686@cisco.com> Date: Sat, 11 Mar 2017 14:38:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O2B9dcF1tk3wMUAK7vgwiHSbNwMif6hb0" X-Auto-Response-Suppress: DR, OOF, AutoReply Archived-At: Subject: [OPSAWG] new release of mudmaker X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 13:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O2B9dcF1tk3wMUAK7vgwiHSbNwMif6hb0 Content-Type: multipart/mixed; boundary="92w7hm6v9pOe8c460UkIuLhCetjxGL9s8"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" , mud-interest@external.cisco.com Message-ID: <3b6f10b2-40d0-53e2-51a5-61309d378686@cisco.com> Subject: new release of mudmaker --92w7hm6v9pOe8c460UkIuLhCetjxGL9s8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, There is a new release of mudmaker available online: https://www.ofcourseimright.com/mudmaker This one provides support for "my-controller". Eliot --92w7hm6v9pOe8c460UkIuLhCetjxGL9s8-- --O2B9dcF1tk3wMUAK7vgwiHSbNwMif6hb0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYw/3PAAoJEIe2a0bZ0nozg0AIAJCa0ar2BZFhWhkTv5SedbHp WZSfYnsFLVZt0nL5GgVnlpv+lLi7lGyaDH9hnpFDhDrOKlyfN1EryV7/5/ghCoEX HYEePKLXlWsLzMrOie5YZ0yvWWN7tWw9kfuZQFm0MLd55FYUYS19ygBV7Kf7XUDL gcEm8A12Fr34HqIX3SRjdZTnrzSl9Y7XjTNMVhFX5iH2NGfrTTqVN0wQV62oEYpF 166jGBIYFuVm729XQH7CgS7IGnSlx8yI6pFcCk2PIohA2UgitAn0Vu7ONrh4x/ya IYE08cx0Hx/FYoNn2+2a+KgAIOQ60GVEZxAsG14/bXIei7RCDMBQR8VcnE/E/Do= =tKZ7 -----END PGP SIGNATURE----- --O2B9dcF1tk3wMUAK7vgwiHSbNwMif6hb0-- From nobody Mon Mar 13 08:48:03 2017 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 92BF01296D6 for ; Mon, 13 Mar 2017 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=voltanet-io.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 iQr5-5PrXA1w for ; Mon, 13 Mar 2017 08:47:58 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 9EC5C12962D for ; Mon, 13 Mar 2017 08:47:56 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id w189so70796008pfb.0 for ; Mon, 13 Mar 2017 08:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voltanet-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sLPD3x8pQKcuoy1Aixku9mpfC86OvsJEp2yW+i1xRpE=; b=tQZYrgL/tI0Pw/xxKeTjS6maZUjV5/Srv4oOINKxdLBpCXtTHqHodiPFrD4I1vFZdV J9u01clcfuEQ24pf6QvnY9SdLnoswfP7gqSHHX7xDvCui8k4Ook1ruG6WMLek7vw7JkO RtuPHVe5xoLVnxrO3yCP4G/GOZXZbWEEdn0LgZ+Y/sBkLbIZ0FHtRZnHz0uJekF34ssm 6zHmDQF76lqHGEF5n5WEpkxJ45GOu9YcwjL053NkwEzTVd4V1266lnjJr2SaAP6gIYYP TbMJr+S4BAVhIS8ga546E2UKE+GZ6lcwek2OdISUr+CLFhCIOy+bCgWrp5fLv3sbch7p DFrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sLPD3x8pQKcuoy1Aixku9mpfC86OvsJEp2yW+i1xRpE=; b=GC8MUmvaqclatkKlavNNOqb+kuoSi15vpIzNFg1rokZUBKmVjCHD9d/6O7gt4mBU0v 2GlcaAVP0PtXNmrkjCqVaTOEDnYSl7IoLaDYrBvcQbijaDvkPrBEkrpcDFUbLc0Ez8lT KUjV+hDBW04/koNBT69i6ijq+MwCNnHYukPkfbNJSDz/roJqmtDqaHwdCvk7G4EF+rNy wKL3xhsNmcaiDzrro1W+/A3m91742Et7EM490cf88OmZ2IpVBGNcu7IrwMAlrzIpwaoF 9svfS9SJCWDaWZgzFQJR6UTwAKPFKl9VU0+YuEu+1S4oArfTiI19vGL9fommQ67qopR/ ewGg== X-Gm-Message-State: AMke39n2tFZvRE3i6RIVqSPykqKGlk+s688efO2XNnVNnn0mDUXnYioYOsYc1CT8XnDbhA== X-Received: by 10.98.156.23 with SMTP id f23mr37795449pfe.3.1489420075949; Mon, 13 Mar 2017 08:47:55 -0700 (PDT) Received: from [172.20.1.78] ([61.115.201.97]) by smtp.gmail.com with ESMTPSA id b83sm33606614pfe.12.2017.03.13.08.47.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 08:47:55 -0700 (PDT) From: Dean Bogdanovic Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 16:47:51 +0100 In-Reply-To: <032301d286ac$73fad140$5bf073c0$@olddog.co.uk> To: adrian@olddog.co.uk References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk> <4248688C-E0AC-4302-A281-0622D824FA4D@voltanet.io> <06fa01d28225$05a25050$10e6f0f0$@olddog.co.uk> <8DACB5AE-56FE-4CB1-BCBE-8D2BD214FFC0@cisco.com> <032301d286ac$73fad140$5bf073c0$@olddog.co.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: opsawg@ietf.org, "Carl Moberg \(camoberg\)" , draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org Subject: Re: [OPSAWG] [netmod] Question on draft-ietf-netmod-yang-model-classification X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:48:00 -0000 --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I just want to clarify one issue on BSS. Order management is part of the = BSS and when external customer is ordering a new service, it talks to = the order management system (either through a sales person or directly = via self ordering application). The BSS then sends request to the = provisioning system to create the service, essentially the service = orchestrator. So I would argue that BSS is exposed to the external = consumers of the service, but those systems are developed by internal = teams. I will update the draft according to some of your comments, but will = leave this for the moment in the draft and we can have a discussion on = this at the WG session or offline before or after. Dean > On Feb 14, 2017, at 11:23 AM, Adrian Farrel = wrote: >=20 > Hi Tianran, >=20 > Nice summary. >=20 > I think some of the confusion may be that = draft-ietf-netmod-yang-model-classification shows "Network Service YANG = Modules" on the interface between OSS/BSS and the network. But the = "customer service model" is at a different place in the hierarchy as = shown in Figure 4 of draft-wu-opsawg-service-model-explained. >=20 > To attend to your specific questions: >> 1. Whether it's necessary to further classify the "Network Service = YANG >> Module"? >=20 > I'm not particularly interested in doing that except so far as is = necessary to avoid conflict between the two I-Ds. In = draft-wu-opsawg-service-model-explained we introduced "customer service = module" and "service delivery module" because it seemed (to us) that = there were two different groups of people using the term "service model" = to describe very different modules. >=20 >> 2. What's the well definition of "Network Service YANG Module", = "customer >> service module", "service delivery module"? >=20 > Since draft-wu-opsawg-service-model-explained introduces the terms = "customer service module" and "service delivery module" I am going to = say that I am happy with the definitions in that document. I can say = that "customer service module" is used consistently with the L3SM and = L2SM work and so it is probably a stable definition. "Service delivery = module" is a term we invented to match the definition in = draft-wu-opsawg-service-model-explained: I don't think the term is used = anywhere else, so maybe a better question is "is this a = useful/meaningful term?" >=20 > If the answer to Q1 is that draft-wu-opsawg-service-model-explained = should not try to resolve any overlap with = draft-ietf-netmod-yang-model-classification, then I think the definition = of "Network Service YANG Module" in = draft-ietf-netmod-yang-model-classification is fine (with the few tweaks = Dean and I discussed on the list). >=20 >> 3. What's the well position of the above terms in the management = architecture? >=20 > Ah, I like that question. But it makes me ask: where should I look for = the definitive, state-of-the art management architecture? >=20 > Thanks for continuing to drive this issue. >=20 > Adrian >=20 >> -----Original Message----- >> From: Tianran Zhou [mailto:zhoutianran@huawei.com] >> Sent: 14 February 2017 09:54 >> To: Carl Moberg (camoberg); adrian@olddog.co.uk >> Cc: opsawg@ietf.org; = draft-ietf-netmod-yang-model-classification@ietf.org; >> netmod@ietf.org; Dean Bogdanovic >> Subject: RE: Question on draft-ietf-netmod-yang-model-classification >>=20 >> Hi, >>=20 >> Based on the discussion, here I try to clean up the confusion of the = two I-Ds. >>=20 >> [draft-ietf-netmod-yang-model-classification] classifies the yang = modules into >> "Network Service YANG Module" and the "Network Element YANG Module". >> And usually, it uses "service module" to imply the "Network Service = YANG >> Module", i.e., "Network" here only want to limit the scope to network = related >> modules. One example of "Network Service YANG Module" is = [draft-ietf-l3sm- >> l3vpn-service-model]. >> The authors do not want to further classify the service module into = more layers, >> until more operational practice comes. >>=20 >> [draft-wu-opsawg-service-model-explained] further classifies the = service module >> into "customer service module" and the "service delivery module". I = think this is >> based on the chair work on L3SM and L2SM WG and discussion with = operators. >> But the document think the "Network Service YANG Module" defined in = [draft- >> ietf-netmod-yang-model-classification] is "service delivery module" = not include >> the "customer service module". The = [draft-ietf-l3sm-l3vpn-service-model] is >> actually the "customer service module". >>=20 >> Here comes the question: >> 1. Whether it's necessary to further classify the "Network Service = YANG >> Module"? >> 2. What's the well definition of "Network Service YANG Module", = "customer >> service module", "service delivery module"? >> 3. What's the well position of the above terms in the management = architecture? >>=20 >> Good to see if we can solve the conflicts, these two I-Ds can = complement each >> other. >>=20 >> Best, >> Tianran >>=20 >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl = Moberg >>> (camoberg) >>> Sent: Thursday, February 09, 2017 12:48 AM >>> To: adrian@olddog.co.uk >>> Cc: opsawg@ietf.org; >>> draft-ietf-netmod-yang-model-classification@ietf.org; = netmod@ietf.org; >>> Dean Bogdanovic >>> Subject: Re: [netmod] Question on >>> draft-ietf-netmod-yang-model-classification >>>=20 >>> Team, >>>=20 >>> Inline below. >>>=20 >>>> On Feb 8, 2017, at 8:04 AM, Adrian Farrel = wrote: >>>>=20 >>>> Hi Dean, >>>>=20 >>>> I've been processing your response and the continuing thread with = you >>> and Tianran. >>>>=20 >>>>>> We've been trying to ensure that >>>>>> draft-wu-opsawg-service-model-explained is consistent with the >>>>>> latest version of draft-ietf-netmod-yang-model-classification. In >>>>>> discussions with Tianran a question has come up. >>>>>>=20 >>>>>> In section 2 you have a nice definition of Network Service YANG >>>>>> Modules and this definition maps nicely to our definition of = "service >>> delivery models". >>>>>> Furthermore, your figure 1 shows Network Service YANG Modules on = the >>>>>> interface between OSS/BSS and the various network services. >>>>>>=20 >>>>>> We have further defined "customer service models" at a higher = layer >>>>>> still. That is, on the interface to the customer. This (of = course?) >>>>>> assumes that the OSS/BSS is not customer code :-) >>>>>>=20 >>>>>> However, your discussion of Network Service YANG Modules in = section >>>>>> 2.1 seems slightly at odds, although this may be just ambiguity. >>>>>>=20 >>>>>> For example, when you say, "Network Service YANG Modules describe >>>>>> the characteristics of a service, as agreed upon with consumers = of that >>> service," >>>>>> this is not the same as, "This model is used in the discussion >>>>>> between a customer and a service provide to describe the = characteristics >>> of a service." >>>>>> That is, the former case could be arrived at after processing = based >>>>>> on the latter case - processing that we have called "service >>>>>> orchestration" but might (of course) be what leads to the = operator poking >>> the OSS/BSS. >>>>>=20 >>>>> Adrian, I can see the ambiguity. The point of service module is to = be >>>>> consumed by the customer and there can be some modifications of = the >>>>> service module to adapt to the customer specifics. >>>>=20 >>>> So far I agree with your email and therefore not with your = document. The >>> OSS/BSS is not, IMHO, a tool used by the customer. >>>>=20 >>>> Please see Figure 3 in = draft-wu-opsawg-service-model-explained-05.txt >>> that shows the customer distinct from the OSS/BSS. >>>=20 >>> IMHO figure 3 in the draft is what it says, an _example_ of a set of >>> relationships between the constituent parts of a = provisioning/activation >>> system. >>>=20 >>> In all real-world applications, customers are several layers above = the >>> =E2=80=9Cservice orchestrator=E2=80=9D and adjacent systems. But the = YANG model nevertheless >>> serves the purpose of describing the structure of the service for = customer >>> (outside the SP) or other consuming parties (e.g. the OSS/BSS = teams). >>>=20 >>>>>> This might all be fine and good, but later in the same section = you >>>>>> say "Network Service YANG Modules define service models to be >>>>>> consumed by external systems. >>>>>> These modules are commonly designed, developed and deployed by >>>>>> network infrastructure teams." And there you introduce two terms >>>>>> that are previously undefined and only server to add ambiguity. >>>>>> Specifically "external to what?" I could make and argument that = the >>>>>> OSS is developed and deployed by network infrastructure teams, ad = also >>> that the OSS is external to the network itself. >>>>>=20 >>>>> Agree that external systems are not defined and this text has to = be >>>>> clarified. The external systems can be OSS and BSS. >>>>=20 >>>> If we relabelled our "Service Delivery Model" as "Network Service = Model" >>> would that be consistent? >>>>=20 >>>> That is, in any case, to say that the OSS/BSS does not talk = directly to >>> the devices. >>>=20 >>> I think that would help. And yes, the intent of =E2=80=9Cexternal=E2=80= =9D was to say =E2=80=9Cother >>> than=E2=80=9D, rather than =E2=80=9Coutside of the company=E2=80=9D = (or something like that). >>>=20 >>>>>> And, in between these two quoted pieces of text, you have... >>>>>>=20 >>>>>> As an example, the Network Service YANG Module defined in >>>>>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>>>>> model for Layer 3 IP VPN service configuration. >>>>>=20 >>>>> My question is where do you see the L3SM model above or below OSS? >>>>=20 >>>> Well, look at the figure in section 5 of >>>> draft-ietf-l3sm-l3vpn-service-model-19.txt >>>>=20 >>>> It is logically higher, but OSS/BSS are not "in the flow" as they = are >>> legacy components in a softwarized world. >>>> However, per our pictures, OSS/BSS should use the same set of >> models/modules >>> as used by the "service orchestrator=E2=80=9D. >>>=20 >>> This is a little different in different SPs. Many of them consider = the >>> RFS-style service definition as laid out in L3SM as something that = is owned >>> by the infratrstucture and ordered through the OSS/BSS layer (the = order >>> manager to be more precise). >>>=20 >>>>> Because there are some nuances in the service module, but at the = end >>>>> we decided not to do sub classification >>>>=20 >>>> Mutter, mutter. >>>> In the document, you talk about "network service modules" not = "service >>> modules" and only trim to "service module" in the text implying that = you >>> always actually mean "network service module=E2=80=9D. >>>=20 >>> We always mean =E2=80=9Cnetwork service models=E2=80=9D, there are = many =E2=80=9Cservice models=E2=80=9D >>> out there that have little or nothing to do with the network. And I = would >>> like to not go there :-) >>>=20 >>>>> one is the business and one technical service. >>>>>=20 >>>>> When i read the YANG-Data-Model-for-L3VPN-service-delivery, it = looked >>>>> to me much more like a technical model, then the business model, = as >>>>> didn=E2=80=99t see SLA definitions to track the business = parameters of the service >>> use. >>>>=20 >>>> It is certainly not a business model and does not include SLAs. = Other >>> people have far more experience working on these things (TMF, MEF, = ...) >>> and it is not an IETF core competence. Our intention is that our = module >>> can be augmented or accompanied by other modules in order to create = a >> business >>> model, acknowledging that commercial details (even including SLAs) = will >>> vary from one operator to another, but that the core technical = description >>> of the service can be (and, it turns out, is) common across multiple >>> providers. >>>>=20 >>>> We even wrote text in Section 5 of draft-wu-opsawg-service-model- >> explained >>> to help with this. >>>>=20 >>>>>> Per my other email, this reference needs to be fixed. But I = struggle >>>>>> to see the L3SM module as consistent with your figure. It may or = may >>>>>> not be consistent with your text dependent on the interpretation. >>>>>=20 >>>>> Sure, we can fix that reference, but the authors of L3SM module >>>>> should do their own module classification, as they are the only = ones >>>>> that know the intent of the module. >>>>=20 >>>> That is fine. They can classify it, and they can use your >>>> classification system, but only if it can be understood, is >>>> meaningful, and fits what they are trying to achieve :-) >>>>=20 >>>> Your text currently says >>>> As an example, the Network Service YANG Module defined in >>>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>>> model for Layer 3 IP VPN service configuration. >>>>=20 >>>> Your text and figures show "Network Service YANG Module" as being >> something >>> that the OSS/BSS talks (presumably toward a network orchestrator?). = Thus >>> the L3SM module does not fit here. And that is why we wrote >>> draft-wu-opsawg-service-model-explained and included Figure 4 to = augment >>> your figure. >>>=20 >>> Figure 4 also seems like an _example_ of how one could structure the = layers. >>> Personally I have never seen an implementation of a clear split = between >>> "Network Service YANG Modules=E2=80=9D and "Service YANG Modules=E2=80= =9D. That=E2=80=99s why we >>> wanted to stay clear of that discussion until there is experience = telling >>> us that this is indeed best practice. >>>=20 >>>> And *finally*, Tianran is concerned that there may be confusion = arising >>> from whether the module we reference are "Network service modules", >> "service >>> delivery modules", "network configuration modules", "network element >>> modules", or "device configuration modules". So many terms, but = presumably >>> these modules don't fit into all of the categories! The list is: >>>>=20 >>>> [I-D.dhjain-bess-bgp-l3vpn-yang] >>>=20 >>> =E2=80=9C=E2=80=9D" >>> There are two parts of the BGP L3VPN yang data model. The first = part >>> of the model defines VRF specific parameters for L3VPN by = augmenting >>> the routing-instance container defined in the routing model [I- >>> D.ietf-netmod-routing-cfg] and the second part of the model = defines >>> BGP specific parameters for the L3VPN by augmenting the base BGP = data >>> model defined in [I-D.shaikh-idr-bgp-model]. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> and it=E2=80=99s importing ietf-routing, ietf-interfaces, = ietf-interfaces >>> augmenting /rt:routing/ and /if:interfaces/. >>>=20 >>> =46rom draft-ietf-netmod-yang-model-classification: >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> Network Element YANG Modules describe the characteristics of a >>> network device as defined by the vendor of that device. The = modules >>> are commonly structured around features of the device, e.g. = interface >>> configuration [RFC7223], OSPF configuration [=E2=80=A6] =E2=80=9C=E2= =80=9D" >>>=20 >>> I would say that ietf-bgp-l3vpn@2016-02-22.yang is a network element = YANG >>> module. >>>=20 >>>> [I-D.ietf-bess-l2vpn-yang] >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> In this version of the document, one single container, l2vpn, is >>> defined. Within the l2vpn container, endpoint-a, endpoint-z and a >>> list of endpoints are defined. [=E2=80=A6] >>> =E2=80=9C=E2=80=9D" >>>=20 >>> =46rom draft-ietf-netmod-yang-model-classification: >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> That is, a >>> service module does not expose the detailed configuration = parameters >>> of all participating network elements and features, but describes = an >>> abstract model that allows instances of the service to be = decomposed >>> into instance data according to the Network Element YANG Modules = of >>> the participating network elements. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> I would say that ietf-l2vpn@2016-10-24.yang is a network service = YANG >>> module. >>>=20 >>>> [I-D.ietf-bess-evpn-yang] >>>=20 >>>=20 >>> This draft contains two modules: >>> - ietf-ethernet-segment@2016-07-08.yang >>> - ietf-evpn@2016-07-08.yang >>>=20 >>> Reading the first paragraph of section 3.1 =E2=80=9COverview=E2=80=9D >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> Two top level module, Ethernet-Segment and EVPN, are defined. = The >>> Ethernet-Segment contains a list of interface to which any = Ethernet- >>> Segment attributes are configured/applied. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> =E2=80=A6and understanding that the list of interfaces can be = located on different >>> network elements, makes me think that these two modules are both = examples >>> of network device YANG modules. >>>=20 >>>> I wonder what type of module you think these are. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYxr8oAAoJEOPDsSt0S41TSScP+wXoAr4aKM/2C0vsGMcP/KkP 5LX5Had9z0Oehj+6EC7+n47f8tsQ2JJPb/dxm6SHL4G1Comy0n1W2v+QjSS+fm/G YSOkQeIn/orDEayoxNyKpJNP0MgoHgMgxSmzAVXQ6WPdMQkOv4+QKJmsFcVcrDzH mrhsCFPLNmEzgE+7F+SYbMH6BRXHwoMHzqSJAR+SQzup1I875qakj8OGd7CpXqn0 Mvzexl36xAwWPUK2+Sih2vgAfOb7p1rf6TVyJNbeT6k1rxZyOqFK5NCZrbgGM8+l p8PH7TSYR7X0Co2TES993+DW5e1/PZNt1qSStAyO/0phFXIGNylBWV8vb1AXjR35 84l3q1oVbwHYyU2FgzbT1tGP3MMrMvsgigRMOPShg15v8L2Uzyfb3u0NkP61TFSs +fD0p+S6TbB6ljzGe80bC7YN7yW05BT3T99MjAx2VotcDpIqYIwqll+rfSlOnSu3 7faZFVkua8+v8BoEbjVvinTBrLJbt66Kgpa32i0WX/YERjEubsSktDd0sJ+efTCi ZE39fA9/kxzja5/kzwe3fTpaWZB1Jr77v9fmeYkrBHTXut1Txfhzwlz4582FoHjH NM8ROkAnS6xxZJbNTAmq8RwTXzfLsoTKCSkGBwbgCsPiAEspy7KgnJLSW0GDBVNU B1k4afF9llqoHNV7XuBo =aSk5 -----END PGP SIGNATURE----- --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0-- From nobody Tue Mar 14 18:24:49 2017 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 6FA34129413; Tue, 14 Mar 2017 18:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Fv2M0Csf3wFU; Tue, 14 Mar 2017 18:24:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6B61293DA; Tue, 14 Mar 2017 18:24:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCU64148; Wed, 15 Mar 2017 01:24:41 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Mar 2017 01:24:40 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 15 Mar 2017 09:24:32 +0800 From: Tianran Zhou To: "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-opsawg-mud-05 Thread-Index: AdKdKuVOQQM7N8jQREGM9UW49sEkhw== Date: Wed, 15 Mar 2017 01:24:32 +0000 Message-ID: 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58C897D9.01AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b01370cd1171cc801e9d939355e50721 Archived-At: Subject: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 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, 15 Mar 2017 01:24:47 -0000 Dear WG Members, We are currently preparing draft-ietf-opsawg-mud-05 for working group last = call. Here is an IPR poll prior to the wglc. Are you aware of any IPR that applies to draft-ietf-opsawg-mud-05.txt?=20 If you own or are aware of any IPR that applies to the draft-ietf-opsawg-mu= d-05 please clarify whether this IPR been disclosed in compliance with IETF= IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email in OPSAWG mailing list regardless of whether or not you are aware o= f any relevant IPR. The document will not advance to the next stage until a= response has been received from each author and contributor. If you are not listed as an author or contributor but are on OPSAWG mailing= list, then please explicitly respond if you are aware of any IPR that has = not yet been disclosed in conformance with IETF rules. Thank you for kind support. Regards, Tianran / OPSAWG Co-Chair From nobody Tue Mar 14 23:07:01 2017 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 C1E541294D8; Tue, 14 Mar 2017 23:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 uMC2UvCe-_9s; Tue, 14 Mar 2017 23:06:57 -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 0665F1294D4; Tue, 14 Mar 2017 23:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1990; q=dns/txt; s=iport; t=1489558017; x=1490767617; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=HDSNoQ+HrWA5yM0A4kdMbUvdpRxqZBqrvwRXvmHb7yY=; b=gzrzgXAPYvYfIBk0c8vn1fxspgl+4LpKRZemOdza07HOGwfUNLCHV9eH s8riIh7hca5NBokd2s4sYYtZOsOnyUL18GLH7Eqsgxc8wK94RNMNVkSSo tlg1H+/gPpPd4c3ABYwlrWgxONwTjFF7bCDIjwPHCHXSV0YbDEGQFE8Qd E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAQB22MhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFyEQIoNc5Bjky2CD4IOhiICgxcYAQIBAQEBAQEBayiFFgEFI1Y?= =?us-ascii?q?QCxgqAgJXBgEMCAEBiXytcYImimABAQEBAQEBAQEBAQEBAQEBAQERD4hTgmqHW?= =?us-ascii?q?oJfBZxDg3iCCYw6gWMBiG6GU5NHHziBBCMWCBcVhxk/iWcBAQE?= X-IronPort-AV: E=Sophos;i="5.36,167,1486425600"; d="asc'?scan'208";a="653279716" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2017 06:06:54 +0000 Received: from [10.61.99.14] (dhcp-10-61-99-14.cisco.com [10.61.99.14]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2F66scn004064; Wed, 15 Mar 2017 06:06:54 GMT To: Tianran Zhou , "opsawg@ietf.org" References: Cc: "opsawg-chairs@ietf.org" From: Eliot Lear Message-ID: <34aa00dd-f811-2e42-32e1-e414a8fd37e5@cisco.com> Date: Wed, 15 Mar 2017 07:06:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="brdGNxbFL6L5jDBR7M2GqtEAD9RxTCLc8" Archived-At: Subject: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 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, 15 Mar 2017 06:06:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --brdGNxbFL6L5jDBR7M2GqtEAD9RxTCLc8 Content-Type: multipart/mixed; boundary="7kaNvlQKOv077fWmMpGG8TKq2ESmUFvgK"; protected-headers="v1" From: Eliot Lear To: Tianran Zhou , "opsawg@ietf.org" Cc: "opsawg-chairs@ietf.org" Message-ID: <34aa00dd-f811-2e42-32e1-e414a8fd37e5@cisco.com> Subject: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 References: In-Reply-To: --7kaNvlQKOv077fWmMpGG8TKq2ESmUFvgK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/15/17 2:24 AM, Tianran Zhou wrote: > Dear WG Members, > > We are currently preparing draft-ietf-opsawg-mud-05 for working group l= ast call. Here is an IPR poll prior to the wglc. > > Are you aware of any IPR that applies to draft-ietf-opsawg-mud-05.txt? = Yes. What I am aware of is disclosed according to IETF policies based on the pre-adopted version of the various drafts. Eliot --7kaNvlQKOv077fWmMpGG8TKq2ESmUFvgK-- --brdGNxbFL6L5jDBR7M2GqtEAD9RxTCLc8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYyNn9AAoJEIe2a0bZ0nozd1YH/1r8xnmGDmDwKvgGnUPUXNYN QqDEJjNR60TNNBQzNPgBRQuG3iKmvwDtWFGVFj/m0moJWyOlqOvr61d69j9ljNXq fKu47rSlNH//PA/K6cQBAKBgqrYg+TBfiohcyNVYRY3BsQLzpNxDR9UdXgRzTp/Y H7UPbslIQuULDODGdw1iwqnAqpINh1MJCC1VvCd9QWC2LGsWV8TOK/zIeUV9NgNn eDNut1KHvwkdNNeFhGwuxng1aDKDWIQvSHMKMz12OaL6CUSExB0WJuwGeS1uCwDI fA+BnUk94Kba5ByLL1ViESi04nGDlkPKgjI428eyqf7jAjdHP2QyJKk+tUn1DGI= =R3aT -----END PGP SIGNATURE----- --brdGNxbFL6L5jDBR7M2GqtEAD9RxTCLc8-- From nobody Wed Mar 15 02:10:48 2017 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 CDCAA129962 for ; Wed, 15 Mar 2017 02:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 e8yqNo4fyBgQ for ; Wed, 15 Mar 2017 02:10:46 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 495B1129968 for ; Wed, 15 Mar 2017 02:10:46 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id 1so7741398qkl.3 for ; Wed, 15 Mar 2017 02:10:46 -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=hDcStE6TX1D3Y4TkppTjWDiEeck8jqOLBELmND/Pjp0=; b=lSxGZ4PuNSHSOMCIgPIe3YHOZoBFJkv0bJZjIqzqoyU4Oqw7adDlblvNEht9eaBeTq BKP5K7d2xNQ/ZvTTBiTjRb7cOqCgmFmgwc3wTEPRcfI6HSSgTrp1+SjHRFxQFN5Bwkpk JDnxEq1VZuzjnrYvcs8C6qildF23tbFYH8D2sFpvUHNaogD5Gh7hHMSrzn/TMLNfIcSb qLzqafY0Qd2TmcHW/9l8iz5ecmD6mDEVf9FSh+Y7GKeHS2waIFHKVaZe6wfooGJLCbDt 6rbRYQaeEE71pUZqvp5VPSxMVQ/eMUADTYLfRRIeNlhar64LuAOle3H5wj++k0E58KaA Rk2Q== 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=hDcStE6TX1D3Y4TkppTjWDiEeck8jqOLBELmND/Pjp0=; b=gnEAtXdyRSu366vpQ0o0ifLCFm/mUBM595dk/Z8NGpcE0Mm+Hc8f38XWEqZWUDRXK2 MruWsyhEwHefMuDnpe4aEyUJHWSG8V9zw0giKwi/AJOt8jNC8IPqnJ9NYmiP+Qp5y+Dm Eaa8/5U52rkQlCe24CcyxbcKXBp02J5T/MKrIhmi5MLYvrmkVM8pA+UoCXtHQhYbcJcm HGeBYRCOLOnrrJPUYHLtR5ueb0jcYai80+JVpVR2Nr6cVZHfV2KRv9SftsgSOTNZ+lQ6 8Wl0X14A3Z/hBCz9dg2GMXxscEhVzXTmC90bh89KunWvgpRw8PHhljEN6sFPBxx0dqrf Sh/w== X-Gm-Message-State: AFeK/H3FtpTMGFMtZmQJzd0NUb2PTULiHRt3ullBKGW+5trbE3TCPIAa9Zn28uhxTNRzXFEGPG6GRNyVIhvGTLGm X-Received: by 10.55.41.215 with SMTP id p84mr1573870qkp.35.1489569045253; Wed, 15 Mar 2017 02:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.11 with HTTP; Wed, 15 Mar 2017 02:10:14 -0700 (PDT) In-Reply-To: <34aa00dd-f811-2e42-32e1-e414a8fd37e5@cisco.com> References: <34aa00dd-f811-2e42-32e1-e414a8fd37e5@cisco.com> From: Warren Kumari Date: Wed, 15 Mar 2017 10:10:14 +0100 Message-ID: To: Eliot Lear Cc: Tianran Zhou , "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 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, 15 Mar 2017 09:10:48 -0000 On Wed, Mar 15, 2017 at 7:06 AM, Eliot Lear wrote: > > > On 3/15/17 2:24 AM, Tianran Zhou wrote: >> Dear WG Members, >> >> We are currently preparing draft-ietf-opsawg-mud-05 for working group last call. Here is an IPR poll prior to the wglc. >> >> Are you aware of any IPR that applies to draft-ietf-opsawg-mud-05.txt? > > Yes. What I am aware of is disclosed according to IETF policies based > on the pre-adopted version of the various drafts. > Thank you. W > Eliot > -- 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 Thu Mar 16 06:13:47 2017 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 BEF2A126C23 for ; Thu, 16 Mar 2017 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 zR2SPwewx3cc for ; Thu, 16 Mar 2017 06:13:44 -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 07D8F1294B6 for ; Thu, 16 Mar 2017 06:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8934; q=dns/txt; s=iport; t=1489670024; x=1490879624; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=yBkQpWYm459D1xc5LVSsCED/sqSa9r/RK5StjKvJgzQ=; b=BNRif0SGBI1p0dEMfoHyzdYAIfwdc5i8k1W9pSxac6Nwmm1mPeh1kgow AILzrqKAiZ4ItXLR+5mmVk69nORVeYigWHiQPoZPlaCFBr9phd0MZTdpy hO5rgP9gJaj7tUEEghoR1LNxg9gEsFSggBMjlLEFAq8lsnTr68ixrg9CQ M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEBADyjspY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFxgg2GLApBGH5U/gg6GIgKDQxcBAgEBAQEBAQFrHQuFFQEBAgI?= =?us-ascii?q?BI1sLIyoCAk0KBg0GAgEBiXQIsGeCJopTAQEBAQEFAQEBAQEBEw+IUwiCYodag?= =?us-ascii?q?l8FnEWDeYIJjDyBYwEXhSiDM4ZTk00hAjSBBCMWCBcVQYZYPzWJSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="asc'?eml'208?scan'208,208";a="651492152" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 13:13:39 +0000 Received: from [10.61.99.14] (dhcp-10-61-99-14.cisco.com [10.61.99.14]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2GDDdmv011794 for ; Thu, 16 Mar 2017 13:13:39 GMT References: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> To: "opsawg@ietf.org" From: Eliot Lear X-Forwarded-Message-Id: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> Message-ID: <4f52b094-c5d8-2078-d809-b47eade21d54@cisco.com> Date: Thu, 16 Mar 2017 14:13:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h11gMxt4iEVEDUiVMIUBVA8INrHP3Q1l7" Archived-At: Subject: [OPSAWG] Fwd: Re: IPR poll on draft-ietf-opsawg-mud-05 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, 16 Mar 2017 13:13:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h11gMxt4iEVEDUiVMIUBVA8INrHP3Q1l7 Content-Type: multipart/mixed; boundary="MLEWba6PpXdwOeoSSQxQCx65D5agnJlTF"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <4f52b094-c5d8-2078-d809-b47eade21d54@cisco.com> Subject: Fwd: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 References: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> In-Reply-To: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> --MLEWba6PpXdwOeoSSQxQCx65D5agnJlTF Content-Type: multipart/mixed; boundary="------------2EBFF248F18E60832E8C2FEA" This is a multi-part message in MIME format. --------------2EBFF248F18E60832E8C2FEA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI --------------2EBFF248F18E60832E8C2FEA Content-Type: message/rfc822; name="Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05.eml" X-Mozilla-Keys: Received: from xch-aln-003.cisco.com (173.36.7.13) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Mailbox Transport; Thu, 16 Mar 2017 08:12:45 -0500 Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Mar 2017 08:12:44 -0500 Received: from alln-iport-4.cisco.com (173.37.142.91) by mail.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 16 Mar 2017 08:12:44 -0500 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 13:12:44 +0000 Received: from alln-inbound-h.cisco.com (alln-inbound-h.cisco.com [173.37.147.238]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2GDChAY017026 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK) for ; Thu, 16 Mar 2017 13:12:44 GMT Received-SPF: Pass (alln-inbound-h.cisco.com: domain of dromasca@gmail.com designates 2a00:1450:400c:c09::22f as permitted sender) identity=mailfrom; client-ip=2a00:1450:400c:c09::22f; receiver=alln-inbound-h.cisco.com; envelope-from="dromasca@gmail.com"; x-sender="dromasca@gmail.com"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-h.cisco.com: no sender authenticity information available from domain of postmaster@mail-wm0-x22f.google.com) identity=helo; client-ip=2a00:1450:400c:c09::22f; receiver=alln-inbound-h.cisco.com; envelope-from="dromasca@gmail.com"; x-sender="postmaster@mail-wm0-x22f.google.com"; x-conformance=spf_only Authentication-Results: alln-inbound-h.cisco.com; spf=Pass smtp.mailfrom=dromasca@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-x22f.google.com; dkim=pass (signature verified) header.i=@gmail.com; dmarc=pass (p=none dis=none) d=gmail.com X-from-outside-Cisco: 2a00:1450:400c:c09::22f IronPort-PHdr: =?us-ascii?q?9a23=3ALgD8xR+EREud3f9uRHKM819IXTAuvvDOBiVQ1KB+?= =?us-ascii?q?2+0cTK2v8tzYMVDF4r011RmSAtWdtqoMotGVmp6jcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47WLmffqXyq7DMUBg63dU8s?= =?us-ascii?q?fry0ScbuiJGa0+G159X3bgxSzG65bLpoBB63tg7W8MIRhN0xBLw2z07lq30AQe?= =?us-ascii?q?NTzHhjLFSO10Lw/MC19YVo+gxfvvsg84hLVqCsLPdwdqBREDlzazN938bsrxSW?= =?us-ascii?q?CFLXvnY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8GDAABMjspYfVAUACqEgLCYCQCEL14aA?= =?us-ascii?q?QEBAQIBAQEBCAEBAQEUAQEBAQEBAQEBAQEHAQEBAQGCZIEYgRWfSIh+jgxDhiK?= =?us-ascii?q?DBUIVAQEBAQEBAQEBAQECEAEBCRYIV4IzBAEdAQQIRikvAQEBAQEBAQEBAR8CK?= =?us-ascii?q?yUBARgBAQICOwYBGx0BAwERBQsNUREBBQEiE4lnAQMIBQkDpB0/jgcFARyDCQW?= =?us-ascii?q?DYAoZJw1VgjkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAgYJAQiGPIIFgmqEVIM0g?= =?us-ascii?q?jEFkFmLbJI+gWMBF4UogyQPhlOPF4JuM4EVNYEnOR8VQREBBYIvggKCHGiHeYF?= =?us-ascii?q?PAQEB?= X-IPAS-Result: =?us-ascii?q?A8GDAABMjspYfVAUACqEgLCYCQCEL14aAQEBAQIBAQEBCAE?= =?us-ascii?q?BAQEUAQEBAQEBAQEBAQEHAQEBAQGCZIEYgRWfSIh+jgxDhiKDBUIVAQEBAQEBA?= =?us-ascii?q?QEBAQECEAEBCRYIV4IzBAEdAQQIRikvAQEBAQEBAQEBAR8CKyUBARgBAQICOwY?= =?us-ascii?q?BGx0BAwERBQsNUREBBQEiE4lnAQMIBQkDpB0/jgcFARyDCQWDYAoZJw1VgjkBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEVAgYJAQiGPIIFgmqEVIM0gjEFkFmLbJI+gWM?= =?us-ascii?q?BF4UogyQPhlOPF4JuM4EVNYEnOR8VQREBBYIvggKCHGiHeYFPAQEB?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="scan'208";a="278950003" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail-wm0-x22f.google.com ([IPv6:2a00:1450:400c:c09::22f]) by alln-inbound-h.cisco.com with ESMTP/TLS/AES128-GCM-SHA256; 16 Mar 2017 13:12:43 +0000 Received: by mail-wm0-x22f.google.com with SMTP id u132so34793386wmg.0 for ; Thu, 16 Mar 2017 06:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:content-transfer-encoding:from:message-id:date:cc:to :mime-version; bh=fRcos7giLsTo5Jcz7VfsutOKvJDWkeCBcI6kDerTbc8=; b=pUaSjQiTWdUY9V9VuZEAI0m5vUg/aO3qIqQo06G7Zp+nPg5ohPtohBZhvKPJ+v1aDk S8xjtyaFxoagh5xGiL37TQ0xHeSMRD5YA8Urmn5SJ6MdJkxTzPmEHFjcLNrQcivVQzUV ZiCO6hjAaq+yICbD05MIAIeW9FlQrdjp7FxLfBJVdjyFGoYdjyzvN9Rq41fBKetwS7BS GOA+J5tasDso2GsmucL4hZOyz5F4pKMkrDDpl6TOjBsTKfxK/23GBF0cRrwBUGOe0Xs/ 8Z92atgZGVSJ8hniKX3N3DDA7g963UOpEaHGbGGcrHQ0tZNMPPWR9+aS28ZiD3I6z3kD RXAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:content-transfer-encoding:from :message-id:date:cc:to:mime-version; bh=fRcos7giLsTo5Jcz7VfsutOKvJDWkeCBcI6kDerTbc8=; b=lwJgmzpZOKcULZzyNlperQHj01cQoo/sMHlK3NHplHVzgNeDUyixDVhuZxYEIsjvmv 8+/Qgt/e3GXvLYhit/dNbXVT19GUzMJDUGtxBYudyxudTNjexoOfMUSaw/TMhjO0MVvR dtxSQTA4lVtYgHyVibFUUFE3J63grtwRWxZaVCNNe7JKzG7cbwRrVcOCv5/sl3xvZIm/ ur33Lo7FWDCCIc2QN0go+ja+aKanHMlVroizNrLHgQEj8+EfYAHVgqGHll19VaVxq2yB Ff04zplFGbRG3BeNqjUGnc+p+ztvtgWREJIYNcLMm6t4wfiNLqktGBRiFkEicsD+DfJl PIww== X-Gm-Message-State: AFeK/H0z54PGFTdgtYTaW65+oHWp8/uMynx9FsySawEf5keevUEpaiJrTyANwhQaw1bcwQ== X-Received: by 10.28.24.6 with SMTP id 6mr8203284wmy.142.1489669962130; Thu, 16 Mar 2017 06:12:42 -0700 (PDT) Received: from [10.160.242.222] ([109.253.222.50]) by smtp.gmail.com with ESMTPSA id u11sm6185898wrb.45.2017.03.16.06.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 06:12:41 -0700 (PDT) Subject: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 Content-Transfer-Encoding: quoted-printable From: Dan Romascanu Content-Type: text/plain; charset="us-ascii" X-Mailer: iPhone Mail (14D27) Message-ID: <9F138C05-D5E0-458E-8CA0-1B9400796E46@gmail.com> Date: Thu, 16 Mar 2017 21:12:36 +0800 Cc: "Romascanu, Dan (Dan)" , Ralph Droms To: Eliot Lear Return-Path: dromasca@gmail.com X-MS-Exchange-Organization-AuthSource: XCH-RCD-005.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: fa88c9e5-1fbf-4337-0943-08d46c6e2285 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 Sorry, I was traveling at the antipodes and I missed this message. I am not= aware about any IPR related to the MUD work. Please forward back to WG lis= t, as I do not have the original. Regards, Dan Sent from my iPhone > On 15 Mar 2017, at 14:25, Eliot Lear wrote: >=20 > pls to answer when you have a moment. >=20 > <[OPSAWG] IPR poll on draft-ietf-opsawg-mud-05.eml> --------------2EBFF248F18E60832E8C2FEA-- --MLEWba6PpXdwOeoSSQxQCx65D5agnJlTF-- --h11gMxt4iEVEDUiVMIUBVA8INrHP3Q1l7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYyo+DAAoJEIe2a0bZ0nozIloIALWcy2YeLvmVlntETdrU83z+ 0CGBCtBHheN1l4+YnA3PTeXfNTiHzIk1517USV3sBIDl31bSVm6c+zRVrNfbfJCN l3k8XvVaulkVIjsqoxlb8y6G7Etm3gxeRsdQCjWD6oLbKp8vw2XF3sIjTgQ9+rH2 aFIQKkPB8YUVp32wT+TkpmtA3QhxfWj+MbqIbzKU/p4nKiGfSyj3al0CgByW4cWb acEYQuue/6xUCnaZJWkZBbIMAXRfiYtZPr897K0QCpllcoxci9Jt5kXdFno8zfD9 nAAJqz+V5xoYS5TZZkB2/fXp5ZTXSIEEP/kRQ/cPIEJhuTtVx3XrXbZcqd64juo= =Jpdx -----END PGP SIGNATURE----- --h11gMxt4iEVEDUiVMIUBVA8INrHP3Q1l7-- From nobody Thu Mar 16 06:25:05 2017 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 4695D1294E0; Thu, 16 Mar 2017 06:25:03 -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 5YJ1x8IsQPAM; Thu, 16 Mar 2017 06:25:01 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 292DE1294D1; Thu, 16 Mar 2017 06:25:01 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id i34so37274830qtc.0; Thu, 16 Mar 2017 06:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RjKtEzFTsGoj0HeGv/yh0/zr2yh4cqOijLPX31adHfU=; b=SFmw0nqgdtSYjymoEIiWWv99XcC10NjnzwrCNM1ycTcWTxI7ocvwfQp8TJTyJHvTol yA03f5EoUWaLsk+j47fTWEaYk8cp+7bRz0m9EfHAUAtt+uN9Zn7bnWRwbCLL2I5Bmc3f 1H8eWgCVjX7r+3zM2c3pCgwm3qwYyouc7Y2Bg0XH+d3kscPMqEvpvfDq7awJTojtyOEU F7+sNoQbp4ogzSB6FKjCvYN/EZevVr/KuYCf5Qu76n2oIblmlUI39KgU70RhqggBUtjf Tj/gmcDT2Quq5ZWNQ3OMPkCHlcI8dTC5lQcH167YWVPlNmnPlTQ9J9RwxdJ7UQ0FgmEz Y8DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RjKtEzFTsGoj0HeGv/yh0/zr2yh4cqOijLPX31adHfU=; b=qomil5AP+bWVg+d9OG8E45gUggm4BWB49+2OWrHebDsVYRaC37ueUBFkZhfc/gQKae +zCNAxWRMqMcqpssjdY/avn7nPW9YgMoj2HXwTslI7afc2ff3KD3Ph2xZ+YonVNeBUdG T1c6UrSC6zqBVDde/67Y/WW/gY1WHMV+MWnf9llk6sA0hMTY162uLbszWc2r2BEKveEj upYocz/NZWPUYhhH2x7xm4npbYBtXWoVaJ/9euLgRBOt1/7Eicij2ozA4O9HTBauSY6j n3I9PcpWjbul5ZGCcZMWX5huTvi051SYdP0DEQLB1jqo94OcoZbvNKkwQ91EPWDoKHK+ FtpQ== X-Gm-Message-State: AFeK/H3uFbNUnnyzOwNwHBdEskbEqNJ57JMPOcjqBb26YOh8qww6EqXyL+Im9BoFX8190Q== X-Received: by 10.200.0.25 with SMTP id a25mr7605004qtg.199.1489670700213; Thu, 16 Mar 2017 06:25:00 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:50fe:ca08:ce27:17bc? ([2601:18f:801:600:50fe:ca08:ce27:17bc]) by smtp.gmail.com with ESMTPSA id 14sm2861362qtp.29.2017.03.16.06.24.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 06:24:59 -0700 (PDT) From: Ralph Droms Message-Id: <3C186480-4E25-4346-A981-59EAFA4BE255@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_43F98ECB-9CDF-4626-824C-4ADD71E2A229" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Mar 2017 09:24:52 -0400 In-Reply-To: <5f893178-dcfc-1881-99d2-3fdc7eaeccb1@cisco.com> Cc: "Romascanu, Dan (Dan)" , Eliot Lear , "opsawg-chairs@ietf.org" To: "opsawg@ietf.org" References: <5f893178-dcfc-1881-99d2-3fdc7eaeccb1@cisco.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 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, 16 Mar 2017 13:25:03 -0000 --Apple-Mail=_43F98ECB-9CDF-4626-824C-4ADD71E2A229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not personally aware of any IPR claims that apply to = draft-ietf-opsawg-mud-05.txt. - Ralph >=20 > From: Tianran Zhou > Subject: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05 > Date: March 14, 2017 at 9:24:32 PM EDT > To: "opsawg@ietf.org" > Cc: "opsawg-chairs@ietf.org" >=20 >=20 > Dear WG Members, >=20 > We are currently preparing draft-ietf-opsawg-mud-05 for working group = last call. Here is an IPR poll prior to the wglc. >=20 > Are you aware of any IPR that applies to draft-ietf-opsawg-mud-05.txt?=20= >=20 > If you own or are aware of any IPR that applies to the = draft-ietf-opsawg-mud-05 please clarify whether this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details). >=20 > If you are listed as a document author or contributor please respond = to this email in OPSAWG mailing list regardless of whether or not you = are aware of any relevant IPR. The document will not advance to the next = stage until a response has been received from each author and = contributor. >=20 > If you are not listed as an author or contributor but are on OPSAWG = mailing list, then please explicitly respond if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. >=20 > Thank you for kind support. >=20 > Regards, > Tianran / OPSAWG Co-Chair >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 >=20 --Apple-Mail=_43F98ECB-9CDF-4626-824C-4ADD71E2A229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am not personally aware of any IPR claims that apply to = draft-ietf-opsawg-mud-05.txt.

- Ralph


From: Tianran Zhou <zhoutianran@huawei.com>
Subject: = [OPSAWG] IPR poll = on draft-ietf-opsawg-mud-05
Date: = March 14, 2017 at 9:24:32 PM = EDT
To: = "opsawg@ietf.org" <opsawg@ietf.org>
Cc: = "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>


Dear WG Members,

We= are currently preparing draft-ietf-opsawg-mud-05 for working group last = call. Here is an IPR poll prior to the wglc.

Are you aware of any IPR that applies to = draft-ietf-opsawg-mud-05.txt?

If you own = or are aware of any IPR that applies to the draft-ietf-opsawg-mud-05 = please clarify whether this IPR been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or = contributor please respond to this email in OPSAWG mailing list = regardless of whether or not you are aware of any relevant IPR. The = document will not advance to the next stage until a response has been = received from each author and contributor.

If= you are not listed as an author or contributor but are on OPSAWG = mailing list, then please explicitly respond if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules.

Thank you for kind support.

Regards,
Tianran / OPSAWG Co-Chair

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg




= --Apple-Mail=_43F98ECB-9CDF-4626-824C-4ADD71E2A229-- From nobody Thu Mar 16 22:59:11 2017 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 E36761201F2 for ; Thu, 16 Mar 2017 22:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 IGKsfSVDKieQ for ; Thu, 16 Mar 2017 22:59:07 -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 2744E127F0E for ; Thu, 16 Mar 2017 22:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1489730347; x=1490939947; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uv1NvIGGGBJkU6q6hBEaNrrpUEK5Nf+aL8//XTpZk3o=; b=aVKDo+cxKd9GR6YmnLRwxX4N13BxYmQeEpl1fiwSWDkT1GSKtM3xIE1o sWjwk4fYDBjn8GKIMUVvELWfRYSq9ZF2FvXnRqqOQ5T4jWjKjSBIzcbu2 89olNn8oWScWv8iS1MFQEQFYUXD1mK/A8ODsCb0JFixrNHNPeF7qLu7Aq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCIestY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWqnF4IOLIV2AoMHPxgBAgEBAQEBAQFrHQuFFgMDOi0?= =?us-ascii?q?KBgIQAgEINhAyGwEGAwIEDgUUB4llDrNZilIBAQEBAQEBAQIBAQEBAQEBAQEBH?= =?us-ascii?q?os9gxeHIgWPW4xqAYZ2i0eBe1SEVIoGk0wBHziBBFgVGIcAdYhKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,175,1486425600"; d="scan'208";a="219318028" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Mar 2017 05:59:06 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2H5x6mn004959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2017 05:59:06 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Mar 2017 00:59:05 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 17 Mar 2017 00:59:05 -0500 From: "Byju Pularikkal (byjupg)" To: "opsawg@ietf.org" CC: "Sri Gundavelli (sgundave)" , Tommy Pauly Thread-Topic: New Version Notification for draft-pularikkal-opsawg-wifi-calling-02.txt Thread-Index: AQHSjueFgU7g3QyVJU6Tk6GNH/Ovs6GYiEgA Date: Fri, 17 Mar 2017 05:59:05 +0000 Message-ID: References: <148797281462.3167.18126508069542557298.idtracker@ietfa.amsl.com> In-Reply-To: <148797281462.3167.18126508069542557298.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <4918E6AA795BF844A158CBAD71FC7B78@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] FW: New Version Notification for draft-pularikkal-opsawg-wifi-calling-02.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: Fri, 17 Mar 2017 05:59:10 -0000 Dear working group members, Kindly request some feedback from the community on the following work item. This covers deployment scenarios and some best practice recommendations for Carrier Wi-Fi calling. We do see lot of relevance in the industry on this topic, as many mobile carriers have deployed the solution and it is also triggering partnerships between Mobile Carriers and Wi-Fi Service Providers. Appreciate your time in reviewing this and providing some feedback on the content prior to IETF 98 Regards Byju On 2/24/17, 1:46 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-pularikkal-opsawg-wifi-calling-02.txt >has been successfully submitted by Byju Pularikkal and posted to the >IETF repository. > >Name: draft-pularikkal-opsawg-wifi-calling >Revision: 02 >Title: Carrier Wi-Fi Calling Deployment Considerations >Document date: 2017-02-24 >Group: Individual Submission >Pages: 26 >URL: =20 >https://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-wifi-calling- >02.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-pularikkal-opsawg-wifi-calling/ >Htmlized: =20 >https://tools.ietf.org/html/draft-pularikkal-opsawg-wifi-calling-02 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-pularikkal-opsawg-wifi-calling-0= 2 > >Abstract: > Carrier Wi-Fi Calling is a solution that allows mobile operators to > seamlessly offload mobile voice signaling and bearer traffic onto Wi- > Fi access networks, which may or may not be managed by the mobile > operators. Mobile data offload onto Wi-Fi access networks has > already become very common, as Wi-Fi access has become more > ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi > networks has become prevalent only in recent years. This was > primarily driven by the native Wi-Fi Calling client support > introduced by device vendors. The objective of this document is to > provide a high level deployment reference to Mobile Operators and Wi- > Fi Operators on Carrier Wi-Fi Calling. > > =20 > =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. > >The IETF Secretariat > From nobody Fri Mar 17 01:17:53 2017 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 DF1E3126B71; Fri, 17 Mar 2017 01:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 vEdi9hNHHrWZ; Fri, 17 Mar 2017 01:17:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B898E124D68; Fri, 17 Mar 2017 01:17:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCY40857; Fri, 17 Mar 2017 08:17:46 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 17 Mar 2017 08:17:45 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 17 Mar 2017 16:17:37 +0800 From: Tianran Zhou To: "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-mud-05 Thread-Index: AdKe9vAgYqk7rVgYSsewZPAvl6ONiA== Date: Fri, 17 Mar 2017 08:17:37 +0000 Message-ID: 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58CB9BAA.0198, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4cb3ca0f812989bb5ef5785b758eb43c Archived-At: Subject: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 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, 17 Mar 2017 08:17:52 -0000 Dear OPSAWG, This is a notice to start a two-week OPSAWG WG last call for the document: Manufacturer Usage Description Specification https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ Please read the above draft and send any issues, comments, or corrections t= o this mailing list. Please indicate your support or concerns by Friday March 31, 2017. Thanks, Chairs From nobody Fri Mar 17 07:49:29 2017 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 E4C9612947C; Fri, 17 Mar 2017 07:49:22 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148976216292.14157.12162592904313869929@ietfa.amsl.com> Date: Fri, 17 Mar 2017 07:49:22 -0700 Archived-At: Subject: [OPSAWG] IPR Disclosure China Mobile Communications Corporation's Statement about IPR related to draft-li-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: Fri, 17 Mar 2017 14:49:23 -0000 Dear Rong Gu, Zhenqiang Li, Jie Dong: An IPR disclosure that pertains to your Internet-Draft entitled "Export BGP community information in IP Flow Information Export (IPFIX)" (draft-li-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/2964/). The title of the IPR disclosure is "China Mobile Communications Corporation's Statement about IPR related to draft-li-opsawg-ipfix-bgp-community" Thank you IETF Secretariat From nobody Sun Mar 19 18:08:23 2017 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 E850412943B for ; Sun, 19 Mar 2017 18:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 grF3QDsXchvC for ; Sun, 19 Mar 2017 18:08:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D37129439 for ; Sun, 19 Mar 2017 18:08:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJE58221; Mon, 20 Mar 2017 01:08:16 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Mar 2017 01:08:16 +0000 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.0235.001; Mon, 20 Mar 2017 09:08:09 +0800 From: Tianran Zhou To: "opsawg@ietf.org" Thread-Topic: OPSAWG meeting agenda posted Thread-Index: AdKhFnA1ONDlXubdTOO5ZzxpRz0TSg== Date: Mon, 20 Mar 2017 01:08:08 +0000 Message-ID: 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58CF2B81.0091, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: da3d215d315363f59fbc219ec1a9a2ca Archived-At: Subject: [OPSAWG] OPSAWG meeting agenda posted 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, 20 Mar 2017 01:08:22 -0000 Hi WG, The OPSAWG meeting is at 13:00-15:00 Thursday Afternoon session I, March 30= , 2017. The meeting agenda is posted according to the applications. https://www.ietf.org/proceedings/98/agenda/agenda-98-opsawg-00 The speakers please send over your slides to the chairs. Thanks, Tianran From nobody Thu Mar 23 12:23:35 2017 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 3BDD1131639 for ; Thu, 23 Mar 2017 12:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 xmUG6yiTcZ4m for ; Thu, 23 Mar 2017 12:23:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7365131635 for ; Thu, 23 Mar 2017 12:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1490296998; x=1491506598; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=suDUr0Dw/0jVzbCIJ6zO2KNQlJQyBNRgkmM2QnMP+EM=; b=aYbhQo+vT9S1kbuEqQwkrMEVx/7ybCaZnIyX8b8x8Py+4vXTlQDl4mcl jT6kQYTmJbzcDpdjkd+qTaVwiC8wKph05rs1jR4jetas0rP4gddHSXESU BkjfCgocBTZ1HH4Ts606lcIW6Tsdrp4m3ykoT3kj1CR34eoe8WLrXzkaM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgD8H9RY/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqYYESg1uKD5EwlWiCDiqFeByCfT8YAQIBAQEBAQEBax0LhRY?= =?us-ascii?q?GHQYROgsSAQgaAiYCBDAVEgQOigsOqjyCJopEAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWBC4dICIJih1ougjEFiSiGNox3AYZ6hlCEf4F7GIUSg1eGM5NhAR84gQR?= =?us-ascii?q?ZFUERAYZGiEMrgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,211,1486425600"; d="scan'208";a="402117521" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2017 19:23:17 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2NJNHYb022826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Mar 2017 19:23:17 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 14:23:17 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Thu, 23 Mar 2017 14:23:17 -0500 From: "Max Pritikin (pritikin)" To: "opsawg@ietf.org" CC: "Eliot Lear (elear)" Thread-Topic: WG LC for draft-ietf-opsawg-mud-05 Thread-Index: AQHSpArsNCNn2YcKPUWtkDOh8HfKZw== Date: Thu, 23 Mar 2017 19:23:17 +0000 Message-ID: <74D7430F-5B42-4857-A49A-AD4AA1845516@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 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, 23 Mar 2017 19:23:23 -0000 DQpGb2xrcywgDQoNCkkgc3VwcG9ydCB0aGlzIGRvY3VtZW50LiBJIGhhdmUgdGhlIGZvbGxvd2lu ZyBjb25jZXJucywNCg0KMSkgQSBNVUQgZmlsZSBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgZXhw ZWN0ZWQgTVVEIFVSTCBlbWlzc2lvbiBtZXRob2QgaXMgb2Ygc2VjdXJpdHkgdmFsdWUuDQoNCkRp c2N1c3Npb246DQpTZWN0aW9uIDEuMyBpbmRpY2F0ZXMgInRocmVlIG1lYW5zIGFyZSBkZWZpbmVk IHRvIGVtaXQgdGhlIE1VRCBVUkzigJ0gd2hpY2ggaW5jbHVkaW5nIHVuc2VjdXJlZCBtb2Rlcy4g VGhpcyBpbnRyb2R1Y2VzIHRoZSBwb3NzaWJpbGl0eSBvZiBhIGF0dGFjayB3aGVyZWluIGFuIGlu Y29ycmVjdCBNVUQgVVJMIGlzIHJlY2VpdmVkLiBUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgd2hlcmUgaXQgaXMgY3VycmVudGx5IHJlY29tbWVuZGVkIHRo YXQgImRldmljZXMgdGhhdCBwcmVzZW50IHNvbWUgZm9ybSBvZiB1bmF1dGhlbnRpY2F0ZWQgTVVE IFVSTCBTSE9VTEQgYmUgdmFsaWRhdGVkIGJ5IHNvbWUgZXh0ZXJuYWwgbWVhbnPigJ0uIEEgdXNl ZnVsIGV4dGVybmFsIG1lYW5zIGZvciBkZXRlY3Rpbmcgc3VjaCBhdHRhY2tzIHdvdWxkIGJlIGZv ciB0aGUgTVVEIFlBTkcgTW9kZWwgdG8gaW5jbHVkZSBhIHVzYWdlIGRlc2NyaXB0aW9uIG9mIHRo ZSBtZWFucyBleHBlY3RlZCBieSB0aGUgZGV2aWNlOg0KDQoodGhpcyBpcyBqdXN0IGFuIGV4YW1w bGUsIGFyZ3VhYmx5IGEgbGlzdCBvZiB0aGVzZSB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpbiBjYXNl IGRldmljZSBjYW4gdXNlIG11bHRpcGxlIG1ldGhvZHMpDQoNCiAgdHlwZWRlZiBtdWQtdXJsLWVt aXNzaW9uLW1vZGVzIHsNCiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgICBlbnVtIHZp YURIQ1Atb3B0aW9uIHsNCiAgICAgICAgICAgZGVzY3JpcHRpb24g4oCcVGhlIGRldmljZSBlbWl0 cyBNVUQgVVJMcyB1c2luZyBESENQIG9wdGlvbnMiOw0KICAgICAgICAgfQ0KICAgICAgICAgZW51 bSB2aWFYNTA5SURldklEIHsNCiAgICAgICAgICAgZGVzY3JpcHRpb24g4oCcVGhlIGRldmljZSBl bWl0cyBNVUQgVVJMcyBieSBhdXRoZW50aWNhdGluZyB1c2luZyBhbiBtYW51ZmFjdHVyZXIgaW5z dGFsbGVkIFguNTA5IGNlcnRpZmljYXRlIjsNCiAgICAgICAgICAgfQ0KICAgICAgICAgZW51bSB2 aWFMTERQZnJhbWUgew0KICAgICAgICAgICBkZXNjcmlwdGlvbiDigJxUaGUgZGV2aWNlIGVtaXRz IE1VRCBVUkxzIGJ5IGF1dGhlbnRpY2F0aW5nIHVzaW5nIGFuIG1hbnVmYWN0dXJlciBpbnN0YWxs ZWQgWC41MDkgY2VydGlmaWNhdGUiOw0KICAgICAgICAgICB9DQogICAgICAgICB9DQogICAgIGRl c2NyaXB0aW9uIOKAnE1hbnVmYWN0dXJlciB1c2FnZSBkZXNjcmlwdGlvbiBvZiBNVUQgVVJMIGVt aXNzaW9uIG1ldGhvZHMgZnJvbSB0aGlzIHR5cGUgb2YgZGV2aWNlIChzZWUgc2VjdGlvbiAxLjMp IjsNCiAgfQ0KDQoNCjIpIEFzIGV4dGVuc2lvbnMgYXJlIGFkZGVkIHRvIE1VRCBmaWxlcyB0byBj b3ZlciBhZGRpdGlvbmFsIHVzYWdlIGRlc2NyaXB0aW9ucyBmb3IgZGV2aWNlcyBpdCB3b3VsZCBi ZSB1c2VmdWwgZm9yIGRldmVsb3BlcnMgYW5kIGZ1dHVyZSB3b3JrIHRvIHJlZmVyIHRvIGFuIElB TkEgbmFtZSByZWdpc3RyeSBkZWZpbmluZyBlYWNoIGV4dGVuc2lvbi4gQXMgc3VjaCBhbiBJQU5B IG5hbWUgcmVnaXN0cnkgZm9yIE1VRCDigJx1c2FnZSBkZXNjcmlwdGlvbnPigJ0gaXMgc3VnZ2Vz dGVkLiANCg0KMykgLndlbGwta25vd24gaXMgbWFuZGF0ZWQgdGhlcmVmb3JlIFJGQzU3ODUgc2hv dWxkIGJlIGluY2x1ZGVkIGluIHRoZSByZWZlcmVuY2VzLg0KDQpJ4oCZbSBvZiB0aGUgb3Bpbmlv biB0aGF0IHRoZSBzZWN0aW9uIDEwICjigJxNVUQgVVJMIFguNTA5IEV4dGVuc2lvbuKAnSkgc2hv dWxkIGRlZmluZSBhIGdlbmVyYWwgcHVycG9zZSBleHRlbnNpb24gZm9yIGltcGFydGluZyB0aGUg bWFudWZhY3R1cmVyIOKAmGF1dGhvcml0eeKAmSBwb3J0aW9uIG9mIHRoZSBVUkkuIEEgbmV3IG9u ZS1vZmYgYXV0aG9yaXR5IGluZm9ybWF0aW9uIHN0YXRlbWVudCB3aXRoaW4gWC41MDkgY3JlZGVu dGlhbHMgaXMgbGVzcyB0aGFuIGlkZWFsLiBTaW5jZSB0aGUgZmluYWwgTVVEIFVSSSBjb250YWlu cyB0aGUgbW9kZWwgaW5mb3JtYXRpb24gSSBzdWdnZXN0IFJGQzQxMDggSGFyZHdhcmVNb2R1bGVO YW0gaHdUeXBlIGJlIHVzZWQgdG8gY29tbXVuaWNhdGUgdGhlIOKAmG1vZGVsJy4gVGhpcyBhbGxv d3MgdGhlIE1VRCBVUkkgdG8gYmUgYnVpbGQgZHluYW1pY2FsbHkgYW5kIGFsbG93cyB0aGUgbmV3 IGV4dGVuc2lvbiB0byBiZSBsZXZlcmFnZWQgYnkgZnV0dXJlIHdvcmsgdGhhdCB3aXNoZXMgdG8g cmVmZXJlbmNlIG90aGVyIC53ZWxsLWtub3duIGluZm9ybWF0aW9uIGF0IHRoZSBhdXRob3JpdHku IEkgdW5kZXJzdGFuZCBpZiB0aGlzIHN1Z2dlc3Rpb24gaXMgbm90IGFjdGVkIG9uLg0KDQotIG1h eA0KDQpyZToNCj4gRGVhciBPUFNBV0csDQo+IA0KPiBUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0 IGEgdHdvLXdlZWsgT1BTQVdHIFdHIGxhc3QgY2FsbCBmb3IgdGhlIGRvY3VtZW50Og0KPiANCj4g TWFudWZhY3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uIFNwZWNpZmljYXRpb24NCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLw0KPiANCj4gUGxl YXNlIHJlYWQgdGhlIGFib3ZlIGRyYWZ0IGFuZCBzZW5kIGFueSBpc3N1ZXMsIGNvbW1lbnRzLCBv ciBjb3JyZWN0aW9ucyB0byB0aGlzIG1haWxpbmcgbGlzdC4NCj4gUGxlYXNlIGluZGljYXRlIHlv dXIgc3VwcG9ydCBvciBjb25jZXJucyBieSBGcmlkYXkgTWFyY2ggMzEsIDIwMTcuDQo+IA0KPiBU aGFua3MsDQo+IENoYWlycw0KPiANCj4gDQo= From nobody Mon Mar 27 06:56:42 2017 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 0E97912783A; Mon, 27 Mar 2017 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 VI0J-VDdRHjC; Mon, 27 Mar 2017 06:56:39 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0129.outbound.protection.outlook.com [23.103.201.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B9A128C83; Mon, 27 Mar 2017 06:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HXBR63eaiRVBHRnRkqQnAKMWl90fiPY7jMYXrlouy+4=; b=KmHjYFcqSDypWgZGjwrlTtLFwxOI74GEwgR6dWafp/wV41+rkDM2wu7R2bZBodyPjN+n3qQKzQ0vNOo1ZSKLG8EkxDbydFoVQ5PCfYx3OG5R5xBAzyO856qYsuhWsHo1hgushzhGRfwrG162JRRXhjC5B/P0cvQYvHfJWgYRKec= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Mon, 27 Mar 2017 13:56:37 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.020; Mon, 27 Mar 2017 13:56:37 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" , "opsawg@ietf.org" Thread-Topic: PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKnAbKJdBq3STHUQoS3UW3fFlo+sQ== Date: Mon, 27 Mar 2017 13:56:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.1] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:uyHrKgDVOiHHcSWns2Uz5ix9kmgy465Scp/Y8KcApdmAeZLkjlNspYSOYEWMYGHezrffJjzibjBpkBTyhqL7saC2vXGht9mkhhfRxdTYlfzbYWJeeGN/JF+bmmn9OdpYZpXtKK5I8mdCVjPzwtz7lQSVov/mlylz0/0FKJbbCicWXAzSDIXoqwWJbIPWWfytTUU0HgiiQZqY4pZghC7j9BOhzjTjwecxocLrNfqukrdX6yFjeq7SZvP4yf7zf9wC2jV2t7bx7tFSv97TvQvqP/KmpSqATZZWqUAoodIcBpweLSBPBb5Y+tLvn95QX2LlgaURtFnXxS2GKzc2Ckk2ZA== x-ms-office365-filtering-correlation-id: f991cccb-54c2-4c5f-b06d-08d475191625 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(55016002)(9686003)(6506006)(6436002)(99286003)(2900100001)(77096006)(33656002)(50986999)(3280700002)(54356999)(66066001)(2906002)(3660700001)(7736002)(122556002)(189998001)(5660300001)(2501003)(8936002)(102836003)(3846002)(74316002)(6116002)(7696004)(81166006)(8676002)(305945005)(38730400002)(86362001)(450100002)(53936002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 13:56:37.1472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [OPSAWG] PANIC Bar BoF Wednesday @ 6:30pm CDT 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, 27 Mar 2017 13:56:41 -0000 The IETF SACM work group has been working to standardize the collection of = endpoint configuration and other posture information from enterprise endpoi= nts. Collecting this information is critical to support automation of commo= n network security tasks, including asset, software, vulnerability, and con= figuration management. Thus far, our efforts have focused primarily on stan= dards to collect information in support of asset, software and vulnerabilit= y management use cases, and has worked with other IETF members to determine= what data would need to be to be collected, and how that data would be sec= urely communicated across the network. Through such exchanges an organizati= on can know what client endpoints are connected to their network, and if th= ey are vulnerable to attack. Given the proliferation of attacks against network infrastructure devices, = it is clear that the next step in our enterprise security automation effort= must be to enable standardized reporting of similar information from netwo= rk infrastructure devices. With the growing number of Yang models and incre= ased adoption of NETCONF, RESTCONF, and related protocol work, the time is = right to work out how these standards can be used to measure the health of = network devices. This information will, as in our efforts in SACM for clien= t devices, support asset, software, vulnerability, and configuration manage= ment use cases. Standards-based reporting of this information from network = infrastructure devices will help network defenders protect against known at= tacks, and provide the necessary knowledge to detect and mitigate future at= tacks.=20 We would like to start a discussion about how to leverage the existing IETF= network management protocols to best address security automation for netwo= rk infrastructure devices. We would like your ideas on how to best pursue t= his work, and your insights into network infrastructure security problems t= hat will impact our networks in the future. We are holding a side meeting a= t IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion abou= t how to move forward. We will be meeting in Vevey 4 at the IETF meeting ve= nue. Here is a summary of the meeting details: PANIC (Posture Assessment through Network Information Collection) Bar BoF W= ednesday, March 29th, 2017 @ 6:30pm CDT Swissotel Conference Center - Vevey= 4 We look forward to working with you, and hope to see you in Chicago at the = PANIC Bar BoF. Regards, Dave Waltermire David Waltermire Information Technology Laboratory Computer Security Division National Institute of Standards and Technology David Waltermire Information Technology Laboratory | Computer Security Division National Institute of Standards and Technology From nobody Tue Mar 28 11:20:45 2017 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 959E01297D0 for ; Tue, 28 Mar 2017 11:20:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 yyP3DqLW9MJj for ; Tue, 28 Mar 2017 11:20:39 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 B4313129882 for ; Tue, 28 Mar 2017 11:20:32 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p77so59313635ywg.1 for ; Tue, 28 Mar 2017 11:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jw5O2i9NvYKAVK8pa8jhdQk1jth/tz4QpABTPn1kIQs=; b=ghpNeg0gPRaHKn7/DqSEH4CTKpreNpI4fDuKO785Coaz0VFeAYJ5A5dbvCrNpIMPL0 TcSUHfJlFnlxWSH307ntqzdMz3RAKdODgwyb9q4x9/ZqWYomkvjvHinYqqyi2D6oWHMw lTlivS6AZ6/dfciT90w64OCZAr9UPIpc7oJaXvmWPtjdt2z79jqk4Ft75iJ3dCxoZWoV ysb4oX9hGBVKG2AWvHoMwuKxPtNTxdhCr1s7IG590s8t+pNbOBTKZ/j6nSaw1nkdBzeD nt2kigp6dMWPz0ye6NYu5Nhh7Hhui9UwBognPZNk/XjIvS4ANoNgYX1G+dpU86nVsU+Y efqA== 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=Jw5O2i9NvYKAVK8pa8jhdQk1jth/tz4QpABTPn1kIQs=; b=EUQWhS00GjNgc8IkjW8SrCDv/cwsYa5xfPa10n5lwiliAsRiLiHe9pc7fyAZm5+Uzk G9G6xYymFzbodnT7Cu7aOaOXKcISiDgu74he8erSMcoQOsvNW4rqwKT3LRmWqrR/mi6T SS8SlDyJnpEV8b9Mdol5jISYHevXLfJLvIeqWVzvMcpV6eMBrg4Xu2ASYbkszmSkJK6a L+mcerGffCijfK0Q0raK5XTO+hhDPe1bJZkd3M4ZWgV95ql4l5T0t9fxcb7cywkxIDDK 7H8F7FK62iFGn/n0RkZxc/v6kEcvcr87k/MKQ/3DO5WfWZKxwlRvjHqfGVL73xxEm2li NEyA== X-Gm-Message-State: AFeK/H1iSUJrmykRVkO+8ghyxxyEUTM5ocVWs44qmYYepAmVjxOwJ7VEhaJErDIKOBUK2S75SBdqx3a3qyqQgtbb X-Received: by 10.13.240.67 with SMTP id z64mr23838223ywe.249.1490725231616; Tue, 28 Mar 2017 11:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.212.134 with HTTP; Tue, 28 Mar 2017 11:20:01 -0700 (PDT) In-Reply-To: References: From: Thorsten Dahm Date: Tue, 28 Mar 2017 13:20:01 -0500 Message-ID: To: Tianran Zhou Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0361c0e3e09b054bce83a3 Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 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, 28 Mar 2017 18:20:44 -0000 --94eb2c0361c0e3e09b054bce83a3 Content-Type: text/plain; charset=UTF-8 I support the document. Regards, Thorsten On 17 March 2017 at 03:17, Tianran Zhou wrote: > Dear OPSAWG, > > This is a notice to start a two-week OPSAWG WG last call for the document: > > Manufacturer Usage Description Specification > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > Please read the above draft and send any issues, comments, or corrections > to this mailing list. > Please indicate your support or concerns by Friday March 31, 2017. > > Thanks, > Chairs > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --94eb2c0361c0e3e09b054bce83a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the document.

Regards,
<= div>Thorsten

On 17 March 2017 at 03:17, Tianran Zhou <zhoutianran@huawei.com&= gt; wrote:
Dear OPSAWG,

This is a notice to start a two-week OPSAWG WG last call for the document:<= br>
Manufacturer Usage Description Specification
https://datatracker.ietf.org/doc/draft-i= etf-opsawg-mud/

Please read the above draft and send any issues, comments, or corrections t= o this mailing list.
Please indicate your support or concerns by Friday March 31, 2017.

Thanks,
Chairs

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



--94eb2c0361c0e3e09b054bce83a3-- From nobody Wed Mar 29 13:42:18 2017 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 8421B1201F2; Wed, 29 Mar 2017 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 gGmLV8P5-rxf; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74055129481; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w3Gma++M9mODIA8/U+rJLTU2z37VjY89vzwisgNlYyI=; b=mDBytFIu/s6c65I+1o8OErJY2xzT6TfzqPchKLjvDoKZmoSZCna4xB099oUnG8/e+AFTPy9nLb2ReJIiLk/ltF1yiU0BVnHg0fk7bm0NjbYnRaUz7wNrXubW6v7qjdcHFtBLglX9mIHPYIOL8y9kgdN8eSHw1XSdHuwtAAAZ10M= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 20:42:04 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 20:42:04 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" , "opsawg@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: PANIC Bar BoF Tonight @ 6:30pm CDT Thread-Index: AdKoyz/2/d9baDSGTnuHD2EJjZ7Mgw== Date: Wed, 29 Mar 2017 20:42:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.87] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:MRz0WSeTiWWcEhsHvpdzglCWeYt10yvdJL2HAM7tWMGoGl4fZ6pjnisT6YM4hGexNOoWOCm5NeE3pWeaCCBiezL3s0n0EVCAoLPMstiTbJEmLCN46tegb36TvmcCDHqJo8cU+YuenCc6+3tO74BzGcpl3tyywY0a6G2mNqIK68Q/FhptBRZZxWy/LoL6AEX0Pr4RRpmuAnL7M3lYf/4RI4jjDz81lgkDjfo3qZ0y+bI5jSWddlbyxn1HC7xwDAZ6ZfsO1t29VTfNbUPR2LNjA3INADhXpccxGwzlPnlN25nJSvJYCZfdBwwgmQNAibjz2eqxMzcK5U8D5H9xmwaILQ== x-ms-office365-filtering-correlation-id: ca08842c-5a57-4a1f-02fa-08d476e40f60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(7696004)(6506006)(2501003)(53936002)(77096006)(74316002)(305945005)(9686003)(55016002)(33656002)(6436002)(99286003)(8676002)(81166006)(8936002)(3660700001)(2201001)(86362001)(25786009)(102836003)(3280700002)(50986999)(54356999)(2900100001)(3846002)(189998001)(6116002)(2906002)(5660300001)(7736002)(122556002)(38730400002)(450100002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 20:42:04.5631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: [OPSAWG] PANIC Bar BoF Tonight @ 6:30pm CDT 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, 29 Mar 2017 20:42:08 -0000 Just a quick reminder... the Posture Assessment through Network Information= Collection (PANIC) bar BoF is tonight right after the IETF 98 Technical an= d Administrative Plenary at 6:30pm CDT in Vevey 4 at the Swissotel Conferen= ce Center. We are hoping to start a discussion about how to leverage the ex= isting IETF network management protocols to best address security automatio= n for network infrastructure devices. We would like your ideas on how to be= st pursue this work, and your insights into network infrastructure security= problems that will impact our networks in the future. We are holding a sid= e meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a disc= ussion about how to move forward on this topic. Given the late hour, we will have some light snacks. We hope to see you the= re. Regards, David Waltermire From nobody Wed Mar 29 15:10:01 2017 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 D56301279E5 for ; Wed, 29 Mar 2017 15:09:59 -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 ZglYgt_v7dvK for ; Wed, 29 Mar 2017 15:09:57 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 F2DC2126C23 for ; Wed, 29 Mar 2017 15:09:56 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so162206137itc.0 for ; Wed, 29 Mar 2017 15:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kKxxav6lzjKVZZDJ6oCM7I8crEaTfDkXyqRcTiK8Ng0=; b=SFJILw6h1/biSb2N6dMZFxbWQLc6aY5teffMNFnkjJ15RQXwWft4juV2guc5RwKk6x ZTOn9wgYvuSIHH0cb8rGTuew86jC3vSrkLR333V1P9IPwqVnxDByu54zF7H17ztJmyQ4 EmmNQQpsG9vbeccdl9qPrTBSQ32x7BQ7rpd2JYchRfnht5pAYS04/TbZ87ZpRvIPWAe8 TaX7IYtU0iFAb1ff0FAG0xXyeaoaIHjA5l3v6tdadOwaJSInfl9AVTe0QZtiliDCbDCC p10NId0H1acjXfLM/Z5IoEym3Jg7rBGJ1gg0+WY1qRqQMnykksgigWsKBKmVHQTa/tDP yHjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kKxxav6lzjKVZZDJ6oCM7I8crEaTfDkXyqRcTiK8Ng0=; b=r2Hs7HPVIGovR/P30ylfpY0T9MmRCcoa3wW8ZK73RzLY1ODKdwvdd9uBNaMwGR+lvf ghKJD/FJN8RXwkIp3393e1/YrMfNsS8hojYFXiZErRlKRvvn7aZtKzIawZn3tdw72Dr/ U81sqotpqUvyHaEbZ+VSf3cZJWYNc1C6ABnZbOVfKZt74wlVPQrWHHgBZPFgVypoU6vM TkUKSabfOtb0lQlguCG6DRebs4rQSVvMgisHngRvIjZpKYJLvFF81MsRgrsUhZj1sYa5 bXkPS96oqv1NiQeD/H56u3ilBV+ofdUrlrGF3wZRRgj5rvFc1h5vA6Sf1r3G/8ixYads mW9Q== X-Gm-Message-State: AFeK/H21QjoEmVsWIt5TYtu5U69VwvZhzVzZkuAosvKTIDjCHGM8yEMnag8EvrFRfsXVguduDYxU5MHZPoV6aw== X-Received: by 10.36.207.193 with SMTP id y184mr734466itf.1.1490825396132; Wed, 29 Mar 2017 15:09:56 -0700 (PDT) MIME-Version: 1.0 From: Tim Polk Date: Wed, 29 Mar 2017 22:09:45 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05b90228a42b054be5d6b5 Archived-At: Subject: [OPSAWG] Review and comments: mud-05 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, 29 Mar 2017 22:10:00 -0000 --94eb2c05b90228a42b054be5d6b5 Content-Type: text/plain; charset=UTF-8 After a hallway conversation with one of the authors, I have reviewed mud-05 in some depth and skimmed mud-net-lifecycle-00 and mud-manu-lifecycle-01 for context. I think that the MUD protocol fills a very important gap in the supply chain, in a reasonably elegant manner. Emitting a stable URI for the MUD file provides a very low overhead mechanism to integrate a new component into your network along with appropriate access controls. The goals laid out in the introduction are largely satisfied, and security controls seem appropriate. I am especially excited about the application to IoT devices for the home consumer, but believe this has distinct advantages for the enterprise as well. In short, I support advancing the document. That said, I have some issues with the draft I would like to raise. (1) Why are we excluding legacy devices from the benefits of MUD? If the device does not emit the MUD URI, which is every legacy device, then it is excluded from the system. If I obtain a MUD controller, I would definitely want to apply this functionality to my previously purchased legacy devices. Yes there are risks in obtaining this information out-of-band, and the management overhead is much lower if my devices convey the URI, but once I provision the controller with a URI and identify the devices I will obtain many of the same benefits to security. Supporting MUD files for legacy devices also allows me to maximize my near-term ROI, which promote adoption... I would suggest adding a brief section 1.7 on legacy devices, simply stating that manufacturers MAY make MUD files available for legacy devices to support appropriate network configuration, and MUD controllers MAY accept URIs for devices through out-of-band means. (2a) [Section 3.3] This draft uses a cache-validity period rather than a next-update time to indicate when to check back. Given that cache-validity prohibits checking back during the specified period, are we comfortable with a recommended maximum value of 1440 hours (60 days!)? Okay, that was a rhetorical question - I'm not comfortable with that at all. Assume a revised MUD file is posted to address a new vulnerability, and the controller always retrieves a fresh copy at the first permissible moment, the average network supporting the corresponding device will experience a post-discovery window of vulnerability of 30 days on average. Given the expected size of the file, why prohibit checking for so long? I understand that there are concerns about MUD controllers hammering servers at high frequency, but 7 days (168 hours) seems like a reasonable maximum to me. In more brevity, I suggest: OLD It is RECOMMENDED that this value be no less than 24 and no more than 1440 for any device that is supported. NEW It is RECOMMENDED that this value be no less than 24 and no more than 168 for any device that is supported. (2b) Better yet, should there be a MAXIMUM amount of time before the checking for a new MUD file? As written, the MUD controller could choose to never look for updates and be "conformant". We could add a field to MUD file specifying the MAXIMUM amount of time, but a lighter weight solution might be a recommendation that the MUD controller refresh all MUD files whose cache-validity period has been exhausted: Append to the end of Section 3.3: The MUD controller SHOULD refresh any MUD file whose cache-validity period has been exhausted. (3) The introduction (section 1, top of pg 4, bullet 3) states that MUD is intended to: o Provide a means to address at least some vulnerabilities in away that is faster than it might take to update systems. This will be particularly true for systems that are no longer supported by their manufacturer. In practice, this is probably true since so many devices are never updated or are used beyond the supported lifetime. For this statement to be more broadly correct, we would need a way to push a new MUD file since cache-validity prohibits early checking. That is, once the vulnerability is known and we post the new MUD file, the average time to download and implementation of access rules is 50% of the cache-validity period. Is this a reason to support subscription of a MUD-controller to a MUD file distributor for emergency changes? I do not advocate changing the MUD draft to incorporate this level of complexity, but if this is our goals perhaps this should be addressed in a future draft... (4) I request a bit of indulgence here; I admit that this one is a bit of a rant. The MUD protocol may have the unexpected consequence of perpetuating bad developer behavior. There is no reason a baby monitor should include a web browser, but the lazy developer just leaves the code in their distribution. Removing the unnecessary code (so messages sent to the offending port would be rejected) should provide stronger security than constraints implicitly specified in the MUD file, and both in concert would be ideal. Does this incentivize developers to make weak security choices and "fix" them in the MUD file? I think that some text in the security considerations stating that MUD is intended to complement and strengthen well designed systems and does not relieve vendors of the obligation to produce decent code is in order. (5) This may be a bridge too far for initial deployment, but (based on my limited understanding of YANG) the architecture assumes that the access controls are independent of device configuration. (That is, I don't see any conditionals.) Is that really the case? For example, if the devices still use the default administrator password I might want to be more restrictive than after the passwords have been updated. If I am a large enterprise, I might also want to substitute infrastructure I own for the vendor supplied cloud that supports operations. How do people envision dealing with this situation? If the network operator has decided to override certain settings, does this preclude use of future updates? --94eb2c05b90228a42b054be5d6b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After a hallway conversation with one = of the authors, I have reviewed mud-05 in some depth and skimmed mud-net-li= fecycle-00 and mud-manu-lifecycle-01 for context.

I think that the MUD protocol fills a very important gap in the supply= chain, in a reasonably elegant manner.=C2=A0 Emitting a stable URI for the= MUD file provides a very low overhead mechanism to integrate a new compone= nt into your network along with appropriate access controls.=C2=A0 The goal= s laid out in the introduction are largely satisfied, and security controls= seem appropriate.=C2=A0 I am especially excited about the application to I= oT devices for the home consumer, but believe this has distinct advantages = for the enterprise as well.

In short, I suppo= rt advancing the document. =C2=A0

That said, I have some issues with= the draft I would like to raise.

(1) Why are= we excluding legacy devices from the benefits of MUD?=C2=A0 If the device = does not emit the MUD URI, which is every legacy device, then it is exclude= d from the system.=C2=A0 If I obtain a MUD controller, I would definitely w= ant to apply this functionality to my previously purchased legacy devices.= =C2=A0 Yes there are risks in obtaining this information out-of-band, and t= he management overhead is much lower if my devices convey the URI, but once= I provision the controller with a URI and identify the devices I will obta= in many of the same benefits to security.

S= upporting MUD files for legacy devices also allows me to maximize my near-t= erm ROI, which promote adoption...

I would su= ggest adding a brief section 1.7 on legacy devices, simply stating that man= ufacturers MAY make MUD files available for legacy devices to support appro= priate network configuration, and MUD controllers MAY accept URIs for devic= es through out-of-band means.

(2a) [Section 3= .3] This draft uses a cache-validity period rather than a next-update time = to indicate when to check back.=C2=A0 Given that cache-validity prohibits c= hecking back during the specified period, are we comfortable with a recomme= nded maximum value of 1440 hours (60 days!)?

= Okay, that was a rhetorical question - I'm not comfortable with that at= all.=C2=A0 Assume a revised MUD file is posted to address a new vulnerabil= ity, and the controller always retrieves a fresh copy at the first permissi= ble moment, the average network supporting the corresponding device will ex= perience a post-discovery window of vulnerability of 30 days on average.=C2= =A0 Given the expected size of the file, why prohibit checking for so long?= =C2=A0 I understand that there are concerns about MUD controllers hammering= servers at high frequency, but 7 days (168 hours) seems like a reasonable = maximum to me.

In more brevity, I suggest:
= OLD
It is= RECOMMENDED that this value be no less than 24 and no
more than 1440 for any device that is supported.
NEW
It is RECOMMEN= DED that this value be no less than 24 and no
more than 168 for any device that is supported.

(2b) Better yet, should there be a MAXIMUM amount of time before th= e checking for a new MUD file?=C2=A0 As written, the MUD controller could c= hoose to never look for updates and be "conformant".=C2=A0 We cou= ld add a field to MUD file specifying the MAXIMUM amount of time, but a lig= hter weight solution might be a recommendation that the MUD controller refr= esh all MUD files whose cache-validity period has been exhausted:
Append to the end of Section 3.3:
The MUD controller SHOULD refresh any MUD file whose cache-v= alidity period has been exhausted.

(3) The in= troduction (section 1, top of pg 4, bullet 3) states that MUD is intended t= o:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 o Provide = a means to address at least some vulnerabilities in away
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that is faster than it might ta= ke to update systems. This will be
=C2=A0= =C2=A0 =C2=A0 =C2=A0 particularly true for systems that are no longer supp= orted by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 thei= r manufacturer.

In practice, this is probably= true since so many devices are never updated or are used beyond the suppor= ted lifetime.=C2=A0 For this statement to be more broadly correct, we would= need a way to push a new MUD file since cache-validity prohibits early che= cking.=C2=A0 That is, once the vulnerability is known and we post the new M= UD file, the average time to download and implementation of access rules is= 50% of the cache-validity period.

Is this a = reason to support subscription of a MUD-controller to a MUD file distributo= r for emergency changes?=C2=A0 I do not advocate changing the MUD draft to = incorporate this level of complexity, but if this is our goals perhaps this= should be addressed in a future draft...

(= 4) I request a bit of indulgence here; I admit that this one is a bit of a = rant.

The MUD protocol may have the unexpecte= d consequence of perpetuating bad developer behavior.=C2=A0 There is no rea= son a baby monitor should include a web browser, but the lazy developer jus= t leaves the code in their distribution.=C2=A0 Removing the unnecessary cod= e (so messages sent to the offending port would be rejected) should provide= stronger security than constraints implicitly specified in the MUD file, a= nd both in concert would be ideal.

Does this = incentivize developers to make weak security choices and "fix" th= em in the MUD file?=C2=A0 I think that some text in the security considerat= ions stating that MUD is intended to complement and strengthen well designe= d systems and does not relieve vendors of the obligation to produce decent = code is in order.

(5) This may be a bridge to= o far for initial deployment, but (based on my limited understanding of YAN= G) the architecture assumes that the access controls are independent of dev= ice configuration.=C2=A0 (That is, I don't see any conditionals.)=C2=A0= Is that really the case?=C2=A0 For example, if the devices still use the d= efault administrator password I might want to be more restrictive than afte= r the passwords have been updated.=C2=A0 If I am a large enterprise, I migh= t also want to substitute infrastructure I own for the vendor supplied clou= d that supports operations.

How do people env= ision dealing with this situation?=C2=A0 If the network operator has decide= d to override certain settings, does this preclude use of future updates?
--94eb2c05b90228a42b054be5d6b5-- From nobody Wed Mar 29 15:12:51 2017 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 49F881294FA for ; Wed, 29 Mar 2017 15:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 G3EOYKHXVCni for ; Wed, 29 Mar 2017 15:12:46 -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 78013126C23 for ; Wed, 29 Mar 2017 15:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26519; q=dns/txt; s=iport; t=1490825566; x=1492035166; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ulwq7CYbfHUFGpc6PUSTyugNekXzEeNiRzsu2754jss=; b=jolTGynL8opC+8yhPWo8turLDHH8X57GfLjexC+h448BL9RmMvQ19V1q dTIz639pwCjpyzbiDZPIiHkWq0bLp0hAm1PpWYMPwr60HVrN0DiR2FZYG vaElsT7akelkgzG7IvxcHH4RgXCtBFNcnqRH3krhQ1pg0arBhYUOIYcO0 o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQANMdxY/5hdJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMqK2GBC4NiihGRUZVOgg4fAQqFLkoCg0M/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBAQEDAQEhSxsJAhIGDQsICgICJyIOBgEMBgIBAReJbw6QJZwsD4EggiYri?= =?us-ascii?q?i4BAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWIU4JqhCwEcoI4gl8FiSgHhzJNizK?= =?us-ascii?q?DfIIMhB+IKYF8iF6GWYYVgkOLEh84gQQkFggXFUGEUwUdggEiNYZ5gj0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="asc'?scan'208,217";a="404179693" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 22:12:35 +0000 Received: from [10.86.247.188] ([10.86.247.188]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2TMCY0e017763; Wed, 29 Mar 2017 22:12:35 GMT To: Tim Polk , "opsawg@ietf.org" References: From: Eliot Lear Message-ID: <927afbb2-a817-cd99-65f8-65079f5e4633@cisco.com> Date: Wed, 29 Mar 2017 17:12:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HHcSKH8w5EhuIW54HC6U3DCBoIVNmBpUE" Archived-At: Subject: Re: [OPSAWG] Review and comments: mud-05 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, 29 Mar 2017 22:12:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HHcSKH8w5EhuIW54HC6U3DCBoIVNmBpUE Content-Type: multipart/mixed; boundary="nCxiwH3pFBj8Knm0NaAXHd4WNKFBTPRka"; protected-headers="v1" From: Eliot Lear To: Tim Polk , "opsawg@ietf.org" Message-ID: <927afbb2-a817-cd99-65f8-65079f5e4633@cisco.com> Subject: Re: [OPSAWG] Review and comments: mud-05 References: In-Reply-To: --nCxiwH3pFBj8Knm0NaAXHd4WNKFBTPRka Content-Type: multipart/alternative; boundary="------------B44CE1FDA85226FC76DDBF5B" This is a multi-part message in MIME format. --------------B44CE1FDA85226FC76DDBF5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks very much for raising these questions. Although they are not on my slides for tomorrow (already submitted) I propose to address them first in person then if you can make it, or otherwise on list. Regards, Eliot On 3/29/17 5:09 PM, Tim Polk wrote: > After a hallway conversation with one of the authors, I have reviewed > mud-05 in some depth and skimmed mud-net-lifecycle-00 and > mud-manu-lifecycle-01 for context. > > I think that the MUD protocol fills a very important gap in the supply > chain, in a reasonably elegant manner. Emitting a stable URI for the > MUD file provides a very low overhead mechanism to integrate a new > component into your network along with appropriate access controls.=20 > The goals laid out in the introduction are largely satisfied, and > security controls seem appropriate. I am especially excited about the > application to IoT devices for the home consumer, but believe this has > distinct advantages for the enterprise as well. > > In short, I support advancing the document. =20 > > That said, I have some issues with the draft I would like to raise. > > (1) Why are we excluding legacy devices from the benefits of MUD? If > the device does not emit the MUD URI, which is every legacy device, > then it is excluded from the system. If I obtain a MUD controller, I > would definitely want to apply this functionality to my previously > purchased legacy devices. Yes there are risks in obtaining this > information out-of-band, and the management overhead is much lower if > my devices convey the URI, but once I provision the controller with a > URI and identify the devices I will obtain many of the same benefits > to security. > > Supporting MUD files for legacy devices also allows me to maximize my > near-term ROI, which promote adoption... > > I would suggest adding a brief section 1.7 on legacy devices, simply > stating that manufacturers MAY make MUD files available for legacy > devices to support appropriate network configuration, and MUD > controllers MAY accept URIs for devices through out-of-band means. > > (2a) [Section 3.3] This draft uses a cache-validity period rather than > a next-update time to indicate when to check back. Given that > cache-validity prohibits checking back during the specified period, > are we comfortable with a recommended maximum value of 1440 hours (60 > days!)? > > Okay, that was a rhetorical question - I'm not comfortable with that > at all. Assume a revised MUD file is posted to address a new > vulnerability, and the controller always retrieves a fresh copy at the > first permissible moment, the average network supporting the > corresponding device will experience a post-discovery window of > vulnerability of 30 days on average. Given the expected size of the > file, why prohibit checking for so long? I understand that there are > concerns about MUD controllers hammering servers at high frequency, > but 7 days (168 hours) seems like a reasonable maximum to me. > > In more brevity, I suggest: > OLD > It is RECOMMENDED that this value be no less than 24 and no > more than 1440 for any device that is supported. > NEW > It is RECOMMENDED that this value be no less than 24 and no > more than 168 for any device that is supported. > > (2b) Better yet, should there be a MAXIMUM amount of time before the > checking for a new MUD file? As written, the MUD controller could > choose to never look for updates and be "conformant". We could add a > field to MUD file specifying the MAXIMUM amount of time, but a lighter > weight solution might be a recommendation that the MUD controller > refresh all MUD files whose cache-validity period has been exhausted: > > Append to the end of Section 3.3: > The MUD controller SHOULD refresh any MUD file whose cache-validity > period has been exhausted. > > (3) The introduction (section 1, top of pg 4, bullet 3) states that > MUD is intended to: > o Provide a means to address at least some vulnerabilities in a= way > that is faster than it might take to update systems. This will = be > particularly true for systems that are no longer supported by > their manufacturer. > > In practice, this is probably true since so many devices are never > updated or are used beyond the supported lifetime. For this statement > to be more broadly correct, we would need a way to push a new MUD file > since cache-validity prohibits early checking. That is, once the > vulnerability is known and we post the new MUD file, the average time > to download and implementation of access rules is 50% of the > cache-validity period. > > Is this a reason to support subscription of a MUD-controller to a MUD > file distributor for emergency changes? I do not advocate changing > the MUD draft to incorporate this level of complexity, but if this is > our goals perhaps this should be addressed in a future draft... > > (4) I request a bit of indulgence here; I admit that this one is a bit > of a rant. > > The MUD protocol may have the unexpected consequence of perpetuating > bad developer behavior. There is no reason a baby monitor should > include a web browser, but the lazy developer just leaves the code in > their distribution. Removing the unnecessary code (so messages sent > to the offending port would be rejected) should provide stronger > security than constraints implicitly specified in the MUD file, and > both in concert would be ideal. > > Does this incentivize developers to make weak security choices and > "fix" them in the MUD file? I think that some text in the security > considerations stating that MUD is intended to complement and > strengthen well designed systems and does not relieve vendors of the > obligation to produce decent code is in order. > > (5) This may be a bridge too far for initial deployment, but (based on > my limited understanding of YANG) the architecture assumes that the > access controls are independent of device configuration. (That is, I > don't see any conditionals.) Is that really the case? For example, > if the devices still use the default administrator password I might > want to be more restrictive than after the passwords have been > updated. If I am a large enterprise, I might also want to substitute > infrastructure I own for the vendor supplied cloud that supports > operations. > > How do people envision dealing with this situation? If the network > operator has decided to override certain settings, does this preclude > use of future updates? > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------B44CE1FDA85226FC76DDBF5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Tim,

Thanks very much for raising these questions.=C2=A0 Although they = are not on my slides for tomorrow (already submitted) I propose to address them first in person then if you can make it, or otherwise on list.

Regards,

Eliot


On 3/29/17 5:09 PM, Tim Polk wrote:
After a hallway conversation with one of th= e authors, I have reviewed mud-05 in some depth and skimmed mud-net-lifecycle-00 and mud-manu-lifecycle-01 for context.

I think that the MUD protocol fills a very important gap in the supply chain, in a reasonably elegant manner.=C2=A0 Emitting a stable URI for the MUD file provides a= very low overhead mechanism to integrate a new component into your network along with appropriate access controls.=C2=A0 The goals laid out in the introduction are largely satisfied, and security controls seem appropriate.=C2=A0 I am especially excit= ed about the application to IoT devices for the home consumer, but believe this has distinct advantages for the enterprise as well.

In short, I support advancing the document.= =C2=A0

That said, I have some issues with the draft I would like to raise.

(1) Why are we excluding legacy devices from the benefits of MUD?=C2=A0 If the device does not emit t= he MUD URI, which is every legacy device, then it is excluded from the system.=C2=A0 If I obtain a MUD controller, I would definitely want to apply this functionality to my previously purchased legacy devices.=C2=A0 Yes there are risks in obtain= ing this information out-of-band, and the management overhead is much lower if my devices convey the URI, but once I provision the controller with a URI and identify the devices I will obtain many of the same benefits to security.
Supporting MUD files for legacy devices also allows me to maximize my near-term ROI, which promote adoption...

I would suggest adding a brief section 1.= 7 on legacy devices, simply stating that manufacturers MAY make MUD files available for legacy devices to support appropriate network configuration, and MUD controllers MAY accept URIs for devices through out-of-band means.

(2a) [Section 3.3] This draft uses a cache-validity period rather than a next-update time to indicate when to check back.=C2=A0 Given that cache-validity prohibits checking back during the specified period, are we comfortable with a recommended maximum value of 1440 hours (60 days!)?

Okay, that was a rhetorical question - I'= m not comfortable with that at all.=C2=A0 Assume a revised MUD = file is posted to address a new vulnerability, and the controller always retrieves a fresh copy at the first permissible moment, the average network supporting the corresponding device will experience a post-discovery window of vulnerability of 30 days on average.=C2=A0 Given the expected= size of the file, why prohibit checking for so long?=C2=A0 I understand that there are concerns about MUD controllers hammering servers at high frequency, but 7 days (168 hours) seems like a reasonable maximum to me.

In more brevity, I suggest:
OLD
It is RECOMMENDED that this value be no less than 24 and no
more than 1440 for any device that is supported.
NEW
It is RECOMMENDED that this value be no less than 24 and no
more than 168 for any device that is supported.

(2b) Better yet, should there be a MAXIMU= M amount of time before the checking for a new MUD file?=C2=A0 = As written, the MUD controller could choose to never look for updates and be "conformant".=C2=A0 We could add a field to MU= D file specifying the MAXIMUM amount of time, but a lighter weight solution might be a recommendation that the MUD controller refresh all MUD files whose cache-validity period has been exhausted:

Append to the end of Section 3.3:<= br class=3D"gmail_msg" style=3D"color:rgb(49,49,49);word-spacing:1px"> The MUD controller SHOULD refresh any MUD= file whose cache-validity period has been exhausted.
(3) The introduction (section 1, top of p= g 4, bullet 3) states that MUD is intended to:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 o Provide a m= eans to address at least some vulnerabilities in away
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that is faste= r than it might take to update systems. This will be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 particularly = true for systems that are no longer supported by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 their manufac= turer.

In practice, this is probably true since so many devices are never updated or are used beyond the supported lifetime.=C2=A0 For this statement to be more broad= ly correct, we would need a way to push a new MUD file since cache-validity prohibits early checking.=C2=A0 That is, once = the vulnerability is known and we post the new MUD file, the average time to download and implementation of access rules is 50% of the cache-validity period.

Is this a reason to support subscription of a MUD-controller to a MUD file distributor for emergency changes?=C2=A0 I do not advocate changing the MUD draft to incorporate this level of complexity, but if this is our goals perhaps this should be addressed in a future draft...

(4) I request a bit of indulgence here; I= admit that this one is a bit of a rant.

The MUD protocol may have the unexpected consequence of perpetuating bad developer behavior.=C2=A0 The= re is no reason a baby monitor should include a web browser, but the lazy developer just leaves the code in their distribution.=C2=A0 Removing the unnecessary code (so message= s sent to the offending port would be rejected) should provide stronger security than constraints implicitly specified in the MUD file, and both in concert would be ideal.

Does this incentivize developers to make weak security choices and "fix" them in the MUD file?=C2=A0 I= think that some text in the security considerations stating that MUD is intended to complement and strengthen well designed systems and does not relieve vendors of the obligation to produce decent code is in order.

(5) This may be a bridge too far for initial deployment, but (based on my limited understanding of YANG) the architecture assumes that the access controls are independent of device configuration.=C2=A0 (That is, I do= n't see any conditionals.)=C2=A0 Is that really the case?=C2=A0 F= or example, if the devices still use the default administrator password I might want to be more restrictive than after the passwords have been updated.=C2=A0 If I am a large enterprise= , I might also want to substitute infrastructure I own for the vendor supplied cloud that supports operations.

How do people envision dealing with this situation?=C2=A0 If the network operator has decided to overr= ide certain settings, does this preclude use of future updates?


_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------B44CE1FDA85226FC76DDBF5B-- --nCxiwH3pFBj8Knm0NaAXHd4WNKFBTPRka-- --HHcSKH8w5EhuIW54HC6U3DCBoIVNmBpUE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJY3DFSAAoJEIe2a0bZ0nozXtQIANlvFpi5stqOCeZoFhvZi2/9 X30JeWjv7qSrLCb/ihawEtbnpq1MG8/e0EnWB3Rn3bUYspzAAiD4od1ZnFQ1GM+7 tR+bNQxvAlpBJfZeMpJyNr3BLTb2j2F/3sYqFqi1EglfAPwVu1rZSmcJWnDnjjZt 9cbdnjA2dyGY7htGlndvEEHxRZoLZTjIhMawJnw2bgKCQH06JgI5ytXTBCTZo3a0 HDToGgOY+4ML39+6EESQ2t65IAnLGK9Doi2qbE0WdJLhgISj+DvSjnyhKc5hyMnx pK2ngc0kDdo+A5/eL+WGCbf6ac72J8QhfEbuN6qvOIIcya2U87rrf/wLxZ9XSRs= =+oVO -----END PGP SIGNATURE----- --HHcSKH8w5EhuIW54HC6U3DCBoIVNmBpUE-- From nobody Thu Mar 30 10:23:18 2017 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 0F0411299E4; Thu, 30 Mar 2017 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3NYVinAUuqY3; Thu, 30 Mar 2017 10:23:15 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 325AC1299D7; Thu, 30 Mar 2017 10:23:15 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l43so71314382wre.1; Thu, 30 Mar 2017 10:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=fyjl74zc3FkkU7OfMFdca9+ya/RakW2wMfuE1GjhV2A=; b=enOov8KG+5S9xKby2zGdysj9GxJtLwml4dU9jVMn70LfJq1RyyPBSV3McPOAQCjwKB tzEF9b/4emEpGjjjNuCgC8n1hxwFLPCZnuVBtRMfl6T5XkaTtr/Kw4G61/TdryGZfIef iwWvYgfvjvdhOD+m+H7aa5pp1TKKKvpa2wOr5FO1DjTpmmUAGjtNxwKauLfptoORVJ2L fdtMK15pr6CNvgWZJHbgKHRNVvlRVcdMG2QCvbbWQlfAFfYldbHIDmvxMDtUTAGlMiMx f/rczEYui0PBL24NL11FYbLmnj7U8KK8lvSza/03q+hUc/IrOsGXeb1xUqiS1/6I4VWW gkJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=fyjl74zc3FkkU7OfMFdca9+ya/RakW2wMfuE1GjhV2A=; b=RHB57/qaVoUFZ264kRHEK8uiux2f95GtRhi9Mm+GRzTGOTw5vW+eSx00fHhnYigkhz Y3b/owBhMPFrEhuVhCcYO+RVynN9odbBHVwJGf1jmNZItvzijhx2nj+icsgNsl8wI15s 9NTd8tpoAOwSE0LuvAgLhWAf+IqyIWFH68CgYM1VS3gMiNH4Y+y5D4xw8IJA19/rgkHF CjA/SmlBTpDTYXItO6FCLI5IDdiPuIwbuVVfFt2wd/Ps08C3MS+byMEvrblY5Na83tiX JOf1HdT6rVizEK7BSLNV0d56Wu/WSmZzUX2uHKe+kW+3ufK1m4mK0M6Z1N662PJYVsEg ZT9g== X-Gm-Message-State: AFeK/H11ZNEvD1tpNaeqjBddWexvRNO0RH6Dby/77mFm49SyAXwPRnZYZ9xzZq+z3JJozg== X-Received: by 10.28.165.147 with SMTP id o141mr1465993wme.67.1490894593574; Thu, 30 Mar 2017 10:23:13 -0700 (PDT) Received: from [192.168.191.106] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id 201sm13048765wmr.5.2017.03.30.10.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 10:23:13 -0700 (PDT) To: "opsawg@ietf.org" Cc: "opsawg-chairs@ietf.org" From: Ignas Bagdonas Message-ID: <22e5ec3d-de6f-df54-0da4-166da74cedb4@gmail.com> Date: Thu, 30 Mar 2017 18:23:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Notes and Jabber for OPSAWG meeting 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, 30 Mar 2017 17:23:17 -0000 Hi, OPSAWG is meeting soon, note taking and jabber room monitoring seem to be just the right snoozing mode tasks after a nice lunch. Please could any volunteers for notes or Etherpad and jabber come forward? Thank you. From nobody Thu Mar 30 11:56:04 2017 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 7915E1201FA; Thu, 30 Mar 2017 11:55:56 -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 kqBUuJgND5qH; Thu, 30 Mar 2017 11:55:54 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0C2126B72; Thu, 30 Mar 2017 11:55:53 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2UItp2e030653; Thu, 30 Mar 2017 19:55:51 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2UItnCp030630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Mar 2017 19:55:50 +0100 Reply-To: From: "Adrian Farrel" To: , Date: Thu, 30 Mar 2017 19:55:51 +0100 Message-ID: <042d01d2a987$414844a0$c3d8cde0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKphlqOZxnzPxBmRdajq9pU3vTa7Q== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22976.001 X-TM-AS-Result: No--3.130-10.0-31-10 X-imss-scan-details: No--3.130-10.0-31-10 X-TMASE-MatchedRID: ZeZXEHjiKRlS/isIEXGDv7u9iqQJLR0vh8Ytn75ClDNVCJR4LoJu4rC/ tyr/qneUptiFgxvHaW9GXdPR9R77GDhkyYEbqgcm+cKX6yCQ13uz5LIh2+IOfNoVfIzJhiw0nKQ gYq4pRtmFu+YpukiIJh9l1zPMOb+6TX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG7CKFCmhdu5cXrdo rMz3unsoBZ360Bo2Fs0TbVdHbBlre03CpH8K7VIKRIZlQ8ceOTRUa/cBCi+N9LgVu0TC67A0ob6 bMXcgBXJNOtXGWfATeRzy9lhw/CZKG6tVpjWHJfjF1XCR4TdrdTI6qsXPa6iJ6oP1a0mRIj Archived-At: Subject: [OPSAWG] Progress of draft-ietf-netmod-yang-model-classification and draft-wu-opsawg-service-model-explained 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, 30 Mar 2017 18:55:57 -0000 Hi, As just stated at the mic in the OPS Area meeting, I met with Dean Bogdanovic today to discuss the overlap/underlap between these two drafts. 1. We went through the text changes to draft-ietf-netmod-yang-model-classification and I am happy that changes in the -05 revision address the questions I have been asking. I do see two nits: a. draft-ietf-l3sm-l3vpn-service-model is now RFC 8049 b. The paragraph that references that document is perfect and correct, but may be slightly out of place as its current position suggests that it is a "Network Service model" where I think that Dean and I have agreed that it is actually one level higher (a business service model in his language) and so basically out of scope of this document. I would suggest moving this paragraph to be the last paragraph in Section 2.1. 2. draft-wu-opsawg-service-model-explained We will revise this document to align a little more closely with the language in draft-ietf-netmod-yang-model-classification and (more important) to not re-state (even in different language) what is in draft-ietf-netmod-yang-model-classification. I believe this will address all open worries in the document that have been expressed on the list. Thanks, Adrian From nobody Thu Mar 30 13:15:46 2017 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 D2AF21292FD for ; Thu, 30 Mar 2017 13:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7fvAILZYGYzw for ; Thu, 30 Mar 2017 13:15:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B823D126B72 for ; Thu, 30 Mar 2017 13:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=664; q=dns/txt; s=iport; t=1490904941; x=1492114541; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=irA0dchAdH4RusFIjrpy83JRuvx0hx1CBumvalxw3rc=; b=Xx4qO/qI1cjrin78W7khqvDy7EQVa+hlOfiYC5nIGoVDsaolm0b2zgg6 Y/t/jhbWGzT2GBsEAklG4+DCBFmSyiR4C6AL+FtBz2/KxoucgpA0IWMaG ZVu8fGPTZ/mPhCwUQ4uMbcbymVcmQkbZACQ4myCRBJbuW1EgjMeCZYnAd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AwBNZd1Y/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1aFTooRpySCDoYYg0Q/GAECAQEBAQEBAWsdC0IOhG+BCwImAl8NCAE?= =?us-ascii?q?BigeeBJAGgiaKVQEBAQcCJoELhUOCBYpEgl8BBJxqgVWQe4FkiHiGW5NtHziBB?= =?us-ascii?q?TsgFYc2JIQbhikBAQE?= X-IronPort-AV: E=Sophos;i="5.36,248,1486425600"; d="scan'208";a="403553634" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 20:15:41 +0000 Received: from [10.24.144.94] ([10.24.144.94]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2UKFeuM007394 for ; Thu, 30 Mar 2017 20:15:40 GMT To: "opsawg@ietf.org" From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <9a0d99fb-1c80-99ba-921d-426a208f7092@cisco.com> Date: Thu, 30 Mar 2017 16:15:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Comment on draft-pularikkal-opsawg-wifi-calling 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, 30 Mar 2017 20:15:45 -0000 Allow me to channel my fellow IETF NOC colleague Clemens and offer one comment on the WiFi calling draft. Add a bit on NAT. We found in Korea that someone was trying to use iPhone WiFi calling to Europe. Because we used a public IPv4 address space, the IPSec NAT detection algorithm found no NAT and used pure ESP for the tunnel. This particular provider had not seen this before and their firewall didn't allow for ESP (only tunneled udp/4500). If the draft could mention that some WiFi hotspots do not use NAT (especially in the IPv6 space) and to make sure that the proper allowance for security is taken, I think that would be helpful. Joe From nobody Thu Mar 30 21:40:45 2017 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 EBA1E127F0E; Thu, 30 Mar 2017 21:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RPlJ3CWkj13q; Thu, 30 Mar 2017 21:40:42 -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 5D6F4128C82; Thu, 30 Mar 2017 21:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10410; q=dns/txt; s=iport; t=1490935241; x=1492144841; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=40/9RtYCGhPxIRXz8B6SHB/8ti7NC53XROMoPe50+ms=; b=MiqSRNy/z7HfqEZa/jr3Lcpfj0ONTQzH8P4O5TPdyC2DipZhaxYEialb At4zqJGDGTG+2NsE4667j/NTYmStOnqnw+6ZP0DfN9nMU1hzFUpvipQ98 4EZEJYB1P8HCEGiZ41fjJCErTJX2tfABcstFUFnsmJ05c/rGdQn6H7SgG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAwD93N1Y/5NdJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuaGGBCweDW4oRkTWDA407hTGCDh8BCoUuSgIagx8/GAECAQE?= =?us-ascii?q?BAQEBAWsohRYCAQMBARsGSwsQAgEGAj8DAgICJQsUEQEBBAENBYoLDottnVuCJ?= =?us-ascii?q?opcAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYhTCIJihCYRATMKHQmCPy6CMQWJLJM?= =?us-ascii?q?+AYZ8hlGFAoF8GDyEVoNZhjiTbAEPEDh9CFsVQREBhEcdgWN1h2GBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,250,1486425600"; d="scan'208,217";a="216596732" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 04:40:40 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2V4edNb000610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 04:40:40 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 00:40:39 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 00:40:39 -0400 From: "Brian Weis (bew)" To: Tianran Zhou , Eliot Lear CC: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Thread-Topic: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 Thread-Index: AdKe9vAgYqk7rVgYSsewZPAvl6ONiALA4gKA Date: Fri, 31 Mar 2017 04:40:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.48.48] Content-Type: multipart/alternative; boundary="_000_DDA67D50ACDA49A69402F0803D3E1B09ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05 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, 31 Mar 2017 04:40:45 -0000 --_000_DDA67D50ACDA49A69402F0803D3E1B09ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkdmFuY2luZyB0aGlzIGRvY3VtZW50LCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5n IG1pbm9yIGNvbW1lbnRzLg0KDQooMSkgU2VjdGlvbiAxLjMuIExMRFAgc2hvdWxkIGJlIHJlZmVy ZW5jZWQgYXQgZmlyc3QgdXNlLiBUaGUgd29yZGluZyBhdCB0aGUgYmVnaW5uaW5nIG9mIFNlY3Rp b24gMTEgaXMgbmljZTogIklFRUU4MDIuMUFCIExpbmsgTGF5ZXIgRGlzY292ZXJ5IFByb3RvY29s IChMTERQKSBbSUVFRTgwMjFBQl3igJ0uDQoNCigyKSBTZWN0aW9uIDEuNC4gQW4gaW50ZXJlc3Rp bmcgcG9saWN5IGV4YW1wbGUgaXM6DQoNCkFsbG93IGFjY2VzcyB0byBob3N0IGNvbnRyb2xsZXIu ZXhhbXBsZS5jb208aHR0cDovL2NvbnRyb2xsZXIuZXhhbXBsZS5jb20+IHdpdGggUW9TIEFGMTEN Cg0KSSBkb27igJl0IHNlZSBob3cgUW9TIG1hcmtpbmdzIGFyZSBkZWZpbmVkIGluIE1VRC4gSWYg bm90LCB0aGVuIOKAnCB3aXRoIFFvUyBBRjEx4oCdIHNob3VsZCBiZSByZW1vdmVkLiBTdXBwb3J0 aW5nIFFvUyBtYXJraW5ncyB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0aG91Z2guDQoNCigzKSBTZWN0 aW9uIDEuNCBhbmQgYmV5b25kLiBUaGUgd29yZCDigJxhdXRob3JpdHnigJ0sIOKAnGF1dGhvcml0 eSBjb21wb25lbnTigJ0sIOKAnGF1dGhvcml0eSBzZWN0aW9u4oCdIGFyZSBhbGwgdXNlZCB0byBt ZWFuIHRoZSBzYW1lIHRoaW5nLCBidXQgd2l0aG91dCBmdXJ0aGVyIGV4cGxhbmF0aW9uIGFzIHRv IHdoYXQgdGhpcyBtZWFucy4gVGhlIGluY29uc2lzdGVuY3kgaXMgY29uZnVzaW5nLiBCdXQgbW9y ZSBpbXBvcnRhbnRseSwgaXQgaXNu4oCZdCBjbGVhciB0byB0aGUgcmVhZGVyIGluIHRob3NlIGVh cmxpZXIgc2VjdGlvbnMgdGhhdCBlYWNoIOKAnGF1dGhvcml0eSAqIiBpcyBhIGZvcndhcmQgcmVm ZXJlbmNlIHRvIHRoZSDigJxhdXRob3JpdHkgZWxlbWVudOKAnSBpbiB0aGUgVVJMIGRlZmluaXRp b24gKFNlY3Rpb24gNSkgIEl0IHdvdWxkIGNsZWFyZXIgaWYgdGhlc2UgcmVmZXJlbmNlcyBzYWlk IHNvbWV0aGluZyBsaWtlIOKAnGF1dGhvcml0eSBlbGVtZW50IG9mIHRoZSBNVUQgVVJM4oCdLg0K DQooNCkgU2VjdGlvbiAxLjYuIFJlZ2FyZGluZyB0aGlzIHRleHQ6ICJJbiB0aGUgY2FzZSBvZiBJ RUVFIDgwMi4xWCwgdGhlIHN3aXRjaCB3b3VsZCB0dW5uZWwgdGhlIFVSSSB2aWEgYSBjZXJ0aWZp Y2F0ZSDigKYu4oCdLiAgVGhlIFVSSSBpc27igJl0IHJlYWxseSDigJx0dW5uZWxlZOKAnS4gSG93 IGFib3V0LCAiSW4gdGhlIGNhc2Ugb2YgSUVFRSA4MDIuMVgsIHRoZSBzd2l0Y2ggd291bGQgcHJl c2VudCBhIGNlcnRpZmljYXRlIGNvbnRhaW5pbmcgdGhlIFVSSSDigKbigJ0uDQoNCig1KSBTZWN0 aW9uIDMuMi4gRm9yICJpdCBzaG91bGQgbm90IGJlIG5lY2Vzc2FyeSB0byByZXNpZ24gYSBNVUQg ZmlsZSB3aGVuIGEgbmV3IG9uZSBpcyByZWxlYXNlZOKAnSwgSSBiZWxpZXZlIHlvdSBtZWFuIHRo YXQgdGhlIE1VRCBmaWxlIGRvZXMgbm90IG5vdCBuZWVkIHRvIGJlIHNpZ25lZCBhZ2FpbiAo4oCc cmUtc2lnbuKAnSkuIE9yIGRvIHlvdSByZWFsbHkgbWVhbiB0aGF0IHRoZSBtYW51ZmFjdHVyZXIg d2lsbCDigJxyZXNpZ27igJ0gKGUuZy4sIOKAnGxlYXZl4oCdIG9yIOKAnHN0YW5kIGRvd27igJ0p IHRoZSBNVUQgZmlsZSBieSBtb3ZpbmcgaXQgdG8gdGhlIGFyY2hpdmFsIGxvY2F0aW9uPyBJZiBz bywgdGhpcyBuZWVkcyB0byBiZSBjbGVhcmVyLg0KDQooNikgU2VjdGlvbiAzLjEyLiBUaGlzIHNl Y3Rpb24gbWVudGlvbnMgInN0YW5kYXJkIGNsYXNzZXPigJ0uIFRoZXJl4oCZcyBzaG91bGQgYmUg YSByZWZlcmVuY2UgdG8gd2hhdCB0aG9zZSBjbGFzc2VzIHdvdWxkIGJlLCBvciBtb3JlIHRleHQg ZGVzY3JpYmluZyB3aGF0IGlzIGEg4oCcc3RhbmRhcmQgY2xhc3PigJ0uIFNob3VsZCB0aGVyZSBi ZSBhbiBJQU5BIHJlZ2lzdHJ5IG9mIOKAnHN0YW5kYXJkIGNsYXNzZXPigJ0/DQoNClRoYW5rcywN CkJyaWFuDQoNCg0KT24gTWFyIDE3LCAyMDE3LCBhdCAzOjE3IEFNLCBUaWFucmFuIFpob3UgPHpo b3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PiB3cm90 ZToNCg0KRGVhciBPUFNBV0csDQoNClRoaXMgaXMgYSBub3RpY2UgdG8gc3RhcnQgYSB0d28td2Vl ayBPUFNBV0cgV0cgbGFzdCBjYWxsIGZvciB0aGUgZG9jdW1lbnQ6DQoNCk1hbnVmYWN0dXJlciBV c2FnZSBEZXNjcmlwdGlvbiBTcGVjaWZpY2F0aW9uDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQvDQoNClBsZWFzZSByZWFkIHRoZSBhYm92ZSBk cmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVzLCBjb21tZW50cywgb3IgY29ycmVjdGlvbnMgdG8gdGhp cyBtYWlsaW5nIGxpc3QuDQpQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5z IGJ5IEZyaWRheSBNYXJjaCAzMSwgMjAxNy4NCg0KVGhhbmtzLA0KQ2hhaXJzDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBs aXN0DQpPUFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb3BzYXdnDQoNCi0tDQpCcmlhbiBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1z DQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb208bWFpbHRv OmJld0BjaXNjby5jb20+DQoNCg== --_000_DDA67D50ACDA49A69402F0803D3E1B09ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2238C225D650CE4E9A7D1C84B2F6017F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBzdXBwb3J0IGFkdmFuY2luZyB0 aGlzIGRvY3VtZW50LCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIG1pbm9yIGNvbW1lbnRzLg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KDEpIFNlY3Rp b24gMS4zLiBMTERQIHNob3VsZCBiZSByZWZlcmVuY2VkIGF0IGZpcnN0IHVzZS4gVGhlIHdvcmRp bmcgYXQgdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDExIGlzIG5pY2U6ICZxdW90O0lFRUU4MDIu MUFCIExpbmsgTGF5ZXIgRGlzY292ZXJ5IFByb3RvY29sIChMTERQKSBbSUVFRTgwMjFBQl3igJ0u PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4oMikgU2VjdGlvbiAxLjQuIEFuIGludGVyZXN0aW5nIHBvbGljeSBleGFtcGxlIGlzOjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMzMDE1NDQxODk1cHg7IiBjbGFzcz0iIj5B bGxvdyBhY2Nlc3MgdG8gaG9zdA0KPGEgaHJlZj0iaHR0cDovL2NvbnRyb2xsZXIuZXhhbXBsZS5j b20iIGNsYXNzPSIiPmNvbnRyb2xsZXIuZXhhbXBsZS5jb208L2E+IHdpdGggUW9TIEFGMTE8L3Nw YW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzMz MzAxNTQ0MTg5NXB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JIGRvbuKAmXQgc2VlIGhvdyBRb1MgbWFya2luZ3MgYXJlIGRlZmluZWQgaW4g TVVELiBJZiBub3QsIHRoZW4g4oCcJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMz MzMzMDE1NDQxODk1cHg7IiBjbGFzcz0iIj53aXRoIFFvUyBBRjExPC9zcGFuPuKAnSBzaG91bGQg YmUgcmVtb3ZlZC4gU3VwcG9ydGluZyBRb1MgbWFya2luZ3Mgd291bGQgYmUgYSBnb29kIGlkZWEg dGhvdWdoLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPigzKSBTZWN0aW9uIDEuNCBhbmQgYmV5b25kLiBUaGUg d29yZCDigJxhdXRob3JpdHnigJ0sIOKAnGF1dGhvcml0eSBjb21wb25lbnTigJ0sIOKAnGF1dGhv cml0eSBzZWN0aW9u4oCdIGFyZSBhbGwgdXNlZCB0byBtZWFuIHRoZSBzYW1lIHRoaW5nLCBidXQg d2l0aG91dCBmdXJ0aGVyIGV4cGxhbmF0aW9uIGFzIHRvIHdoYXQgdGhpcyBtZWFucy4gVGhlIGlu Y29uc2lzdGVuY3kgaXMgY29uZnVzaW5nLiBCdXQgbW9yZSBpbXBvcnRhbnRseSwgaXQgaXNu4oCZ dA0KIGNsZWFyIHRvIHRoZSByZWFkZXIgaW4gdGhvc2UgZWFybGllciBzZWN0aW9ucyB0aGF0IGVh Y2gg4oCcYXV0aG9yaXR5IComcXVvdDsgaXMgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUg4oCc YXV0aG9yaXR5IGVsZW1lbnTigJ0gaW4gdGhlIFVSTCBkZWZpbml0aW9uIChTZWN0aW9uIDUpJm5i c3A7IEl0IHdvdWxkIGNsZWFyZXIgaWYgdGhlc2UgcmVmZXJlbmNlcyBzYWlkIHNvbWV0aGluZyBs aWtlIOKAnGF1dGhvcml0eSBlbGVtZW50IG9mIHRoZSBNVUQgVVJM4oCdLiZuYnNwOzwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4oNCkgU2VjdGlvbiAxLjYuIFJlZ2FyZGluZyB0aGlzIHRleHQ6ICZxdW90O0luIHRoZSBjYXNl IG9mIElFRUUgODAyLjFYLCB0aGUgc3dpdGNoIHdvdWxkIHR1bm5lbCB0aGUgVVJJIHZpYSBhIGNl cnRpZmljYXRlIOKApi7igJ0uICZuYnNwO1RoZSBVUkkgaXNu4oCZdCByZWFsbHkg4oCcdHVubmVs ZWTigJ0uIEhvdyBhYm91dCwgJnF1b3Q7SW4gdGhlIGNhc2Ugb2YgSUVFRSA4MDIuMVgsIHRoZSBz d2l0Y2ggd291bGQgcHJlc2VudCBhIGNlcnRpZmljYXRlIGNvbnRhaW5pbmcNCiB0aGUgVVJJIOKA puKAnS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPig1KSBTZWN0aW9uIDMuMi4gRm9yICZxdW90O2l0IHNob3VsZCBub3QgYmUgbmVjZXNz YXJ5IHRvIHJlc2lnbiBhIE1VRCBmaWxlIHdoZW4gYSBuZXcgb25lIGlzIHJlbGVhc2Vk4oCdLCBJ IGJlbGlldmUgeW91IG1lYW4gdGhhdCB0aGUgTVVEIGZpbGUgZG9lcyBub3Qgbm90IG5lZWQgdG8g YmUgc2lnbmVkIGFnYWluICjigJxyZS1zaWdu4oCdKS4gT3IgZG8geW91IHJlYWxseSBtZWFuIHRo YXQgdGhlIG1hbnVmYWN0dXJlciB3aWxsIOKAnHJlc2lnbuKAnQ0KIChlLmcuLCDigJxsZWF2ZeKA nSBvciDigJxzdGFuZCBkb3du4oCdKSB0aGUgTVVEIGZpbGUgYnkgbW92aW5nIGl0IHRvIHRoZSBh cmNoaXZhbCBsb2NhdGlvbj8gSWYgc28sIHRoaXMgbmVlZHMgdG8gYmUgY2xlYXJlci48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPig2KSBT ZWN0aW9uIDMuMTIuIFRoaXMgc2VjdGlvbiBtZW50aW9ucyAmcXVvdDtzdGFuZGFyZCBjbGFzc2Vz 4oCdLiBUaGVyZeKAmXMgc2hvdWxkIGJlIGEgcmVmZXJlbmNlIHRvIHdoYXQgdGhvc2UgY2xhc3Nl cyB3b3VsZCBiZSwgb3IgbW9yZSB0ZXh0IGRlc2NyaWJpbmcgd2hhdCBpcyBhIOKAnHN0YW5kYXJk IGNsYXNz4oCdLiBTaG91bGQgdGhlcmUgYmUgYW4gSUFOQSByZWdpc3RyeSBvZiDigJxzdGFuZGFy ZCBjbGFzc2Vz4oCdPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmlhbjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMTcsIDIwMTcsIGF0IDM6MTcg QU0sIFRpYW5yYW4gWmhvdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5j b20iIGNsYXNzPSIiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5EZWFyIE9QU0FXRyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgT1BTQVdHIFdHIGxhc3QgY2FsbCBm b3IgdGhlIGRvY3VtZW50OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1hbnVmYWN0dXJl ciBVc2FnZSBEZXNjcmlwdGlvbiBTcGVjaWZpY2F0aW9uPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLyIg Y2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNh d2ctbXVkLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2UgcmVhZCB0aGUg YWJvdmUgZHJhZnQgYW5kIHNlbmQgYW55IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25z IHRvIHRoaXMgbWFpbGluZyBsaXN0LjxiciBjbGFzcz0iIj4NClBsZWFzZSBpbmRpY2F0ZSB5b3Vy IHN1cHBvcnQgb3IgY29uY2VybnMgYnkgRnJpZGF5IE1hcmNoIDMxLCAyMDE3LjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyw8YnIgY2xhc3M9IiI+DQpDaGFpcnM8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9QU0FXRyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQpPUFNBV0dAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29wc2F3ZzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS0mbmJzcDs8YnIg Y2xhc3M9IiI+DQpCcmlhbiBXZWlzPGJyIGNsYXNzPSIiPg0KU2VjdXJpdHksIENTRywgQ2lzY28g U3lzdGVtczxiciBjbGFzcz0iIj4NClRlbGVwaG9uZTogJiM0MzsxIDQwOCA1MjYgNDc5NjxiciBj bGFzcz0iIj4NCkVtYWlsOiA8YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgY2xhc3M9IiI+ YmV3QGNpc2NvLmNvbTwvYT4gPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DDA67D50ACDA49A69402F0803D3E1B09ciscocom_--