From nobody Tue Sep 5 05:16:34 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 AFD0B132941 for ; Tue, 5 Sep 2017 05:16:32 -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 Wvklu3wjRKIe for ; Tue, 5 Sep 2017 05:16:31 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A009132939 for ; Tue, 5 Sep 2017 05:16:31 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u26so18395999wma.0 for ; Tue, 05 Sep 2017 05:16:30 -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; bh=0bYsUZeYbzM4Z+NLUcnlTb+CTwNyStk9I334q7aI54Y=; b=wz4Tj3AFhGYcwGBqCEmKdG3hl5kACmPPQuFsP0pCG6FVt+N5NZVtkh7yGQ5p52Onic V41v8OjdPf1cG9yaMFxH6rJzpZQxb8muA20/T8+/omOQi6cjGyCxRSMQ9HeoTt3DaPQA wzY3/+7gDCYPFg93mlWB4RqSPkU+QsUlg2n1+R6hkUD73W4+r7IuBvqtlvOJ/dAjdF37 IPSVBbpc6bqeQ0Imk5+Rs7YDpyV/Ua3BV7ipeQ9RKKOjoSDnEV0uuB+2bgaq5bUPPGx7 gvj0QyJKZUV+cbSfsuCW6g5F7Je4pMZo5ItSkQGtRatq4RnAIxtQvjkZ6X4cfafC5GSc OlqA== 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; bh=0bYsUZeYbzM4Z+NLUcnlTb+CTwNyStk9I334q7aI54Y=; b=M/ryQMjFFtaMNAb4MB0XfP/C7pHFOdSlZBbaWxOqzSgrolaQbrMm+kqRt6zfKF0t9e wzQiRMSfx88C9z4PDC+w16MwUMKj8HHrdNHwYWBkvfQCgK0KVbRWhZZB1N5w/KcEb7hz zbTf0thAttxkwyRLT25F1dKdyBK1pY8J5u7vpz8O88bUlSA0qAqFu+e+kPKC1IMFXPao mHVYPHJBKs6tC4FTTUIfacXKMyP8zNlzJBbGOQ07GZz+hQb/oO/8sg9pZuFC2QZDeaQr uyBV19SvftZ8REOQPKA++oXqHLuunyts9jUspgOt7KNuxw6XE+V4ZzH4ScQQio15LekG MraQ== X-Gm-Message-State: AHPjjUgEfnVW509mP8N8JpObug+H3K0p9iMV3hz11yv3gFBquOaRKLf4 vl+e/siZPvOa4a1Z4rGLmSceilC0oeZBdCw= X-Google-Smtp-Source: ADKCNb5kKkWPnhhegSdGToilz7MV+QE0zCdAUY53v6hxfsgR1E0PrL3YZk6AmoICXYPECOc7Cq+YY1a+zLgFlOnA04g= X-Received: by 10.28.225.132 with SMTP id y126mr2397944wmg.119.1504613789010; Tue, 05 Sep 2017 05:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 5 Sep 2017 05:15:48 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Tue, 5 Sep 2017 08:15:48 -0400 Message-ID: To: opsawg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OPSAWG] Fwd: AD Review of draft-ietf-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: Tue, 05 Sep 2017 12:16:32 -0000 Apologies, I forgot to CC the WG. I'll also be asking Benoit to give it the once over, as he is much more familiar with this topic. W ---------- Forwarded message ---------- From: Warren Kumari Date: Mon, Sep 4, 2017 at 8:43 PM Subject: AD Review of draft-ietf-opsawg-service-model-explained To: draft-ietf-opsawg-service-model-explained.all@ietf.org Hi there, First off, thanks for a really well written document -- this is one of the cleanest AD reviews I've done. I do have some very minor grammar nits. I'd prefer a new version with these addressed, but they are all sufficiently minor that I'm also OK starting the LC as is. Please let me know which you'd prefer. 1: While unfortunate, I think many will not understand the q.v. in the Service definition in Section 2. Terms and Concepts. Perhaps break it out, or more clearly point where more info is to be found. 2: Section 6.3. Customer Service Model Work "The most advanced presents the L3VPN service..." - I'd suggest "Currently the most advanced presents the L3VPN service..." -- there may be another, more advanced one soon... The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason / Rational / format. Section Abstract This document describes service models as used within the IETF, and [O] IETF, and [P] IETF and [R] grammar Section 1. Introduction. Within the context of Software Defined Networking (SDN) [RFC7149] [RFC7426] YANG data models may be used on the interface between a [O] [RFC7426] YANG data models [P] [RFC7426], YANG data models [R] grammar Ultimately they could be used in online, software-driven dynamic systems, and eventually as part of an SDN system. [O] systems, and [P] systems and [R] grammar Equally, this document clarifies what a service model is not, and dispels some common misconceptions. [O] not, and [P] not and [R] grammar - I think. Section 2. Terms and Concepts An example of where such details are relevant to the customer are when they describe the behavior or interactions on the [O] are when [P] is when [R] subject/verb agreement ("An example [...] is [...]") The distinction between a customer service model and a service delivery model needs to be repeatedly clarified. A customer service [O] repeatedly clarified. [R] This seems like an odd thing to say. Maybe, "needs to be emphasized" or "bears repeating" instead? Section 4. Service Models in an SDN Context That is, there should be an independence between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service. The [O] That is, there should be an independence between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service. [P] That is, the behavior and functions that a customer requests should be independent of the technology that the network operator has available to deliver the service. [R] readability. Not sure if P is much better. Section 5. Possible Causes of Confusion SLAs are also linked to commercial terms with penalties and so forth, and so are also not good topics for [O] and so are also not good [P] and thus SLAs are also not good [R] grammar/clarity Section 6.1. Comparison With Network Service Models These are service delivery models as described in this document, that is, they [O] document, that is, they [P] document; that is, they [R] grammar are the models used on the interface between the Service Orchestrator or OSS/BSS and the Network Orchestrator as shown in Figure 3. Figure 1 of [RFC8199] can be modified to make this more clear and to add an additional example of a Network Service YANG model as shown in Figure 4. This figure illustrates a functional architecture and an [O] architecture and an [P] architecture, and an [R] grammar Section 6.2. Service Delivery and Network Element Model Work These models focus on how the network operator configures the network through protocols and devices to deliver a service. Some of these models are classified as service delivery models while [O] models while [P] models, while [R] grammar 6.4. The MEF Architecture This does not invalidate either approach, but only [O] approach, but [P] approach; [R] grammar (or "either approach, it only" ?) 7.2. Relationship to Policy As with commercial terms and SLAs discussed in Section 5 it is [O] Section 5 it is [P] Section 5, it is [R] grammar 7.3. Operator-Specific Features They also understood that should an individual network operator want to describe additional features (operator-specific features) they could do so by [O] that should an individual network operator want to describe additional features (operator-specific features) [P] that, should an individual network operator want to describe additional features (operator-specific features), [R] grammar 7.4. Supporting Multiple Services [O] It is an implementation and deployment choice whether all service models are processed by a single Service Orchestrator that can coordinate between the different services, or whether each service model is handled by a specialized Service Orchestrator able to provide tuned behavior for a specific service. [P] Whether each service model is handled by a specialized Service Orchestrator able to provide tuned behavior for a specific service or whether all service models are handled by a single Service Orchestrator is an implementation and deployment choice. [R] readability Section 8. Security Considerations Therefore it is important that the protocol interface used to exchange service request information between customer and network operator is subject to authorization, authentication, and encryption. Equally, all external intefaces, such as any of those between the [O] intefaces [P] interfaces [R] spelling W -- 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Sep 5 05:45:31 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 767BE132980 for ; Tue, 5 Sep 2017 05:45:30 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 nM8AKCxYifMz for ; Tue, 5 Sep 2017 05:45:27 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BAC1329AB for ; Tue, 5 Sep 2017 05:45:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v85CjOaq031701; Tue, 5 Sep 2017 13:45:24 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v85CjMvo031652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2017 13:45:23 +0100 Reply-To: From: "Adrian Farrel" To: "'Warren Kumari'" , References: In-Reply-To: Date: Tue, 5 Sep 2017 13:45:20 +0100 Message-ID: <063801d32644$d65b0fc0$83112f40$@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: AQH7Kyvs+tH/F4htDHmBhyx05xyzfwJusmlFokK9adA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23304.006 X-TM-AS-Result: No--21.477-10.0-31-10 X-imss-scan-details: No--21.477-10.0-31-10 X-TMASE-MatchedRID: 1ZHks2aQIkinykMun0J1wvHkpkyUphL9Ud7Bjfo+5jRm60OoujMOyNLu X2hj/M7U1EZYnCnBeLiGCaNfXtMBMOFGL6eX5d7bT7jCYv2QJPF6ABsdgB/A3WsXlULOq+TgKDk R2MDyn9zzaPp0zwpDaK/6/0DnZa3nq5plusWPmZhjoaO27r+3fX5ErfRqpilVZ5yuplze9ptqMI sdN+1tA/bEOe725RFi+X6JFUGKUhekIJwm8HcuFdxajlW+zwxCWDdWpJMntKjjsTquy0JRiz+2w a/V3o/KlcNil5Jf4i/trTvo40oHftK5cuk2o4lJy7TSWcbz49YfN1sSaNSB9Q9rNVSJxlY+YNtQ Bww5RnQ/2QaxJIKKIqTtRiXhPq5La6E59IxHGX9+H/Q3vgskAqFI/hOhKe2iCVuEXtlNqcv0T3R isbtv4381JtMs2RVQWLG9CvT5n8wwH8qwXC+TQS0x8J2DopEN6KbGBEfATCaQS5Fh6/hkz9rKbe LV7rdXRxnoImeRZKzW0e5KCL9fbq0ZS7JYIH8qJ7VPmvVUDciagpdUd+Iwzx+OicpPbfIdNBlMy mEzIhLYVvr1GfpNDpy4Ugasr2m9ehHR0rDYUtloMLOoNHsM9maq8BZOZSelpp+LQOi8dUWd1W7n 1XTpWGILs6/GamoNTIfHd1sFGgJ7pSYlG/A2Xsdt9cf9BUOgkk5xcxBziMER34ro7k23nfNvmSa CnjTlt+odoSua73aRk6XtYogiarQ/aqQZTRfKVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo Archived-At: Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Tue, 05 Sep 2017 12:45:30 -0000 Warren, thanks. Updating now. A > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: 05 September 2017 13:16 > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: AD Review of draft-ietf-opsawg-service-model- > explained > > Apologies, I forgot to CC the WG. > > I'll also be asking Benoit to give it the once over, as he is much > more familiar with this topic. > W > > ---------- Forwarded message ---------- > From: Warren Kumari > Date: Mon, Sep 4, 2017 at 8:43 PM > Subject: AD Review of draft-ietf-opsawg-service-model-explained > To: draft-ietf-opsawg-service-model-explained.all@ietf.org > > > Hi there, > > First off, thanks for a really well written document -- this is one of > the cleanest AD reviews I've done. > I do have some very minor grammar nits. > I'd prefer a new version with these addressed, but they are all > sufficiently minor that I'm also OK starting the LC as is. Please let > me know which you'd prefer. > > > > > 1: While unfortunate, I think many will not understand the q.v. in the > Service definition in Section 2. Terms and Concepts. Perhaps break it > out, or more clearly point where more info is to be found. > > 2: Section 6.3. Customer Service Model Work > "The most advanced presents the L3VPN service..." - I'd suggest > "Currently the most advanced presents the L3VPN service..." -- there > may be another, more advanced one soon... > > The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason > / Rational / format. > > > Section Abstract > This document describes service models as used within the IETF, and > [O] IETF, and > [P] IETF and > [R] grammar > > > Section 1. Introduction. > > Within the context of Software Defined Networking (SDN) [RFC7149] > [RFC7426] YANG data models may be used on the interface between a > [O] [RFC7426] YANG data models > [P] [RFC7426], YANG data models > [R] grammar > > Ultimately they could be used in online, software-driven dynamic > systems, and eventually as part of an SDN system. > [O] systems, and > [P] systems and > [R] grammar > > Equally, this document clarifies what a service model is > not, and dispels some common misconceptions. > [O] not, and > [P] not and > [R] grammar - I think. > > > > Section 2. Terms and Concepts > > An example of where such details are relevant to the customer > are when they describe the behavior or interactions on the > [O] are when > [P] is when > [R] subject/verb agreement ("An example [...] is [...]") > > > The distinction between a customer service model and a service > delivery model needs to be repeatedly clarified. A customer service > > [O] repeatedly clarified. > [R] This seems like an odd thing to say. Maybe, "needs to be > emphasized" or "bears repeating" instead? > > > Section 4. Service Models in an SDN Context > > That is, there should be an independence between the > behavior and functions that a customer requests and the technology > that the network operator has available to deliver the service. The > [O] That is, there should be an independence between the behavior and > functions that a customer requests and the technology that the network > operator has available to deliver the service. > [P] That is, the behavior and functions that a customer requests > should be independent of the technology that the network operator has > available to deliver the service. > [R] readability. Not sure if P is much better. > > > Section 5. Possible Causes of Confusion > > SLAs are also linked to commercial terms > with penalties and so forth, and so are also not good topics for > [O] and so are also not good > [P] and thus SLAs are also not good > [R] grammar/clarity > > > Section 6.1. Comparison With Network Service Models > These are > service delivery models as described in this document, that is, they > > [O] document, that is, they > [P] document; that is, they > [R] grammar > > are the models used on the interface between the Service Orchestrator > or OSS/BSS and the Network Orchestrator as shown in Figure 3. > > Figure 1 of [RFC8199] can be modified to make this more clear and to > add an additional example of a Network Service YANG model as shown in > Figure 4. This figure illustrates a functional architecture and an > > [O] architecture and an > [P] architecture, and an > [R] grammar > > Section 6.2. Service Delivery and Network Element Model Work > > These models focus on how the network operator configures > the network through protocols and devices to deliver a service. Some > of these models are classified as service delivery models while > > [O] models while > [P] models, while > [R] grammar > > 6.4. The MEF Architecture > > This does not invalidate either approach, but only > > [O] approach, but > [P] approach; > [R] grammar (or "either approach, it only" ?) > > 7.2. Relationship to Policy > > As with commercial terms and SLAs discussed in Section 5 it is > > [O] Section 5 it is > [P] Section 5, it is > [R] grammar > > > 7.3. Operator-Specific Features > > They also understood > that should an individual network operator want to describe > additional features (operator-specific features) they could do so by > > [O] that should an individual network operator want to describe > additional features (operator-specific features) > > [P] that, should an individual network operator want to describe > additional features (operator-specific features), > [R] grammar > > > 7.4. Supporting Multiple Services > > [O] It is an implementation and deployment choice whether all service > > models are processed by a single Service Orchestrator that can > coordinate between the different services, or whether each service > model is handled by a specialized Service Orchestrator able to > provide tuned behavior for a specific service. > [P] Whether each service model is handled by a specialized Service > Orchestrator able to provide tuned behavior for a specific service or > whether all service models are handled by a single Service > Orchestrator is an implementation and deployment choice. > [R] readability > > > Section 8. Security Considerations > > Therefore it is important that the protocol interface used to > exchange service request information between customer and network > operator is subject to authorization, authentication, and encryption. > Equally, all external intefaces, such as any of those between the > > [O] intefaces > [P] interfaces > [R] spelling > > > > > W > > > > -- > 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 > > > -- > 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 > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Sep 5 07:21:43 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 53660132CE7; Tue, 5 Sep 2017 07:21:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150462129529.14420.2242778176797980839@ietfa.amsl.com> Date: Tue, 05 Sep 2017 07:21:35 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-model-explained-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 14:21:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Service Models Explained Authors : Qin Wu Will Liu Adrian Farrel Filename : draft-ietf-opsawg-service-model-explained-03.txt Pages : 22 Date : 2017-09-05 Abstract: The IETF has produced many data modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF, and also shows where a service model might fit into a Software Defined Networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-service-model-explained-03 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model-explained-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-model-explained-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 5 07:31:57 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 3FAF2132D0D for ; Tue, 5 Sep 2017 07:31: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 AO34YkZSR4t2 for ; Tue, 5 Sep 2017 07:31:53 -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 92B55132C49 for ; Tue, 5 Sep 2017 07:31: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 v85EVpto015697; Tue, 5 Sep 2017 15:31:51 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v85EVnDo015691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2017 15:31:50 +0100 Reply-To: From: "Adrian Farrel" To: "'Warren Kumari'" , References: In-Reply-To: Date: Tue, 5 Sep 2017 15:31:47 +0100 Message-ID: <066d01d32653$b547f7d0$1fd7e770$@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: AQH7Kyvs+tH/F4htDHmBhyx05xyzfwJusmlFokK+ZXA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23304.007 X-TM-AS-Result: No--6.016-10.0-31-10 X-imss-scan-details: No--6.016-10.0-31-10 X-TMASE-MatchedRID: Rp71wniPtoPRhEyb9f1sjvHkpkyUphL98GRhP/nTHNaTMTaQzhvoeucD DzKnTzUs8Tf7QBnKJMTNKZccbgFfqlkb4pg11AKqU+OjsPhIWDghpWQUitAWG+OxOq7LQlGLP7b Br9Xej8rpiWLSyZ8lkeTtIFjW0OaXMvc4FC3sMGb9vE/QVDV5ISNCRG3jSFiWYXvKrYW+zbcGvz VmOA+OndhWmHoPNNsHdTXa9VSD0MSAXaIZA5v/Tcu00lnG8+PWHzdbEmjUgfUVGU3zNNLOPnzON prx10+fanfXtrIQ3IXZe+wUej5whzcDLA95do+zQpxiLlDD9FUQJvY8X/Kxm7V5fSMRD1zqINVf 6u18qEXKwT8GWWE9Oja8LJ6qWrSSmFozpQIyI+tK2kj7j4ouAKgkPVIChYLxvyvZgplq5gYNqOn m5wgG4PmOqTud8R8ojPvoMzvFhRCpd5AcQEjSO5YsKSXWWrsHsEf8CpnIYtnYCfmDULr78mtCcS werg4mLwDAy0mgbkmRa8X3KCoywU7D8XzVBFmiwkMSqacJzSu45ODp7JI8vmtEzrC9eANp3Rfsk ShJlmpbxi+1blYThEu9yaCA0I5AyM4rdnSorj+hhgMpt6+x7SzjhVPXPQf4J870fpj93L4Dkd7W QNL44uLzNWBegCW2XC3N7C7YzrdWRVlrjsKO8N0H8LFZNFG7CKFCmhdu5cWi9dK0cf3u4sD7RMv ODTtVKKvxT9hVXGXSqPjnX0qxIqtmIDXdiaDZgs8A1MZL0FPoyyA1LMxdK2zecVenqujxxaOw+V d1Z9mRzy9lhw/CZKG6tVpjWHJfjF1XCR4TdrdTI6qsXPa6iJ6oP1a0mRIj Archived-At: Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Tue, 05 Sep 2017 14:31:56 -0000 Hi again... > 1: While unfortunate, I think many will not understand the q.v. in the > Service definition in Section 2. Terms and Concepts. Perhaps break it > out, or more clearly point where more info is to be found. Yeah, my mistake for writing in a language that has been dead for 2000 years :-) Added proper pointer. > 2: Section 6.3. Customer Service Model Work > "The most advanced presents the L3VPN service..." - I'd suggest > "Currently the most advanced presents the L3VPN service..." -- there > may be another, more advanced one soon... :-) Meant "most advanced through the IETF process." But anyway... OLD Several initiatives within the IETF are developing customer service models. The most advanced presents the L3VPN service as described by a network operator to a customer. The L3SM is described as in Figure 5 which is reproduced from [RFC8049]. As can be seen, the L3SM is a customer service model as described in this document. NEW Several initiatives within the IETF are developing customer service models. The L3SM presents the L3VPN service as described by a network operator to a customer. Figure 5, which is reproduced from [RFC8049], shows that the L3SM is a customer service model as described in this document. END > The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason > / Rational / format. > > Section Abstract > This document describes service models as used within the IETF, and > [O] IETF, and > [P] IETF and > [R] grammar Debateable and left to RFC Ed for house style. > Section 1. Introduction. > > Within the context of Software Defined Networking (SDN) [RFC7149] > [RFC7426] YANG data models may be used on the interface between a > [O] [RFC7426] YANG data models > [P] [RFC7426], YANG data models > [R] grammar You're just moving my commas from one place to another. But, yes. > Ultimately they could be used in online, software-driven dynamic > systems, and eventually as part of an SDN system. > [O] systems, and > [P] systems and > [R] grammar See? But leaving this one to RFC Ed as well. > Equally, this document clarifies what a service model is > not, and dispels some common misconceptions. > [O] not, and > [P] not and > [R] grammar - I think. Ditto > Section 2. Terms and Concepts > > An example of where such details are relevant to the customer > are when they describe the behavior or interactions on the > [O] are when > [P] is when > [R] subject/verb agreement ("An example [...] is [...]") Yes. I feel bad about this one. > The distinction between a customer service model and a service > delivery model needs to be repeatedly clarified. A customer service > > [O] repeatedly clarified. > [R] This seems like an odd thing to say. Maybe, "needs to be > emphasized" or "bears repeating" instead? Was my bitterness showing through? s/repeatedly clarified/clarified/ > Section 4. Service Models in an SDN Context > > That is, there should be an independence between the > behavior and functions that a customer requests and the technology > that the network operator has available to deliver the service. The > [O] That is, there should be an independence between the behavior and > functions that a customer requests and the technology that the network > operator has available to deliver the service. > [P] That is, the behavior and functions that a customer requests > should be independent of the technology that the network operator has > available to deliver the service. > [R] readability. Not sure if P is much better. OLD That is, there should be an independence between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service. NEW That is, the technology that the network operator has available to deliver the service should not influence the behavior and functions that a customer requests. END > Section 5. Possible Causes of Confusion > > SLAs are also linked to commercial terms > with penalties and so forth, and so are also not good topics for > [O] and so are also not good > [P] and thus SLAs are also not good > [R] grammar/clarity OK > Section 6.1. Comparison With Network Service Models > These are > service delivery models as described in this document, that is, they > > [O] document, that is, they > [P] document; that is, they > [R] grammar OK > are the models used on the interface between the Service Orchestrator > or OSS/BSS and the Network Orchestrator as shown in Figure 3. > > Figure 1 of [RFC8199] can be modified to make this more clear and to > add an additional example of a Network Service YANG model as shown in > Figure 4. This figure illustrates a functional architecture and an > > [O] architecture and an > [P] architecture, and an > [R] grammar Yes. Now you want to put a comma in for exactly the construction you wanted to remove them from before :-) Here I agree with you. > Section 6.2. Service Delivery and Network Element Model Work > > These models focus on how the network operator configures > the network through protocols and devices to deliver a service. Some > of these models are classified as service delivery models while > > [O] models while > [P] models, while > [R] grammar OK > 6.4. The MEF Architecture > > This does not invalidate either approach, but only > > [O] approach, but > [P] approach; > [R] grammar (or "either approach, it only" ?) OLD This does not invalidate either approach, but only observes that they are different. NEW This does not invalidate either approach: it only observes that they are different approaches. END > 7.2. Relationship to Policy > > As with commercial terms and SLAs discussed in Section 5 it is > > [O] Section 5 it is > [P] Section 5, it is > [R] grammar OK > 7.3. Operator-Specific Features > > They also understood > that should an individual network operator want to describe > additional features (operator-specific features) they could do so by > > [O] that should an individual network operator want to describe > additional features (operator-specific features) > [P] that, should an individual network operator want to describe > additional features (operator-specific features), > [R] grammar OK > 7.4. Supporting Multiple Services > > [O] It is an implementation and deployment choice whether all service > models are processed by a single Service Orchestrator that can > coordinate between the different services, or whether each service > model is handled by a specialized Service Orchestrator able to > provide tuned behavior for a specific service. > [P] Whether each service model is handled by a specialized Service > Orchestrator able to provide tuned behavior for a specific service or > whether all service models are handled by a single Service > Orchestrator is an implementation and deployment choice. > [R] readability Good > Section 8. Security Considerations > > Therefore it is important that the protocol interface used to > exchange service request information between customer and network > operator is subject to authorization, authentication, and encryption. > Equally, all external intefaces, such as any of those between the > > [O] intefaces > [P] interfaces > [R] spelling OK Posted. Thanks, Adrian From nobody Tue Sep 5 14:17:38 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 E5D34132E33 for ; Tue, 5 Sep 2017 14:17:36 -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 KVnRlypIJNnd for ; Tue, 5 Sep 2017 14:17:34 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8995E132E1E for ; Tue, 5 Sep 2017 14:17:33 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u26so24117944wma.0 for ; Tue, 05 Sep 2017 14:17:33 -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=DElHIjJzcvP69P4lpKA3uRVoVzOURhgZhuLJb25pjj0=; b=C9oBcWTvLkyenO+ajHwGrc0joIMvSeQbxREEmpyrCEciLP99hSMJCoAvU9aqRnSDLF 8etXEMnoZIzHhjQj3G3eQ0bYDLWCKHAbdjKOtyHLLB/YjUAbSaLPZgOMyOi1fmFR6APE lRcHRUc8VPQx2XpP0FevP9aST0RmFrhqV5PE2C2T62M4DGRer1gP/voQY4FXuhFwKE+S jBwe5lfBqQdiwY98fc1xH/K8TbxagbZtYRobUGBc8h3CTRVkAsc1sRjlQQlP8xd3FS12 m3AI827pjgdOalvSFkWAzqcJnS+8hV9XW2kVcw+eOV5AMK/HYu2eVyo6TCxXmPH/IncE 2eOQ== 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=DElHIjJzcvP69P4lpKA3uRVoVzOURhgZhuLJb25pjj0=; b=Hwkyg2oU89kQFGVwCm5A/PX92ErAv1LR1al/fPdsIvtK+0xToxBdN7wy22ye8Y5vV8 yZaMBgH3fGP03qK4IpDZ6bXz1X88ycmrYBm/hKF2Q4/g1UI9FFwUkyp+18MtTUFt0gkW RRIi2qUzXl2wm9l9R3Z6GBCbyjs4PAUeqGO6iP/DoyfiADV85ddunmTSheJy00p1FIKi 3dQcx00Q5D1FpGS3N14yzZp9GYZVCC3o4JEprlGE8vQJvsKs55OvGKrLssK+v7u3KLLF jMb6xYRcvB6HZB/8URWEw1ylBFT6BBeh2ICGBYdgVNj1SSQmwVGqAIyar6PsiqUIKmeZ wXFA== X-Gm-Message-State: AHPjjUj2wcQCRtjlJeeEJN22Eyy+KhBslI0nlhLghS26jvjK6z3+usE3 CJ2ga46Z6KsVpFah0whgskgHK3X8aEe9cSypMA== X-Google-Smtp-Source: ADKCNb52+maT//gPjHFst+E5hfnywzj1IcSv0WnRP0Lw6nteRYl+4Pebf8YuFeDmZvxT/XgA5zadRzDKCuPOdQmrLbw= X-Received: by 10.28.93.146 with SMTP id r140mr168768wmb.133.1504646251791; Tue, 05 Sep 2017 14:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 5 Sep 2017 14:16:50 -0700 (PDT) In-Reply-To: <066d01d32653$b547f7d0$1fd7e770$@olddog.co.uk> References: <066d01d32653$b547f7d0$1fd7e770$@olddog.co.uk> From: Warren Kumari Date: Tue, 5 Sep 2017 17:16:50 -0400 Message-ID: To: Adrian Farrel Cc: opsawg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Tue, 05 Sep 2017 21:17:37 -0000 On Tue, Sep 5, 2017 at 10:31 AM, Adrian Farrel wrote: > Hi again... > >> 1: While unfortunate, I think many will not understand the q.v. in the >> Service definition in Section 2. Terms and Concepts. Perhaps break it >> out, or more clearly point where more info is to be found. > > Yeah, my mistake for writing in a language that has been dead for 2000 years :-) > > Added proper pointer. > >> 2: Section 6.3. Customer Service Model Work >> "The most advanced presents the L3VPN service..." - I'd suggest >> "Currently the most advanced presents the L3VPN service..." -- there >> may be another, more advanced one soon... > > :-) > > Meant "most advanced through the IETF process." But anyway... Ah, I *so* didn't get that... > > OLD > Several initiatives within the IETF are developing customer service > models. The most advanced presents the L3VPN service as described by > a network operator to a customer. The L3SM is described as in > Figure 5 which is reproduced from [RFC8049]. As can be seen, the > L3SM is a customer service model as described in this document. > NEW > Several initiatives within the IETF are developing customer service > models. The L3SM presents the L3VPN service as described by > a network operator to a customer. Figure 5, which is reproduced > from [RFC8049], shows that the L3SM is a customer service > model as described in this document. > END > >> The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason >> / Rational / format. >> >> Section Abstract >> This document describes service models as used within the IETF, and >> [O] IETF, and >> [P] IETF and >> [R] grammar > > Debateable and left to RFC Ed for house style. > >> Section 1. Introduction. >> >> Within the context of Software Defined Networking (SDN) [RFC7149] >> [RFC7426] YANG data models may be used on the interface between a >> [O] [RFC7426] YANG data models >> [P] [RFC7426], YANG data models >> [R] grammar > > You're just moving my commas from one place to another. Yes, yes I am. You gotta met me have *some* fun! > > But, yes. > >> Ultimately they could be used in online, software-driven dynamic >> systems, and eventually as part of an SDN system. >> [O] systems, and >> [P] systems and >> [R] grammar > > See? > But leaving this one to RFC Ed as well. > >> Equally, this document clarifies what a service model is >> not, and dispels some common misconceptions. >> [O] not, and >> [P] not and >> [R] grammar - I think. > > Ditto > >> Section 2. Terms and Concepts >> >> An example of where such details are relevant to the customer >> are when they describe the behavior or interactions on the >> [O] are when >> [P] is when >> [R] subject/verb agreement ("An example [...] is [...]") > > Yes. I feel bad about this one. https://imgflip.com/i/1vcf6j :-P > >> The distinction between a customer service model and a service >> delivery model needs to be repeatedly clarified. A customer service >> >> [O] repeatedly clarified. >> [R] This seems like an odd thing to say. Maybe, "needs to be >> emphasized" or "bears repeating" instead? > > Was my bitterness showing through? > > s/repeatedly clarified/clarified/ > >> Section 4. Service Models in an SDN Context >> >> That is, there should be an independence between the >> behavior and functions that a customer requests and the technology >> that the network operator has available to deliver the service. The >> [O] That is, there should be an independence between the behavior and >> functions that a customer requests and the technology that the network >> operator has available to deliver the service. >> [P] That is, the behavior and functions that a customer requests >> should be independent of the technology that the network operator has >> available to deliver the service. >> [R] readability. Not sure if P is much better. > > OLD > That is, there should be an independence between the > behavior and functions that a customer requests and the technology > that the network operator has available to deliver the service. > NEW > That is, the technology that the network operator has available to > deliver the service should not influence the behavior and functions that > a customer requests. > END > >> Section 5. Possible Causes of Confusion >> >> SLAs are also linked to commercial terms >> with penalties and so forth, and so are also not good topics for >> [O] and so are also not good >> [P] and thus SLAs are also not good >> [R] grammar/clarity > > OK > >> Section 6.1. Comparison With Network Service Models >> These are >> service delivery models as described in this document, that is, they >> >> [O] document, that is, they >> [P] document; that is, they >> [R] grammar > > OK > >> are the models used on the interface between the Service Orchestrator >> or OSS/BSS and the Network Orchestrator as shown in Figure 3. >> >> Figure 1 of [RFC8199] can be modified to make this more clear and to >> add an additional example of a Network Service YANG model as shown in >> Figure 4. This figure illustrates a functional architecture and an >> >> [O] architecture and an >> [P] architecture, and an >> [R] grammar > > Yes. Now you want to put a comma in for exactly the construction you wanted to > remove them from before :-) > https://media3.giphy.com/media/bA5EUCvMgDBkc/200_s.gif > Here I agree with you. > >> Section 6.2. Service Delivery and Network Element Model Work >> >> These models focus on how the network operator configures >> the network through protocols and devices to deliver a service. Some >> of these models are classified as service delivery models while >> >> [O] models while >> [P] models, while >> [R] grammar > > OK > >> 6.4. The MEF Architecture >> >> This does not invalidate either approach, but only >> >> [O] approach, but >> [P] approach; >> [R] grammar (or "either approach, it only" ?) > > OLD > This does not invalidate either approach, but only observes that they are > different. > NEW > This does not invalidate either approach: it only observes that they are > different approaches. > END > >> 7.2. Relationship to Policy >> >> As with commercial terms and SLAs discussed in Section 5 it is >> >> [O] Section 5 it is >> [P] Section 5, it is >> [R] grammar > > OK > >> 7.3. Operator-Specific Features >> >> They also understood >> that should an individual network operator want to describe >> additional features (operator-specific features) they could do so by >> >> [O] that should an individual network operator want to describe >> additional features (operator-specific features) >> [P] that, should an individual network operator want to describe >> additional features (operator-specific features), >> [R] grammar > > OK > >> 7.4. Supporting Multiple Services >> >> [O] It is an implementation and deployment choice whether all service >> models are processed by a single Service Orchestrator that can >> coordinate between the different services, or whether each service >> model is handled by a specialized Service Orchestrator able to >> provide tuned behavior for a specific service. >> [P] Whether each service model is handled by a specialized Service >> Orchestrator able to provide tuned behavior for a specific service or >> whether all service models are handled by a single Service >> Orchestrator is an implementation and deployment choice. >> [R] readability > > Good > >> Section 8. Security Considerations >> >> Therefore it is important that the protocol interface used to >> exchange service request information between customer and network >> operator is subject to authorization, authentication, and encryption. >> Equally, all external intefaces, such as any of those between the >> >> [O] intefaces >> [P] interfaces >> [R] spelling > > OK > > Posted. > Thanks, > Adrian > Thank you very much. W -- 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 Wed Sep 6 08:17:55 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 C5B08132494; Wed, 6 Sep 2017 08:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-opsawg-service-model-explained@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou , opsawg@ietf.org, zhoutianran@huawei.com, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150471106777.15216.17661654177317542804.idtracker@ietfa.amsl.com> Date: Wed, 06 Sep 2017 08:17:47 -0700 Archived-At: Subject: [OPSAWG] Last Call: (Service Models Explained) to Informational RFC 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: Wed, 06 Sep 2017 15:17:48 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Service Models Explained' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF has produced many data modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF, and also shows where a service model might fit into a Software Defined Networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Sep 7 08:51:37 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 E55AD132F84; Thu, 7 Sep 2017 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eALaR1njMpz2; Thu, 7 Sep 2017 08:51:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDA813219F; Thu, 7 Sep 2017 08:51:25 -0700 (PDT) Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v87FpKXH044717 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Sep 2017 10:51:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local To: Eliot Lear , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> From: Robert Sparks Message-ID: <3570a07d-6786-3077-f1a7-4ec61a4bf9d0@nostrum.com> Date: Thu, 7 Sep 2017 10:51:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> Content-Type: multipart/alternative; boundary="------------35768AF4B247EF2DF66EB037" Content-Language: en-US Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 07 Sep 2017 15:51:30 -0000 This is a multi-part message in MIME format. --------------35768AF4B247EF2DF66EB037 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Apologies for being a little laggy - Some comments inline. On 8/31/17 2:07 PM, Eliot Lear wrote: > > Robert, > > As I wrote earlier, this was a great review.  Thanks for that. Please > see below. > > > On 8/30/17 7:21 PM, Robert Sparks wrote: >> Reviewer: Robert Sparks >> Review result: Almost Ready >> >> This is an exciting concept, and the draft overall is approachable. I >> have identified a few areas I think need more detail, and have a >> longish list of nits (please don't take that to be negative). >> >> ==Issues== >> >> I find the structure of the introduction unclear. Please consider >> reworking it. I would suggest even more succinctly listing goals and >> constraints, and then intended applicability (these things are in the >> current text, but I think you can render them much more efficiently). In >> particular, the argument that implementers of things are incented only to >> provide the minimal amount of behavior to get their thingyness could be >> more strongly highlighted. > > I've received conflicting reviews here.  Most like what's there and > while I'm open to specific textual changes, a full reorganization > would likely be destabilizing. I disagree. I know it's work, but if you read this as an implementer, I think it would pay back. This is a stylistic suggestion though, so take it only as my opinion. > >> The document proposes "reputation services". It needs more words about >> whether those exist, and what scopes the architecture imagines (an >> enterprise might have a different idea of a reputation service than a >> residence). There is a notion of "decent web reputations" in the security >> considerations section. Who determines that? The security considerations >> section should talk about attacks against the reputation services. > > This is discussed in security considerations: >> It may also be useful >> to limit retrieval of MUD URLs to only those sites that are known to >> have decent web reputations. > What I am specifically talking about are web or domain reputation > services.  These are pretty commonplace today.  Your browser uses one, > and numerous companies offer them, including our own.  But to be > clearer, I propose to use the term "web or domain reputation > services", so that people know what I'm talking about. I'll look at the diff. > > > > >> In the first paragraph of Section 2, it's not clear if you are trying >> to restrict the models to only those in the two documents in the list >> following the paragraph. > > Right.  This was caught earlier, and I'll correct. > >> I am not a YANG doctor, so this may be in the weeds, but it feels like >> there's a discrepancy between the diagram at the end of section 2 and the >> element definitions in section 3. In particular 3.7 doesn't seem to align >> with what the diagram or the example in Appendix B uses. Should you be >> defining "from-device-policy" and "to-device-policy" instead of >> "packet-direction"? (I'm wondering if 3.7 reflects an older design?) > > Yupper.  Fixed (I think). >> At section 3.13, the description of my-controller is not quite right. >> This bit signals to the mud controller to use a mapping that it knows >> about or creates. Something else established that class (and maybe gave >> it a name). I talked about this with Eliot and he has a better >> description to use. > > Proposed text: > >> This null-valued node signals to the MUD controller to use whatever >> mapping it has for this URL to a controller class".  This may require >> prompting the administrator for class members.  Future work should >> seek to automate membership management. ack > >> It's not clear to me that this is a good use of .well-known. I suggest >> getting an expert review on the proposed usage. (I had a quick >> conversation with Mark Nottingham and got some initial feedback that >> I'm passing along here. I'm sure there's more that an in-depth review >> would identify.) Why wouldn't a URI template (RFC6570) do the job? >> Rather than use RFC3986's query, consider pointing to HTML5 (which >> would bring the more familiar key=value format). > > The key issue is that we want to externalize versioning AND hardcode > it in the URL so that it's independent of transport. Remember, there > is very little information exchange between the Thing and the network, > and I will claim that's a good thing. Sure, and URL templates would _do_ that, no? But please take that argument up with folks like Mark. > >> The document needs to say more about how HTTP is used. I assume you only >> intend to use GET, and that you expect redirects to be followed, and that >> nothing special needs to be considered with caching? The document needs >> to be explicit about it. Take a look at >> . (There's been some conversation >> about it on the art list, so Eliot, at least, is already aware of it - >> see) > > What we say today is the following; >> Processing of this >> URL occurs as specified in {{RFC2818}} and {{RFC3986}}. > There is one aspect of caching semantics we should probably capture, > which is that the cache-validity period should exceed the HTTP cache > or expiry period as specified by max-age or Expires. Does that sound > about right to you? Goes in the right direction. Do you expect POST to work with this? > >> I think there needs to be more discussion of the PKI used for signing MUD >> files. > > We do have some discussion in Section 12.2.  I'm happy to add an > additional sentence or two, but would seek guidance on where you think > we're missing. So, are you expecting to reuse the web PKI here? Will the MUD files be signed with the same credentials used by the HTTP server? I'm thinking you aren't, and are waving your hands at where trust lies with the recommendation that signers be validated directly etc. Either way, I think you need to be more explicit and that what you expect for establishing trust is going to take more than a couple of sentences. > >> Consider discussing whether the stacks used by typical things will let >> them add DHCP options (or include bits in the other protocols being >> enabled). If it's well known (I can't say) that these stacks typically >> _won't_ provide that functionality, then you should punch up the >> discussion of the controllers mapping other identifiers to MUD URLs on >> behalf of the thing. > > I agree.  We allude to this in the draft.  We say, for instance: >> It is possible that there may be other means for a MUD URL to be >> learned by a network.  For instance, if a device has a serial number, >> it may be possible for the MUD controller to perform a lookup of the >> device, if it has some knowledge as to who the device manufacturer >> is, and what its MUD file server is.  Such mechanisms are not >> described in this memo, but are possible. > > The case we have in mind is LoRaWAN.  Should we go further? I think explicitly acknowledging that some things stacks limit their behavior will pay back. It would be unfortunate if someone who started a MUD controller implementation made the assumption that the majority of things will hand them the DHCP option (etc.) and waited to bolt the complexity of the lookup above onto their initial design. > > >> You suggest the DHCP Client (which is a thing) SHOULD log or report >> improper acknowledgments from servers. That's asking a bit much from >> a thing. I suspect the requirement is unrealistic and should be removed >> or rewritten to acknowledge that things typically won't do that. > I think there's a philosophical thing hiding here, though: what > expectations should we have of device.  As a SHOULD we're saying, if > you have good cause not to, ok.  But otherwise, for the sake of the > sanity of the customer, please log. Why not acknowledge in the document that the expectation is that most won't be able to. Painting as explicit and accurate picture as possible can only do good, no? (Again, I'm not trying to _assert_ that the majority of things can't, but that's my suspicion. People who work with this things on a daily basis should weigh in.) > >> The security and deployment considerations sections talk about what the >> need for coordination if control over the domain name used in the URL >> changes. It should talk more about what happens if the new administration >> of the domain is not interested in facilitating a transition (consider >> the case of a young company with a few thousand start-up-ish things out >> there that loses a suit over its name). Please discuss whether or not >> suddenly losing the MUD assisted network configuration is expected to >> leave the devices effectively cut-off. > > It should not, and here's why: > > * Assuming the device has already been used, there is no reason to > simply delete the MUD file from one's cache.  The cache-validity > value is meant as a timer to keep implementations for harassing > the MUD file server, but there's the information is still useful, > even if it may not have been freshened. > Hrmm - there should be some description about using the information even if the cache has expired. That might have security ramifications (it at least enables an attacker to cause a set of devices to use old information by attacking the access to what might be newer information). > > * In the case where the MUD file service is unavailable when the > device is first turned up, it's as if it had not included a > MUD-URL in the first place.  While this may be a downgrade attack, > there is, as I understand it, really no way to get around it, > other than for the MUD controller to log a problem. > Worth a short discussion in the text. > > * > > >> Right now, you leave the DHCP server (when it's used) responsible for >> clearing state in the MUD controller. Please discuss what happens when >> those are distinct elements (as you have in the end of section 9.2) and >> the DHCP server reboots. Perhaps it would make sense for the DHCP server >> to hand the length of the lease it has granted to the MUD controller and >> let the MUD controller clean up on its own? > > See other response. > >> The document currently suggests that a piece of software inspect the >> WHOIS database to see if registration ownership of a domain has changed. >> Do you really mean software, or should this be advice to the >> administrator of the controller instead? > > The controller.  The idea is to catch bad behavior and anomalies. And > the bigger idea is to reduce the number of decisions that the > administrator must make, while providing relevant information with > which to make the decisions. I don't think this is a reasonable thing to do. It has the many of the same properties we complain about when someone suggest that code inspect an IANA registry. > >> ==Nits== >> >> I recommend an editorial pass focusing on simplifying sentences. Look >> particularly where the word "therefore" is used and consider >> restructuring the surrounds. (It is used non-sequitur in a couple of >> places). Be careful to call out actors explicitly (I note the places >> that particularly caught my eye below). > > ok. >> Some specific nits: >> >> The abstract speaks only about properties of MUD but does not describe >> what MUD _is_, or is good for. A few more words here would help. > Right.  See response to Henk. >> Next to last paragraph of section 1 (before 1.1): A means for _who_ to >> retrieve the description? (Consider rendering the three list elements on >> their own lines.) > Right.  Fixed. >> The last sentence of section 1 treats "enterprise networks" more >> specially than it intends, I think. Why couldn't _any_ network do this? >> Could the sentence be reworded to make it clear that enterprise networks >> are an example? > > s/enterprise networks/local deployments/ > > ? Sure > >> First sentence of 1.1: Perhaps you mean "general purpose computing >> devices" instead of "general computing"? "their" has an unclear >> antecedent. > > Indeed.  fixed. > >> Last paragraph of 1.3: It's unclear what "such an approach" is intended >> to point to. Would "a general solution that required capabilities their >> particular device would not use" make more sense? > > Reworded. > >> First paragraph of 1.5: "might to allow" is probably meant to be "might >> be to allow". What does it mean for a controller to "need to speak COAP". >> Do you mean "controllers capable of speaking COAP"? > Fixed. >> Fourth paragraph of 1.5 at the discussion of time and effort: Consider >> rephrasing this to focus on the result of the time and effort (high >> quality) rather than the time and effort itself. > > Existence is good enough in this case ;-) > >> In the list of abstractions at the end of 1.5, you have three things you >> describe as devices and one thing you describe as a class. You later talk >> about the abstractions you've described as devices as classes. At this >> point in the document what you mean by "class" has not been made as >> explicit as it could be. > I've tried to review all instances of class to be clear that it is > used consistently.  This is somewhat difficult given natural language, > but I hope I've gotten it right. > >> Section 1.8, item 3: the MUD file doesn't have hosts in it (it has >> identifiers of some kind). Consider being more explicit about what >> you mean by testing that against a reputation service. > > Actually, it can have hosts in it, but see above. > >> Section 3.1: You say "Which turn was taken". I think you meant >> "Which, in turn, was taken". Consider deleting "for those keeping score". > > Awwww.  Just a bit of humor? ;-) > >> Section 3.3 is missing a word at "the location any MASA service"? > > Ok it's cleaned up. > >> I found the prose in the descriptions of the "manufacturer" and >> "same-manufacturer" elements (3.8 and 3.9) very confusing. I think >> additional prose introducing the concepts and maybe some examples would >> be very useful. > > Added examples per your suggestion. > >> What do you mean by "matches" at 3.10. Do you mean "is"? > > All of this is applicable in the context of the matches statement in > the ACL model.  I've added some explanatory text at the beginning of > the chapeau. >> The caution in the 2nd paragraph of 3.12 is not clear. > > Ok, I've cleaned that up and added an example. > >> At section 4, consider pointing out that you are not allowing >> DHCP by default, and that devices that are expected to use DHCP >> need to have an explicit allow in their MUD file. > > Hmm.  The issue here is that DHCP is an L2 protocol that isn't > forwarded.  Do you think it needs to be listed anyway? Hmm indeed. You're right. That said, the thing that triggered the thought was the ability of a MUD file to say whether or not something can talk to other things in the local network. Maybe some reinforcement in the discussion about what that rule would expand to would prevent someone from walling off the device more than you intended (it would be a creative mistake to do so, I agree) > >> The description of the manufacturer leaf in the MUD YANG model >> could be made more useful. > > ALL the descriptions have been improved. >> Provide a reference for "giaddr" when you use it in section 9.2. > > Cleaned up (that's defined in RFC 2131, already normatively > referenced, but I expanded). >> Section 14, 2nd paragraph: additional segmentation of what? > > Make that "network segmentation". >> Second paragraph of Section 15 - it would help to be more precise >> with agency. _Who_ should review the class? > > Fixed. > >> In the security considerations section, when you get to the "if for some >> reason it is not possible to determine whether ownership has changed", >> _who_ are you suggesting conduct further review? > > It's always the network administrator. >> ==Micro-nits== >> >> 1,$s/enorcement/enforcement/g > > Doh! > >> s/autjors/authors/ >> > > Fixed. > > Thanks again, > > Eliot > --------------35768AF4B247EF2DF66EB037 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Apologies for being a little laggy -

Some comments inline.


On 8/31/17 2:07 PM, Eliot Lear wrote:

Robert,

As I wrote earlier, this was a great review.  Thanks for that.  Please see below.


On 8/30/17 7:21 PM, Robert Sparks wrote:
Reviewer: Robert Sparks
Review result: Almost Ready

This is an exciting concept, and the draft overall is approachable. I
have identified a few areas I think need more detail, and have a 
longish list of nits (please don't take that to be negative).

==Issues==

I find the structure of the introduction unclear. Please consider
reworking it.  I would suggest even more succinctly listing goals and
constraints, and then intended applicability (these things are in the
current text, but I think you can render them much more efficiently). In
particular, the argument that implementers of things are incented only to
provide the minimal amount of behavior to get their thingyness could be
more strongly highlighted.

I've received conflicting reviews here.  Most like what's there and while I'm open to specific textual changes, a full reorganization would likely be destabilizing.
I disagree. I know it's work, but if you read this as an implementer, I think it would pay back.
This is a stylistic suggestion though, so take it only as my opinion.

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

This is discussed in security considerations:
It may also be useful
to limit retrieval of MUD URLs to only those sites that are known to
have decent web reputations.
What I am specifically talking about are web or domain reputation services.  These are pretty commonplace today.  Your browser uses one, and numerous companies offer them, including our own.  But to be clearer, I propose to use the term "web or domain reputation services", so that people know what I'm talking about.
I'll look at the diff.




In the first paragraph of Section 2, it's not clear if you are trying
to restrict the models to only those in the two documents in the list
following the paragraph.

Right.  This was caught earlier, and I'll correct.

I am not a YANG doctor, so this may be in the weeds, but it feels like
there's a discrepancy between the diagram at the end of section 2 and the
element definitions in section 3. In particular 3.7 doesn't seem to align
with what the diagram or the example in Appendix B uses. Should you be 
defining "from-device-policy" and "to-device-policy" instead of
"packet-direction"? (I'm wondering if 3.7 reflects an older design?)

Yupper.  Fixed (I think).
At section 3.13, the description of my-controller is not quite right.
This bit signals to the mud controller to use a mapping that it knows
about or creates. Something else established that class (and maybe gave
it a name). I talked about this with Eliot and he has a better 
description to use.

Proposed text:

This null-valued node signals to the MUD controller to use whatever
mapping it has for this URL to a controller class".  This may require
prompting the administrator for class members.  Future work should
seek to automate membership management.
ack

It's not clear to me that this is a good use of .well-known. I suggest
getting an expert review on the proposed usage. (I had a quick 
conversation with Mark Nottingham and got some initial feedback that 
I'm passing along here. I'm sure there's more that an in-depth review
would identify.) Why wouldn't a URI template (RFC6570) do the job? 
Rather than use RFC3986's query, consider pointing to HTML5 (which
would bring the more familiar key=value format).

The key issue is that we want to externalize versioning AND hardcode it in the URL so that it's independent of transport.  Remember, there is very little information exchange between the Thing and the network, and I will claim that's a good thing.
Sure, and URL templates would _do_ that, no? But please take that argument up with folks like Mark.

The document needs to say more about how HTTP is used. I assume you only
intend to use GET, and that you expect redirects to be followed, and that
nothing special needs to be considered with caching? The document needs
to be explicit about it. Take a look at 
<https://mnot.github.io/I-D/bcp56bis/>. (There's been some conversation
about it on the art list, so Eliot, at least, is already aware of it - 
see <https://mailarchive.ietf.org/arch/search/?q=bcp56bis>)

What we say today is the following;
Processing of this
URL occurs as specified in {{RFC2818}} and {{RFC3986}}.
There is one aspect of caching semantics we should probably capture, which is that the cache-validity period should exceed the HTTP cache or expiry period as specified by max-age or Expires.  Does that sound about right to you?
Goes in the right direction. Do you expect POST to work with this? 

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

We do have some discussion in Section 12.2.  I'm happy to add an additional sentence or two, but would seek guidance on where you think we're missing.
So, are you expecting to reuse the web PKI here? Will the MUD files be signed with the same credentials used by the HTTP server? I'm thinking you aren't, and are waving your hands at where trust lies with the recommendation that signers be validated directly etc. Either way, I think you need to be more explicit and that what you expect for establishing trust is going to take more than a couple of sentences.

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

I agree.  We allude to this in the draft.  We say, for instance:
It is possible that there may be other means for a MUD URL to be
learned by a network.  For instance, if a device has a serial number,
it may be possible for the MUD controller to perform a lookup of the
device, if it has some knowledge as to who the device manufacturer
is, and what its MUD file server is.  Such mechanisms are not
described in this memo, but are possible.

The case we have in mind is LoRaWAN.  Should we go further?
I think explicitly acknowledging that some things stacks limit their behavior will pay back. It would be unfortunate if someone who started a MUD controller implementation made the assumption that the majority of things will hand them the DHCP option (etc.) and waited to bolt the complexity of the lookup above onto their initial design.


You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.
I think there's a philosophical thing hiding here, though: what expectations should we have of device.  As a SHOULD we're saying, if you have good cause not to, ok.  But otherwise, for the sake of the sanity of the customer, please log.
Why not acknowledge in the document that the expectation is that most won't be able to.
Painting as explicit and accurate picture as possible can only do good, no?
(Again, I'm not trying to _assert_ that the majority of things can't, but that's my suspicion. People who work with this things on a daily basis should weigh in.)

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

It should not, and here's why:

  • Assuming the device has already been used, there is no reason to simply delete the MUD file from one's cache.  The cache-validity value is meant as a timer to keep implementations for harassing the MUD file server, but there's the information is still useful, even if it may not have been freshened.
Hrmm - there should be some description about using the information even if the cache has expired. That might have security ramifications (it at least enables an attacker to cause a set of devices to use old information by attacking the access to what might be newer information).
  • In the case where the MUD file service is unavailable when the device is first turned up, it's as if it had not included a MUD-URL in the first place.  While this may be a downgrade attack, there is, as I understand it, really no way to get around it, other than for the MUD controller to log a problem.
Worth a short discussion in the text.

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

See other response.

The document currently suggests that a piece of software inspect the
WHOIS database to see if registration ownership of a domain has changed.
Do you really mean software, or should this be advice to the
administrator of the controller instead?

The controller.  The idea is to catch bad behavior and anomalies.  And the bigger idea is to reduce the number of decisions that the administrator must make, while providing relevant information with which to make the decisions.
I don't think this is a reasonable thing to do. It has the many of the same properties we complain about when someone suggest that code inspect an IANA registry.

==Nits==

I recommend an editorial pass focusing on simplifying sentences. Look
particularly where the word "therefore" is used and consider
restructuring the surrounds. (It is used non-sequitur in a couple of
places). Be careful to call out actors explicitly (I note the places 
that particularly caught my eye below).

ok.
Some specific nits:

The abstract speaks only about properties of MUD but does not describe
what MUD _is_, or is good for. A few more words here would help.
Right.  See response to Henk.
Next to last paragraph of section 1 (before 1.1): A means for _who_ to
retrieve the description? (Consider rendering the three list elements on
their own lines.)
Right.  Fixed.
The last sentence of section 1 treats "enterprise networks" more
specially than it intends, I think. Why couldn't _any_ network do this?
Could the sentence be reworded to make it clear that enterprise networks
are an example?

s/enterprise networks/local deployments/

?
Sure

First sentence of 1.1: Perhaps you mean "general purpose computing
devices" instead of "general computing"? "their" has an unclear
antecedent.

Indeed.  fixed.

Last paragraph of 1.3: It's unclear what "such an approach" is intended
to point to. Would "a general solution that required capabilities their
particular device would not use" make more sense?

Reworded.

First paragraph of 1.5: "might to allow" is probably meant to be "might
be to allow". What does it mean for a controller to "need to speak COAP".
Do you mean "controllers capable of speaking COAP"?
Fixed.
Fourth paragraph of 1.5 at the discussion of time and effort: Consider
rephrasing this to focus on the result of the time and effort (high
quality) rather than the time and effort itself.

Existence is good enough in this case ;-)

In the list of abstractions at the end of 1.5, you have three things you
describe as devices and one thing you describe as a class. You later talk
about the abstractions you've described as devices as classes. At this
point in the document what you mean by "class" has not been made as
explicit as it could be.
I've tried to review all instances of class to be clear that it is used consistently.  This is somewhat difficult given natural language, but I hope I've gotten it right.

Section 1.8, item 3: the MUD file doesn't have hosts in it (it has
identifiers of some kind). Consider being more explicit about what
you mean by testing that against a reputation service.

Actually, it can have hosts in it, but see above.

Section 3.1: You say "Which turn was taken". I think you meant
"Which, in turn, was taken". Consider deleting "for those keeping score".

Awwww.  Just a bit of humor? ;-)

Section 3.3 is missing a word at "the location any MASA service"?

Ok it's cleaned up.

I found the prose in the descriptions of the "manufacturer" and
"same-manufacturer" elements (3.8 and 3.9) very confusing. I think
additional prose introducing the concepts and maybe some examples would
be very useful.

Added examples per your suggestion.

What do you mean by "matches" at 3.10. Do you mean "is"?

All of this is applicable in the context of the matches statement in the ACL model.  I've added some explanatory text at the beginning of the chapeau.
The caution in the 2nd paragraph of 3.12 is not clear.

Ok, I've cleaned that up and added an example.

At section 4, consider pointing out that you are not allowing 
DHCP by default, and that devices that are expected to use DHCP
need to have an explicit allow in their MUD file.

Hmm.  The issue here is that DHCP is an L2 protocol that isn't forwarded.  Do you think it needs to be listed anyway?
Hmm indeed. You're right. That said, the thing that triggered the thought
was the ability of a MUD file to say whether or not something can talk to
other things in the local network. Maybe some reinforcement in the discussion
about what that rule would expand to would prevent someone from walling
off the device more than you intended (it would be a creative mistake to do so,
I agree)

The description of the manufacturer leaf in the MUD YANG model
could be made more useful.

ALL the descriptions have been improved.
Provide a reference for "giaddr" when you use it in section 9.2.

Cleaned up (that's defined in RFC 2131, already normatively referenced, but I expanded).
Section 14, 2nd paragraph: additional segmentation of what?

Make that "network segmentation".
Second paragraph of Section 15 - it would help to be more precise
with agency. _Who_ should review the class?

Fixed.

In the security considerations section, when you get to the "if for some
reason it is not possible to determine whether ownership has changed",
_who_ are you suggesting conduct further review?

It's always the network administrator.
==Micro-nits==

1,$s/enorcement/enforcement/g

Doh!

s/autjors/authors/

Fixed.

Thanks again,

Eliot


--------------35768AF4B247EF2DF66EB037-- From nobody Thu Sep 7 23:25:26 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 6A1CA132D90; Thu, 7 Sep 2017 23:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 WLtZAblJOb-l; Thu, 7 Sep 2017 23:25:10 -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 C22A81321ED; Thu, 7 Sep 2017 23:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28232; q=dns/txt; s=iport; t=1504851909; x=1506061509; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Gu73CRtWTElK6P8KDGN/nNhChMwwGigOIdoI/bGpUsA=; b=AyMte3A6OpwhXhuEW0mIIt8loaH3GVc1L+62UDbiVIvKHOdzL0SkmSEz 5fMufTq9WdcY/4rCm3VwvdhBCWRii4cGMxbMS98FaaIb/5cjkKIoYZcNI JVBiG1PaUuU21k5cvH8WXEHwdq/Z/pIZ8FLV6vXpIO7cKv2QCcd1DT9Xj k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyBAA7N7JZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy2BEW6EHosVkHMJIpY2ggQHA4IDgzsChEYUAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?EASNPBwULCw40AgJXBgEMCAEBiiUIqn6CJyeLEwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQ4PgyYEhTMrC4JyhE4BCgQCgymCYQWJfgEThxaBZ4UliECEOYIhhFuJHAK?= =?us-ascii?q?CEYVng1qHHZUrgTk2IVsyMiEIHBWFXAUcgWk+iBMBASQHghQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,360,1500940800"; d="asc'?scan'208,217";a="657313580" 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; 08 Sep 2017 06:25:04 +0000 Received: from [10.61.194.216] ([10.61.194.216]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v886P4kw026034; Fri, 8 Sep 2017 06:25:04 GMT To: Robert Sparks , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> <3570a07d-6786-3077-f1a7-4ec61a4bf9d0@nostrum.com> From: Eliot Lear Message-ID: <59951415-4f15-97da-fef0-be2686850b9d@cisco.com> Date: Fri, 8 Sep 2017 08:25:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3570a07d-6786-3077-f1a7-4ec61a4bf9d0@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G09gOSsONrln52186q8PjfU32srn0a7r1" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 08 Sep 2017 06:25:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G09gOSsONrln52186q8PjfU32srn0a7r1 Content-Type: multipart/mixed; boundary="m1Rf2qkQejQRNEUanG9feDvMxoQF52C2G"; protected-headers="v1" From: Eliot Lear To: Robert Sparks , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Message-ID: <59951415-4f15-97da-fef0-be2686850b9d@cisco.com> Subject: Re: Genart early review of draft-ietf-opsawg-mud-08 References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> <3570a07d-6786-3077-f1a7-4ec61a4bf9d0@nostrum.com> In-Reply-To: <3570a07d-6786-3077-f1a7-4ec61a4bf9d0@nostrum.com> --m1Rf2qkQejQRNEUanG9feDvMxoQF52C2G Content-Type: multipart/alternative; boundary="------------492D86A3EC36FAC886DF6A3D" Content-Language: en-US This is a multi-part message in MIME format. --------------492D86A3EC36FAC886DF6A3D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, Thanks now for BOTH of your reviews.=C2=A0 I've a number of proposals bel= ow. On 9/7/17 5:51 PM, Robert Sparks wrote: > There is one aspect of caching semantics we should probably capture, > which is that the cache-validity period should exceed the HTTP cache > or expiry period as specified by max-age or Expires.=C2=A0 Does that so= und > about right to you? > Goes in the right direction. Do you expect POST to work with this? There is no particular POST operation required, but if someone wanted to POST a MUD file, so long as they also POST a signature file, it should be fine. >> >>> I think there needs to be more discussion of the PKI used for signing= MUD >>> files. >> >> We do have some discussion in Section 12.2.=C2=A0 I'm happy to add an >> additional sentence or two, but would seek guidance on where you >> think we're missing. > So, are you expecting to reuse the web PKI here? Will the MUD files be > signed with the same credentials used by the HTTP server? I'm thinking > you aren't, and are waving your hands at where trust lies with the > recommendation that signers be validated directly etc. Either way, I > think you need to be more explicit and that what you expect for > establishing trust is going to take more than a couple of sentences. You're right.=C2=A0 I don't think we want to interlock the signature of t= he file with the cert used on the web server.=C2=A0 It *could* be that, but = the focus on trust has to be the signer of the file.=C2=A0 How about somethin= g like this: The purpose of the signature on the file is to assign accountability to an entity, whose reputation can be used to guide administrators on whether or not to accept a given MUD file.=C2=A0 It is already com= mon place to check web=C2=A0 reputation on the location of a server on wh= ich a file resides.=C2=A0 While it is likely that the manufacturer will b= e the signer of the file, this is not strictly necessary, and may not be desirable.=C2=A0 For one thing, in some environments, integrators = may install their own certificates.=C2=A0 For another, what is more impor= tant is the accountability of the recommendation, and not the cryptographic relationship between the device and the file.=C2=A0 ?? This follows the philosophy we've used previously in efforts like DKIM. >> >>> Consider discussing whether the stacks used by typical things will le= t >>> them add DHCP options (or include bits in the other protocols being=20 >>> enabled). If it's well known (I can't say) that these stacks typicall= y >>> _won't_ provide that functionality, then you should punch up the >>> discussion of the controllers mapping other identifiers to MUD URLs o= n >>> behalf of the thing. >> >> I agree.=C2=A0 We allude to this in the draft.=C2=A0 We say, for insta= nce: >>> It is possible that there may be other means for a MUD URL to be >>> learned by a network.=C2=A0 For instance, if a device has a serial nu= mber, >>> it may be possible for the MUD controller to perform a lookup of the >>> device, if it has some knowledge as to who the device manufacturer >>> is, and what its MUD file server is.=C2=A0 Such mechanisms are not >>> described in this memo, but are possible. >> >> The case we have in mind is LoRaWAN.=C2=A0 Should we go further? > I think explicitly acknowledging that some things stacks limit their > behavior will pay back.=20 How about a replacement paragraph: It is possible that there may be other means for a MUD URL to be learned by a network.=C2=A0 For instance, some devices may already be= fielded or have very limited ability to communicate a MUD URL, and ye= t can be identified through some means, such as a serial number or a public key.=C2=A0 In these cases, manufacturers may be able to map th= ose identifies to particular MUD URLs (or even the files themselves). Similarly, there may be alternative resolution mechanisms available for situations where Internet connectivity is limited or does not exist.=C2=A0 Such mechanisms are not described in this memo, but are possible.=C2=A0 Implementors should allow for this sort of flexibilit= y of how MUD URLs may be learned. > >>> You suggest the DHCP Client (which is a thing) SHOULD log or report=20 >>> improper acknowledgments from servers. That's asking a bit much from >>> a thing. I suspect the requirement is unrealistic and should be remov= ed >>> or rewritten to acknowledge that things typically won't do that. >> I think there's a philosophical thing hiding here, though: what >> expectations should we have of device.=C2=A0 As a SHOULD we're saying,= if >> you have good cause not to, ok.=C2=A0 But otherwise, for the sake of t= he >> sanity of the customer, please log. > Why not acknowledge in the document that the expectation is that most > won't be able to. > Painting as explicit and accurate picture as possible can only do > good, no? > (Again, I'm not trying to _assert_ that the majority of things can't, > but that's my suspicion. People who work with this things on a daily > basis should weigh in.) Obviously a Thing can be literally anything.=C2=A0 I agree we are setting= a bit of a bar here, but I would rather not let implementors off the hook.=C2=A0 From an implementation standpoint, the device is already awak= e in this case in order to process the packet, and so we're not talking about excess power consumption.=C2=A0 In the case of really low power, DHCP isn= 't going to be in the picture. >> >>> The security and deployment considerations sections talk about what t= he >>> need for coordination if control over the domain name used in the URL= >>> changes. It should talk more about what happens if the new administra= tion >>> of the domain is not interested in facilitating a transition (conside= r >>> the case of a young company with a few thousand start-up-ish things o= ut >>> there that loses a suit over its name). Please discuss whether or not= >>> suddenly losing the MUD assisted network configuration is expected to= >>> leave the devices effectively cut-off.=20 >> >> It should not, and here's why: >> >> * Assuming the device has already been used, there is no reason to >> simply delete the MUD file from one's cache.=C2=A0 The cache-valid= ity >> value is meant as a timer to keep implementations for harassing >> the MUD file server, but there's the information is still useful, >> even if it may not have been freshened. >> > Hrmm - there should be some description about using the information > even if the cache has expired. That might have security ramifications > (it at least enables an attacker to cause a set of devices to use old > information by attacking the access to what might be newer information)= =2E It may be worth "logging and/or reporting".=C2=A0=C2=A0 I think we need implementation experience to tell us exactly how long to wait before doing so, however. See below. >> * In the case where the MUD file service is unavailable when the >> device is first turned up, it's as if it had not included a >> MUD-URL in the first place.=C2=A0 While this may be a downgrade >> attack, there is, as I understand it, really no way to get around >> it, other than for the MUD controller to log a problem. >> > Worth a short discussion in the text. How about this: It may not be possible for a MUD controller to retrieve a MUD file at= any given time.=C2=A0 Should a MUD controller fail to retrieve a MUD = file, it SHOULD consider the existing one safe to use, at least for a time.= After some period, it SHOULD log that it has been unable to retrieve the file.=C2=A0 There may be very good reasons for such failures, inc= luding the possibility that the MUD controller is in an off-line environment= , the local Internet connection has failed, or the remote Internet connection has failed.=C2=A0 It is also possible that an attacker is attempting to prevent onboarding of a device.=C2=A0 It is a local deployment decision as to whether or not devices may be onboarded in the face of such failures. >> * >> >> >> >> >>> Right now, you leave the DHCP server (when it's used) responsible for= >>> clearing state in the MUD controller. Please discuss what happens whe= n >>> those are distinct elements (as you have in the end of section 9.2) a= nd >>> the DHCP server reboots. Perhaps it would make sense for the DHCP ser= ver >>> to hand the length of the lease it has granted to the MUD controller = and >>> let the MUD controller clean up on its own? >> >> See other response. >> >>> The document currently suggests that a piece of software inspect the >>> WHOIS database to see if registration ownership of a domain has chang= ed. >>> Do you really mean software, or should this be advice to the >>> administrator of the controller instead?=20 >> >> The controller.=C2=A0 The idea is to catch bad behavior and anomalies.= =C2=A0 >> And the bigger idea is to reduce the number of decisions that the >> administrator must make, while providing relevant information with >> which to make the decisions. > I don't think this is a reasonable thing to do. It has the many of the > same properties we complain about when someone suggest that code > inspect an IANA registry. This is different.=C2=A0 The registries are REALLY static information and= do not maintain any form of ownership.=C2=A0 Here, if there is an ownership change, it's a good idea to spot it.=C2=A0 Note that such queries should = be infrequent.=C2=A0 They should only happen when a signer has changed, and = when DNS information has changed. >>> At section 4, consider pointing out that you are not allowing=20 >>> DHCP by default, and that devices that are expected to use DHCP >>> need to have an explicit allow in their MUD file.=20 >> >> Hmm.=C2=A0 The issue here is that DHCP is an L2 protocol that isn't >> forwarded.=C2=A0 Do you think it needs to be listed anyway? > Hmm indeed. You're right. That said, the thing that triggered the thoug= ht > was the ability of a MUD file to say whether or not something can talk = to > other things in the local network. Maybe some reinforcement in the > discussion > about what that rule would expand to would prevent someone from walling= > off the device more than you intended (it would be a creative mistake > to do so, > I agree) I'd need a suggestion for that, but since it's a stretch I suggest we let this one go for now. Thanks again. Eliot --------------492D86A3EC36FAC886DF6A3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Robert,

Thanks now for BOTH of your reviews.=C2=A0 I've a number of propos= als below.

On 9/7/17 5:51 PM, Robert Sparks wrote= :

There= is one aspect of caching semantics we should probably capture, which is that the cache-validity period should exceed the HTTP cache or expiry period as specified by max-age or Expires.=C2=A0 Do= es that sound about right to you?
Goes in the right direction. Do you expect POST to work with this?

There is no particular POST operation required, but if someone wanted to POST a MUD file, so long as they also POST a signature file, it should be fine.


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

We do have some discussion in Section 12.2.=C2=A0 I'm happy to ad= d an additional sentence or two, but would seek guidance on where you think we're missing.
So, are you expecting to reuse the web PKI here? Will the MUD files be signed with the same credentials used by the HTTP server? I'm thinking you aren't, and are waving your hands at where trust lies with the recommendation that signers be validated directly etc. Either way, I think you need to be more explicit and that what you expect for establishing trust is going to take more than a couple of sentences.

You're right.=C2=A0 I don't think we want to interlock the signature = of the file with the cert used on the web server.=C2=A0 It *could* be th= at, but the focus on trust has to be the signer of the file.=C2=A0 How ab= out something like this:

The purpose of the signature on the file is to assign accountability to an entity, whose reputation can be used to guide administrators on whether or not to accept a given MUD file.=C2=A0 = It is already common place to check web=C2=A0 reputation on the locati= on of a server on which a file resides.=C2=A0 While it is likely that = the manufacturer will be the signer of the file, this is not strictly necessary, and may not be desirable.=C2=A0 For one thing, in some environments, integrators may install their own certificates.=C2=A0= For another, what is more important is the accountability of the recommendation, and not the cryptographic relationship between the device and the file.=C2=A0

??

This follows the philosophy we've used previously in efforts like DKIM.



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

I agree.=C2=A0 We allude to this in the draft.=C2=A0 We say, for = instance:
It is possible that there may be other means for a MUD URL to be
learned by a network.=C2=A0 For instance, if a device has a ser= ial number,
it may be possible for the MUD controller to perform a lookup of the
device, if it has some knowledge as to who the device manufacturer
is, and what its MUD file server is.=C2=A0 Such mechanisms are = not
described in this memo, but are possible.

The case we have in mind is LoRaWAN.=C2=A0 Should we go further?<= br>
I think explicitly acknowledging that some things stacks limit their behavior will pay back.

How about a replacement paragraph:

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

You suggest the DHCP Client (which is a thing) S=
HOULD log or report=20
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.
I think there's a philosophical thing hiding here, though: what expectations should we have of device.=C2=A0 As a SHOULD we're saying, if you have good cause not to, ok.=C2=A0 But otherwise, f= or the sake of the sanity of the customer, please log.
Why not acknowledge in the document that the expectation is that most won't be able to.
Painting as explicit and accurate picture as possible can only do good, no?
(Again, I'm not trying to _assert_ that the majority of things can't, but that's my suspicion. People who work with this things on a daily basis should weigh in.)

Obviously a Thing can be literally anything.=C2=A0 I agree we are set= ting a bit of a bar here, but I would rather not let implementors off the hook.=C2=A0 From an implementation standpoint, the device is already awake in this case in order to process the packet, and so we're not talking about excess power consumption.=C2=A0 In the case of really l= ow power, DHCP isn't going to be in the picture.

= 
The security and deployment considerations secti=
ons talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration=

of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off.

It should not, and here's why:

  • Assuming the device has already been used, there is no reason to simply delete the MUD file from one's cache.=C2=A0 = The cache-validity value is meant as a timer to keep implementations for harassing the MUD file server, but there's the information is still useful, even if it may not have been freshened.
Hrmm - there should be some description about using the information even if the cache has expired. That might have security ramifications (it at least enables an attacker to cause a set of devices to use old information by attacking the access to what might be newer information).

It may be worth "logging and/or reporting".=C2=A0=C2=A0 I think we ne= ed implementation experience to tell us exactly how long to wait before doing so, however. See below.

  • In the case where the MUD file service is unavailable when the device is first turned up, it's as if it had not included a MUD-URL in the first place.=C2=A0 While this may b= e a downgrade attack, there is, as I understand it, really no way to get around it, other than for the MUD controller to log a problem.
Worth a short discussion in the text.

How about this:

It may not be possible for a MUD controller to retrieve a MUD file at
any given time.=C2=A0 Should a MUD controller fail to retrieve a MU= D file,
it SHOULD consider the existing one safe to use, at least for a time.
After some period, it SHOULD log that it has been unable to retrieve
the file.=C2=A0 There may be very good reasons for such failures, including
the possibility that the MUD controller is in an off-line environment,
the local Internet connection has failed, or the remote Internet connection has failed.=C2=A0 It is also possible that an attacker i= s
attempting to prevent onboarding of a device.=C2=A0 It is a local deployment decision as to whether or not devices may be onboarded in
the face of such failures.



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

See other response.

The document currently suggests that a piece of =
software inspect the
WHOIS database to see if registration ownership of a domain has changed.
Do you really mean software, or should this be advice to the
administrator of the controller instead?

The controller.=C2=A0 The idea is to catch bad behavior and anomalies.=C2=A0 And the bigger idea is to reduce the number of decisions that the administrator must make, while providing relevant information with which to make the decisions.
I don't think this is a reasonable thing to do. It has the many of the same properties we complain about when someone suggest that code inspect an IANA registry.

This is different.=C2=A0 The registries are REALLY static information= and do not maintain any form of ownership.=C2=A0 Here, if there is an ownership change, it's a good idea to spot it.=C2=A0 Note that such queries should be infrequent.=C2=A0 They should only happen when a si= gner has changed, and when DNS information has changed.

At section 4, consider pointing out that you are=
 not allowing=20
DHCP by default, and that devices that are expected to use DHCP
need to have an explicit allow in their MUD file.

Hmm.=C2=A0 The issue here is that DHCP is an L2 protocol that isn= 't forwarded.=C2=A0 Do you think it needs to be listed anyway? Hmm indeed. You're right. That said, the thing that triggered the thought
was the ability of a MUD file to say whether or not something can talk to
other things in the local network. Maybe some reinforcement in the discussion
about what that rule would expand to would prevent someone from walling
off the device more than you intended (it would be a creative mistake to do so,
I agree)

I'd need a suggestion for that, but since it's a stretch I suggest we let this one go for now.

Thanks again.

Eliot
--------------492D86A3EC36FAC886DF6A3D-- --m1Rf2qkQejQRNEUanG9feDvMxoQF52C2G-- --G09gOSsONrln52186q8PjfU32srn0a7r1 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 iQEcBAEBCAAGBQJZsjfFAAoJEIe2a0bZ0nozSr0IAIxMmojcFqthbfF4tdwqRp+f ngYruBPVzxqm6Zl6BIHXBPeLOkZDjk4lfW7Ja/CasXIubN0XBgageSZfRvwHe63u JjdLzei/lnJzl9i81qwg+0Ja0zuFp+gc+LAGGrX4fcRufzDR+LK3ALiIDCq6Q9uI 0gWOiQU7zMdXIi9772V3lv1IdUmnnb7Vi71UswQLt3Grjl4Nnw04+fEY+Ps4DgkP hIEWFZcFLuGFyySam+0MvqFiByR1dYD8iVdMa/16bYMhODLRxQMU+fHuaCRevF92 YkiHSpAitdSmqrADK2nueGDgT6/uage5l4HeHiL/IKGlrMoc/TDylkgZQ1p4ldE= =zGHT -----END PGP SIGNATURE----- --G09gOSsONrln52186q8PjfU32srn0a7r1-- From nobody Fri Sep 8 05:35:55 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 0DB181321A4; Fri, 8 Sep 2017 05:35:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150487415301.17285.8385247668098511742@ietfa.amsl.com> Date: Fri, 08 Sep 2017 05:35:53 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 12:35:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Rajesh S. Pazhyannur Sri Gundavelli Zhen Cao Hui Deng Zongpeng Du Filename : draft-ietf-opsawg-capwap-alt-tunnel-10.txt Pages : 26 Date : 2017-09-08 Abstract: Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-10 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 8 11:54: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 BDBC713292A for ; Fri, 8 Sep 2017 11:54:46 -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 EF0al_Z8Ymfa for ; Fri, 8 Sep 2017 11:54:45 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 5D9D513293F for ; Fri, 8 Sep 2017 11:54:45 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f199so9759542wme.0 for ; Fri, 08 Sep 2017 11:54:45 -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=IDsmRHF9MfsdwtylVCoJ55gHeRwT+pWDKol4Deyku4w=; b=A0SHBdJNB44BR0q8fb+MPKoYapYCQfu8LhhByE3aOzWBhES32uCU9oEae3BCPx1ERJ vcOWGARVJyH4wNoT5+BeXux17A1XFpDlWMOD5awlZBAv1ZccAEGOmlrEgPjrrk63+Vet RjqxK1B666lOlD7FlgQc/rF2Iasi8ur9MiuITSEHHSHjoC4pKQhfnXJsP8fhVwh8Yz4n 6pHWl1kHhoKtdKsRA3v55NOpO7lRln85U0KCdwYQuq6O2JK4gpwaRkwxYYOI/zRlPapU 2GrRCZWlDYJCTiUNuARZdMTIZwXDZiukYnwl8p9XfcULaJSRnVmb3PpuD92cAkOD03Qd 3bmA== 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=IDsmRHF9MfsdwtylVCoJ55gHeRwT+pWDKol4Deyku4w=; b=S+4Dq1Ae3SkFfeDv5omO4NVK3J2TDI+uJoHbyP2MZevTMO1f8BiaFovxsMfpV59gg4 Tww7d8NdsGcQKy86vQ/T19PicJeesfSdteQv9vuMA4nJeTYz4TL7iXc421NIOhuZLuHN +Z36jpcI9jGPS+MHCclUladY8cfW71jD6Nxho1ddb5jIMgO9M6n5PQ65uQG41zeBFQFN 89SmOnhTrxquX+Bt6OpGEoqWlT80oUK+gi/Mk2ePYEkp5UKgvWS0S5z/OJaFoZ+j63B+ 3CW/U2U4uJygSK7Zjr3GNuWQs1HuvL3+PPLdPKnay5AAvrwt+/o0UfVGKiMrestdJosm Ypmg== X-Gm-Message-State: AHPjjUhTtioKpGLgdmPKAbbLo1msu3iErdy32n7KisCoFvsfhRsg8X28 yKi7Ctc9FeZ/srUuiHIDwIsSdnoeIv91 X-Google-Smtp-Source: AOwi7QCuZ7tNVG9OUuf85Krq6usKye7Vn7ysFpvV0oaJfrQOsSoDuU98uIp3mKhLZGycCdQxeeLvCJKRynHhhEw1HG8= X-Received: by 10.28.212.212 with SMTP id l203mr2242921wmg.33.1504896883569; Fri, 08 Sep 2017 11:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.71 with HTTP; Fri, 8 Sep 2017 11:54:02 -0700 (PDT) From: "M. Ranganathan" Date: Fri, 8 Sep 2017 14:54:02 -0400 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a11497de82b37810558b21cd0" Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 08 Sep 2017 18:54:46 -0000 --001a11497de82b37810558b21cd0 Content-Type: text/plain; charset="UTF-8" Hello! MUD currently does not enforce restrictions on temporal behavior. For example, I cannot specify how many times per second a device is allowed to connect to a remote IP address and port. Would this be worth considering? Use case: DDOS attack mitigation (?) Ranga -- M. Ranganathan --001a11497de82b37810558b21cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

MUD currently does not = enforce restrictions on temporal behavior. For example, I cannot specify ho= w many times per second a device is allowed to connect to a remote IP addre= ss and port.

Would this be worth considering?

Use case:

DDOS attack mitigation (?)


Ranga

--
M. Ranganathan
--001a11497de82b37810558b21cd0-- From nobody Mon Sep 11 00:54: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 64651132F2E; Mon, 11 Sep 2017 00:54:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150511645436.9764.10060813476954322953@ietfa.amsl.com> Date: Mon, 11 Sep 2017 00:54:14 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 07:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-09.txt Pages : 52 Date : 2017-09-11 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-09 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 11 01:02: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 6301A132F49 for ; Mon, 11 Sep 2017 01:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 q-iUY7PmicyY for ; Mon, 11 Sep 2017 01:02:35 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306B7132F2E for ; Mon, 11 Sep 2017 01:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8322; q=dns/txt; s=iport; t=1505116955; x=1506326555; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=rXJVrtH1I/kSYFfkUiV3amyhuIfUA9WaCX7l0k3RZcY=; b=hbbamoIbVpKYCZRe+KFeZPFZCNhadtrH+K0dOROpzgcSQyHuALwzyZo7 atFq7U3sXAreQ5wDak0QkbvGyQ1BoZIWPRuGLUG4j5S7AG1W8lrj5ph9z TDqQtwSgNNV9OIOx07Nc2JwDFGcKhpc3lLLoaqTZTGxS9XD3Ne1RzVdrT w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCDQrZZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3iiF0kHMrkGqFPw6CBAcDI4UbAoRSGAECAQEBAQEBAWs?= =?us-ascii?q?dC4UZAQUjVBILEgYVFQICSQ4GDQYCAQGKLRCtOoInJ4sNAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEPD4MrhWCCfYMngQuBBIJUgmEFihKHFocMiECEOYIhgQGMdoITWoU?= =?us-ascii?q?Ng1qFVIFJlSuBOR84gQ0yIQgcFSCHRz42AYdFK4IUAQEB?= X-IronPort-AV: E=Sophos;i="5.42,376,1500940800"; d="asc'?scan'208,217";a="697096224" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 08:02:32 +0000 Received: from [10.61.216.42] ([10.61.216.42]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8B82WQ8024475 for ; Mon, 11 Sep 2017 08:02:32 GMT To: "opsawg@ietf.org" References: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> From: Eliot Lear Message-ID: <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> Date: Mon, 11 Sep 2017 10:02:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EdCs6vwJqAwNRoI5r17cPTVD4rQarKrC7" Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 08:02:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EdCs6vwJqAwNRoI5r17cPTVD4rQarKrC7 Content-Type: multipart/mixed; boundary="fT38vp7W26bijwvghR3D6cOECQL8EGQar"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> Subject: Re: New Version Notification for draft-ietf-opsawg-mud-09.txt References: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> In-Reply-To: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> --fT38vp7W26bijwvghR3D6cOECQL8EGQar Content-Type: multipart/alternative; boundary="------------7B7EA8738E375F3FBC56CC79" Content-Language: en-US This is a multi-part message in MIME format. --------------7B7EA8738E375F3FBC56CC79 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, This draft takes into account comments received from early reviews.=C2=A0= The changes include the following: * Resolution of Security Area review, IoT directorate review, GenART review, YANG doctors review; * change of YANG structure to address mandatory nodes; * Terminology cleanup; * specify out extra portion of MUD-URL; * consistency changes; * improved YANG descriptions; * Remove extra revisions; * Track ACL model changes; * Additional cautions on use of ACL model; * Further clarifications on extensions; * Improved text on certificate validation; * An extension example; and * Additional guidance on "controller" URIs and URNs. The examples should be correct. I am aware of one error that is in the current ACL model draft at this point that may generate warnings (there is an xpath error, the authors are aware). Please review. Eliot On 9/11/17 9:54 AM, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-opsawg-mud-09.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name: draft-ietf-opsawg-mud > Revision: 09 > Title: Manufacturer Usage Description Specification > Document date: 2017-09-11 > Group: opsawg > Pages: 52 > URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-= mud-09.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/= > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-mud-09 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg= -mud-09 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-m= ud-09 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL suffix specification, an X.509 certificate extension= > and a means to sign and verify the descriptions. > > = =20 > > > 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. > > The IETF Secretariat > > --------------7B7EA8738E375F3FBC56CC79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi everyone,

This draft takes into account comments received from early reviews.=C2=A0 The changes include the following:

  • Resolution of Security Area review, IoT directorate review, GenART review, YANG doctors review;
  • change of YANG structure to address mandatory nodes;
  • Terminology cleanup;
  • specify out extra portion of MUD-URL;
  • consistency changes;
  • improved YANG descriptions;
  • Remove extra revisions;
  • Track ACL model changes;
  • Additional cautions on use of ACL model;
  • Further clarifications on extensions;
  • Improved text on certificate validation;
  • An extension example; and
  • Additional guidance on "controller" URIs and URNs.

The examples should be correct.

I am aware of one error that is in the current ACL model draft at this point that may generate warnings (there is an xpath error, the authors are aware).

Please review.

Eliot


On 9/11/17 9:54 AM, internet-drafts@ietf.org wrote:
A new version of I-D, draft-ietf-opsawg-mud-09.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-ietf-opsawg-mud
Revision:	09
Title:		Manufacturer Usage Description Specification
Document date:	2017-09-11
Group:		opsawg
Pages:		52
URL:            https://www.ietf.org=
/internet-drafts/draft-ietf-opsawg-mud-09.txt
Status:         https://datatracker.ietf.org/d=
oc/draft-ietf-opsawg-mud/
Htmlized:       https://tools.ietf.org/html/draft=
-ietf-opsawg-mud-09
Htmlized:       https://datatracker.iet=
f.org/doc/html/draft-ietf-opsawg-mud-09
Diff:           https://www.ietf.org/rfcd=
iff?url2=3Ddraft-ietf-opsawg-mud-09

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.

                                                                         =
        =20


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

The IETF Secretariat

--------------7B7EA8738E375F3FBC56CC79-- --fT38vp7W26bijwvghR3D6cOECQL8EGQar-- --EdCs6vwJqAwNRoI5r17cPTVD4rQarKrC7 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 iQEcBAEBCAAGBQJZtkMYAAoJEIe2a0bZ0noz1+cH/3eLAIS5ekmsmI9Y3A7acpRs e5oIMPyOG3cYZQVqwPECQatCvKBCU5QcIGAYXnTNAfQ4qkozqz7+HTwesrIJ4HJU gN74tgz4/20/9RY44I3e6HOklrlupZRwQwfqj7hNX+DyTKdCGN8Ksg3d52ruUWPK ldH7rkWbKFoM8+/YzgWHtiQELkzfJIw4EjlFYveEiw9mmpr0gD3VeJd1Te8YLHmS z9x+ZiFu1S9MbKZtIw5xF1uN9bVUNEDTuIxaPBalzNG5g8vYcRHhxql+PbzgmVoh ZzCV39U47JhuE0x/tZ7/T7BaSGHRG+23GQJ9CnHvtydO8d5gMf3BcQI9Z/tKYGo= =yMFd -----END PGP SIGNATURE----- --EdCs6vwJqAwNRoI5r17cPTVD4rQarKrC7-- From nobody Mon Sep 11 01:05:27 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 591BA132F2E for ; Mon, 11 Sep 2017 01:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 uV6TK8oS6fxN for ; Mon, 11 Sep 2017 01:05:24 -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 3ABBD132F2C for ; Mon, 11 Sep 2017 01:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10116; q=dns/txt; s=iport; t=1505117124; x=1506326724; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=574leJyZ4OiszX5yy3T2Z+7j+88mwRq5FK4o2kEYow4=; b=jC8trIM3CJblb+igkCFFgSzKPcDKr8aVRCIrwvrf5/SzvZaRGCrXpcFP ZzhSfb8gc1tJ3rzk62TAXGnzi70ytke3cOA8cP5kX9hCNYPR7Y4E0b71K SqVwEOlxC+B0ndplnJmcfxQREsiaiXlUYW6wroglkEhKN/C5RY/rcYjG0 s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APEACDQrZZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3iiF0gX+OdCuQaoU/DoIEBwMYAQqETE8ChFIYAQIBAQE?= =?us-ascii?q?BAQEBax0LhRkBAQQBASEmJQkSCxIGFRUCAiciDgYNBgIBAYotEK06gicniw0BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEOD4MrhWCCfYMngQuBBIJUgmEFihKHFocMiEC?= =?us-ascii?q?EOYIhgQGMdoITWoUNg1qFVIFJlSuBOR84gQ0yIQgcFSAqhx0+NgGHRSuCFAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.42,376,1500940800"; d="asc'?scan'208,217";a="655550583" 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; 11 Sep 2017 08:05:21 +0000 Received: from [10.61.216.42] ([10.61.216.42]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8B85LNT006081 for ; Mon, 11 Sep 2017 08:05:21 GMT To: "opsawg@ietf.org" References: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> From: Eliot Lear Message-ID: <219da765-b78d-fd34-ad65-235c3d9188e5@cisco.com> Date: Mon, 11 Sep 2017 10:05:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="daSl3qfCNcQEXGGRjVfNWf2r6TtCXx5Ce" Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 08:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --daSl3qfCNcQEXGGRjVfNWf2r6TtCXx5Ce Content-Type: multipart/mixed; boundary="iXGR2no0KcgDTBr1CtojUHTFlCduwtwhU"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <219da765-b78d-fd34-ad65-235c3d9188e5@cisco.com> Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-09.txt References: <150511645457.9764.7198036883880280931.idtracker@ietfa.amsl.com> <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> In-Reply-To: <909b26be-6a30-7fe5-aa35-091c42a33cc7@cisco.com> --iXGR2no0KcgDTBr1CtojUHTFlCduwtwhU Content-Type: multipart/alternative; boundary="------------46CE13FEB8A77A14052CA36F" Content-Language: en-US This is a multi-part message in MIME format. --------------46CE13FEB8A77A14052CA36F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Also, www.mudmaker.org now generates to this draft.=C2=A0 The old version= can be found at https://www.mudmaker.org/v08. Eliot On 9/11/17 10:02 AM, Eliot Lear wrote: > > Hi everyone, > > This draft takes into account comments received from early reviews.=C2=A0= > The changes include the following: > > * Resolution of Security Area review, IoT directorate review, GenART > review, YANG doctors review; > * change of YANG structure to address mandatory nodes; > * Terminology cleanup; > * specify out extra portion of MUD-URL; > * consistency changes; > * improved YANG descriptions; > * Remove extra revisions; > * Track ACL model changes; > * Additional cautions on use of ACL model; > * Further clarifications on extensions; > * Improved text on certificate validation; > * An extension example; and > * Additional guidance on "controller" URIs and URNs. > > The examples should be correct. > > I am aware of one error that is in the current ACL model draft at this > point that may generate warnings (there is an xpath error, the authors > are aware). > > Please review. > > Eliot > > > On 9/11/17 9:54 AM, internet-drafts@ietf.org wrote: >> A new version of I-D, draft-ietf-opsawg-mud-09.txt >> has been successfully submitted by Eliot Lear and posted to the >> IETF repository. >> >> Name: draft-ietf-opsawg-mud >> Revision: 09 >> Title: Manufacturer Usage Description Specification >> Document date: 2017-09-11 >> Group: opsawg >> Pages: 52 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg= -mud-09.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud= / >> Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-mud-09 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsaw= g-mud-09 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-= mud-09 >> >> Abstract: >> This memo specifies a component-based architecture for manufacturer= >> usage descriptions (MUD). The goal of MUD is to provide a means fo= r >> Things to signal to the network what sort of access and network >> functionality they require to properly function. The initial focus= >> is on access control. Later work can delve into other aspects. >> >> This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a= n >> LLDP TLV, a URL suffix specification, an X.509 certificate extensio= n >> and a means to sign and verify the descriptions. >> >> = =20 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------46CE13FEB8A77A14052CA36F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Also, www.mudmaker.org now generates to this draft.=C2=A0 The ol= d version can be found at https://www.mudmaker.org/v08.

Eliot


On 9/11/17 10:02 AM, Eliot Lear wrote:=

Hi everyone,

This draft takes into account comments received from early reviews.=C2=A0 The changes include the following:

  • Resolution of Security Area review, IoT directorate review, GenART review, YANG doctors review;
  • change of YANG structure to address mandatory nodes;
  • Terminology cleanup;
  • specify out extra portion of MUD-URL;
  • consistency changes;
  • improved YANG descriptions;
  • Remove extra revisions;
  • Track ACL model changes;
  • Additional cautions on use of ACL model;
  • Further clarifications on extensions;
  • Improved text on certificate validation;
  • An extension example; and
  • Additional guidance on "controller" URIs and URNs.

The examples should be correct.

I am aware of one error that is in the current ACL model draft at this point that may generate warnings (there is an xpath error, the authors are aware).

Please review.

Eliot


On 9/11/17 9:54 AM, internet-drafts@ietf.org wrote:
A new version of I-D, draft-ietf-opsawg-mud-09.txt=

has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-ietf-opsawg-mud
Revision:	09
Title:		Manufacturer Usage Description Specification
Document date:	2017-09-11
Group:		opsawg
Pages:		52
URL:            https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud-09.txt
Status:         https=
://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
Htmlized:       https://=
tools.ietf.org/html/draft-ietf-opsawg-mud-09
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-09
Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-09

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.

                                                                         =
        =20


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

The IETF Secretariat






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

--------------46CE13FEB8A77A14052CA36F-- --iXGR2no0KcgDTBr1CtojUHTFlCduwtwhU-- --daSl3qfCNcQEXGGRjVfNWf2r6TtCXx5Ce 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 iQEcBAEBCAAGBQJZtkPBAAoJEIe2a0bZ0noz/M0IAJpLkLHVKKsJH1W1GhtBuYMB bRbGGKTNPL4JUA/aRSxX4AFgeIzjyn9f7/aNxUTxdYHRAsT91nAffOKx/FEptkGD XQyOobgY/QqWnB9cNxdN1iooBpFbPr/m2sLU2a3GTKlG499mcgtbp3uvnG1lEVOj QfAJ4q91khwDpMYOAnples60FQR8c7UPTJDAYpwxB7M405AgdrdA2rQH7wX8D1f0 dEUqf5HPUtJwbPFncHIeY6SW7DA9KPipEHJ1sv+6gKdvhwp2IHgboG+bnx0TbdQx Ydm11h9FfKw+yehpdk7Ubg8M2IkeJJpuxEaVARdHgwtMFSJAuQblaUgv4VgO4Ck= =irK6 -----END PGP SIGNATURE----- --daSl3qfCNcQEXGGRjVfNWf2r6TtCXx5Ce-- From nobody Mon Sep 11 08:29:25 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 83DB01330D1 for ; Mon, 11 Sep 2017 08:29:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FBZyi8EAu8_4 for ; Mon, 11 Sep 2017 08:29:21 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 851AB1330CA for ; Mon, 11 Sep 2017 08:29:21 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 80so19503168lfy.4 for ; Mon, 11 Sep 2017 08:29:21 -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=C4CnG/2xSIEk6al+kPnuLqS/YHL0TjJwuocqaM02lmU=; b=AdVlNBMOvzruMgy4PYIUyT4uaYTTHGpmMOmQB9RGfrVOMPWkYl7Rm5peHG6PLOBjOM 7xjSqot4u70239nTrzm0CUKKnVlNP5gdiQIFbhcKQsaZ2s/mKm8IYwh1QCD3rsdCSno3 Lj60VYISeBPNNG6pT/rOEINBaDz2IRLzMShXb4BWrHoMEYMJj5sL38xytIydCko1Z4y8 10a/R5ESsE8CEWeWgE5JvtwDiCH8b1TUgJL4hgdvtCBR8WwVLH53keSu++Je14MQiQCf whrqPtAOyUDqkXG1c3TpuqhD0rfqMNisJr/5XnRwmDo7lZ4Ur+JeDyTZo5GLR1B5jMZI bqiA== 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=C4CnG/2xSIEk6al+kPnuLqS/YHL0TjJwuocqaM02lmU=; b=YYq3xBETS63DoRuAQJhSgemb0qRHfCn+HwRa6daCYuBfTkhUiB4kc99p+JrXvhPvUj KgLoEG1IsWKXqAdqjnAm6Bd0H5Le4KKqRP6pre0LqCUlUC6CDzsayHwJwiZ9dwjZS5Vk Tb5dfNtCrDc5ROkbmqsLfnvQzLhvZwcsFMMz9LhdUH2XXE83uvCjafnsmIzL+v9Bf+Q1 JBj2shYxkbcPx7oCRFxoh3kILGD0s/aTTN30fZFW4FORu6JodYKcumew9Jo4MWihvxPE fK3i62zti2xg973MOQLZINC1raAhLCCwymmLC7QX3PjRMwxJW/zNV+DUxFaCpk+ZNGY+ wq7g== X-Gm-Message-State: AHPjjUhPPX3XA1L7nnWEWZ48o6e3urzxXzMzfk0YDs2ZqKyBFFqovIff oCq87XD1bRXPx7fVKeNiaRERY0AdtZVr X-Google-Smtp-Source: AOwi7QDaQMv1sXSEWzVnhYRAk4ALvkgtUhq0tIXoayxBHQklT1Z/56V0ikszUYJGRfdFXJ8z9SJ02r8HuOROZtvBo3s= X-Received: by 10.46.82.15 with SMTP id g15mr1520044ljb.135.1505143759551; Mon, 11 Sep 2017 08:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.146 with HTTP; Mon, 11 Sep 2017 08:28:48 -0700 (PDT) In-Reply-To: References: From: Thorsten Dahm Date: Mon, 11 Sep 2017 16:28:48 +0100 Message-ID: To: "M. Ranganathan" Cc: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a113c3ca02029060558eb9760" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 11 Sep 2017 15:29:23 -0000 --001a113c3ca02029060558eb9760 Content-Type: text/plain; charset="UTF-8" Hi Ranga, I think this would go beyond the job of MUD and would be at the discretion of the network administrator to enforce rate limits probably at the same network devices that are also responsible for implementing the packet filters and such. cheers, Thorsten On 8 September 2017 at 19:54, M. Ranganathan wrote: > Hello! > > MUD currently does not enforce restrictions on temporal behavior. For > example, I cannot specify how many times per second a device is allowed to > connect to a remote IP address and port. > > Would this be worth considering? > > Use case: > > DDOS attack mitigation (?) > > > Ranga > > -- > M. Ranganathan > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > -- Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047 --001a113c3ca02029060558eb9760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ranga,

I think this would go b= eyond the job of MUD and would be at the discretion of the network administ= rator to enforce rate limits probably at the same network devices that are = also responsible for implementing the packet filters and such.

cheers,
Thorsten
On 8 September 2017 at 19:54, M. Ranganathan <m= ranga@gmail.com> wrote:
Hello!

MUD currently does not enf= orce restrictions on temporal behavior. For example, I cannot specify how m= any times per second a device is allowed to connect to a remote IP address = and port.

Would this be worth considering?

= Use case:

DDOS attack mitigation (?)

Ranga

--
M. Ranganathan

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



--
Thorsten Dahm
=
Network Engineer
Google Ireland Ltd.
The Gasworks, Barrow Street<= br>Dublin 4,=C2=A0 Ireland

Registered in Dublin, Ireland
Registra= tion Number: 368047
--001a113c3ca02029060558eb9760-- From nobody Mon Sep 11 09:03:43 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 64B88133133 for ; Mon, 11 Sep 2017 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 F9f-K-FniyeH for ; Mon, 11 Sep 2017 09:03:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FA9132D96 for ; Mon, 11 Sep 2017 09:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9622; q=dns/txt; s=iport; t=1505145818; x=1506355418; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ni+205FgU8T01gz9CSW+ma9TClywU746r30IlJ69AO0=; b=cYT1kEi95jUBXiskgU9ZySYSFqnTyS2QGDDUJXm9KDqfeLYdfm4dcXzA /7+/qKXpXW2LpfJeil35mL8ZCh1dVVZlhVxbBa0l6tOzc0ztbGtNS3ocu fzvp1L8ztnDKgDe3mIv6kULrqwuJHGdZEuyOPFcMYBBLbjmamrVgozf/V I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAwC7srZZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4tZG4nB4NwmkKKLogwhnIDXAoYAQqETE8CGoQHVwECAQEBAQE?= =?us-ascii?q?CayiFGQIEAQEhSwsQAgEIPwMCAgIfBgsUEQIEDgWJTUwDFRCsGYInhy4Ng28BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMnBIEnW4MzK4J9gliCHoMUMIIxBYoNBY4?= =?us-ascii?q?iiAQ8Ao9ZhHaEAY5wjFOFIoMJAhEZAYE4AVdOP3cVShIBgnKBWjSCCHaIMIEPA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.42,378,1500940800"; d="scan'208,217";a="1882143" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2017 16:03:38 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8BG3b2T017816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 16:03:38 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 12:03:37 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 12:03:37 -0400 From: "Einar Nilsen-Nygaard (einarnn)" To: Thorsten Dahm CC: "M. Ranganathan" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. Thread-Index: AQHTKNP164oCI7lBJUeOkNlowrSPV6KwFrkAgAAJqwA= Date: Mon, 11 Sep 2017 16:03:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.194.211] Content-Type: multipart/alternative; boundary="_000_AD2B1DE40B9F432F864A82899BBA3646ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 11 Sep 2017 16:03:41 -0000 --_000_AD2B1DE40B9F432F864A82899BBA3646ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpbGUgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlh bCBNVUQgZHJhZnQsIEnigJltIG5vdCBzdXJlIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGJleW9uZCB0 aGUgc2NvcGUgb2YgTVVEIGluIHRoZSBsb25nZXIgdGVybS4NCg0KSWYgYSBtYW51ZmFjdHVyZXIg Y2FuIGRlZmluZSBiZWhhdmlvciBpbiB0aGlzIHdheSwgd2h5IHdvdWxkbuKAmXQgaXQgcG9zc2li bHkgYmUgYSBuZXcgcG9saWN5IHR5cGUgdGhhdCBjYW4gYmUgYW4gZXh0ZW5zaW9uL2F1Z21lbnRh dGlvbiB0byB0aGUgTVVEIFlBTkcgbW9kdWxlPw0KDQpCdXQgSSBkbyBhbHNvIGFncmVlIHRoYXQg dGhpbmdzIGxpa2UgcmF0ZSBsaW1pdHMgYXJlLCBhbmQgc2hvdWxkIGNvbnRpbnVlIHRvIGJlIGF0 IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IuIEZvciBleGFtcGxl LCBpZiB0aGUgYWRtaW5pc3RyYXRvciBkZXRlcm1pbmVzIHRoYXQgaGVyIHBvbGljeSBpcyDigJwy MCBjb25uZWN0aW9uIGF0dGVtcHRzIHBlciBzZWNvbmTigJ0sIGEgTVVEIHBvbGljeSBzYXlpbmcg YSBkZXZpY2UgdHlwZSBtaWdodCBiZSDigJwzMCBjb25uZWN0aW9uIGF0dGVtcHRzIHBlciBzZWNv bmTigJ0gd291bGQganVzdCBiZSB0YWtlbiBhcyBhbiBhZHZpc29yeSwgbm90IHNvbWV0aGluZyB0 aGF0IG5lZWRzIHRvIGJlIGVtYm9kaWVkIGluIHBvbGljeS4gSG93ZXZlciwgaWYgYSBtYW51ZmFj dHVyZXIgZGVmaW5lcyBhbiBleHBlY3RlZCByYXRlIGxvd2VyIHRoYW4gdGhleSB3b3VsZCBub3Jt YWxseSBhbGxvdywgdGhhdCBjYW4gcG90ZW50aWFsbHkgYmUgYW4gaW5wdXQgdG8sIGZvciBleGFt cGxlLCBJRFMgY29uZmlncy4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQpPbiAxMSBTZXAgMjAxNywg YXQgMTY6MjgsIFRob3JzdGVuIERhaG0gPHRob3JzdGVuZGx1eEBnb29nbGUuY29tPG1haWx0bzp0 aG9yc3RlbmRsdXhAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpIaSBSYW5nYSwNCg0KSSB0aGluayB0 aGlzIHdvdWxkIGdvIGJleW9uZCB0aGUgam9iIG9mIE1VRCBhbmQgd291bGQgYmUgYXQgdGhlIGRp c2NyZXRpb24gb2YgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB0byBlbmZvcmNlIHJhdGUgbGlt aXRzIHByb2JhYmx5IGF0IHRoZSBzYW1lIG5ldHdvcmsgZGV2aWNlcyB0aGF0IGFyZSBhbHNvIHJl c3BvbnNpYmxlIGZvciBpbXBsZW1lbnRpbmcgdGhlIHBhY2tldCBmaWx0ZXJzIGFuZCBzdWNoLg0K DQpjaGVlcnMsDQpUaG9yc3Rlbg0KDQpPbiA4IFNlcHRlbWJlciAyMDE3IGF0IDE5OjU0LCBNLiBS YW5nYW5hdGhhbiA8bXJhbmdhQGdtYWlsLmNvbTxtYWlsdG86bXJhbmdhQGdtYWlsLmNvbT4+IHdy b3RlOg0KSGVsbG8hDQoNCk1VRCBjdXJyZW50bHkgZG9lcyBub3QgZW5mb3JjZSByZXN0cmljdGlv bnMgb24gdGVtcG9yYWwgYmVoYXZpb3IuIEZvciBleGFtcGxlLCBJIGNhbm5vdCBzcGVjaWZ5IGhv dyBtYW55IHRpbWVzIHBlciBzZWNvbmQgYSBkZXZpY2UgaXMgYWxsb3dlZCB0byBjb25uZWN0IHRv IGEgcmVtb3RlIElQIGFkZHJlc3MgYW5kIHBvcnQuDQoNCldvdWxkIHRoaXMgYmUgd29ydGggY29u c2lkZXJpbmc/DQoNClVzZSBjYXNlOg0KDQpERE9TIGF0dGFjayBtaXRpZ2F0aW9uICg/KQ0KDQoN ClJhbmdhDQoNCi0tDQpNLiBSYW5nYW5hdGhhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYu b3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29wc2F3Zw0KDQoNCg0KDQotLQ0KVGhvcnN0ZW4gRGFobQ0KDQpOZXR3b3JrIEVu Z2luZWVyDQpHb29nbGUgSXJlbGFuZCBMdGQuDQpUaGUgR2Fzd29ya3MsIEJhcnJvdyBTdHJlZXQN CkR1YmxpbiA0LCAgSXJlbGFuZA0KDQpSZWdpc3RlcmVkIGluIER1YmxpbiwgSXJlbGFuZA0KUmVn aXN0cmF0aW9uIE51bWJlcjogMzY4MDQ3DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYub3JnPG1h aWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zw0KDQo= --_000_AD2B1DE40B9F432F864A82899BBA3646ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <70ED0FC860815443BB8902F27B7162C5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2hpbGUgSSBhZ3JlZSB0aGF0IHRo aXMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbCBNVUQgZHJhZnQsIEnigJltIG5v dCBzdXJlIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgTVVEIGluIHRo ZSBsb25nZXIgdGVybS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPklmIGEgbWFudWZhY3R1cmVyIGNhbiBkZWZpbmUgYmVoYXZpb3IgaW4gdGhpcyB3 YXksIHdoeSB3b3VsZG7igJl0IGl0IHBvc3NpYmx5IGJlIGEgbmV3IHBvbGljeSB0eXBlIHRoYXQg Y2FuIGJlIGFuIGV4dGVuc2lvbi9hdWdtZW50YXRpb24gdG8gdGhlIE1VRCBZQU5HIG1vZHVsZT88 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkJ1dCBJIGRvIGFsc28gYWdyZWUgdGhhdCB0aGluZ3MgbGlrZSByYXRlIGxpbWl0cyBhcmUsIGFu ZCBzaG91bGQgY29udGludWUgdG8gYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIG5ldHdvcmsg YWRtaW5pc3RyYXRvci4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhZG1pbmlzdHJhdG9yIGRldGVybWlu ZXMgdGhhdCBoZXIgcG9saWN5IGlzIOKAnDIwIGNvbm5lY3Rpb24gYXR0ZW1wdHMgcGVyIHNlY29u ZOKAnSwgYSBNVUQgcG9saWN5IHNheWluZw0KIGEgZGV2aWNlIHR5cGUgbWlnaHQgYmUg4oCcMzAg Y29ubmVjdGlvbiBhdHRlbXB0cyBwZXIgc2Vjb25k4oCdIHdvdWxkIGp1c3QgYmUgdGFrZW4gYXMg YW4gYWR2aXNvcnksIG5vdCBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBlbWJvZGllZCBpbiBw b2xpY3kuIEhvd2V2ZXIsIGlmIGEgbWFudWZhY3R1cmVyIGRlZmluZXMgYW4gZXhwZWN0ZWQgcmF0 ZSBsb3dlciB0aGFuIHRoZXkgd291bGQgbm9ybWFsbHkgYWxsb3csIHRoYXQgY2FuIHBvdGVudGlh bGx5DQogYmUgYW4gaW5wdXQgdG8sIGZvciBleGFtcGxlLCBJRFMgY29uZmlncy48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PbiAxMSBTZXAgMjAxNywgYXQgMTY6Mjgs IFRob3JzdGVuIERhaG0gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9yc3RlbmRsdXhAZ29vZ2xlLmNv bSIgY2xhc3M9IiI+dGhvcnN0ZW5kbHV4QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgUmFuZ2EsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KSSB0aGluayB0aGlzIHdvdWxkIGdvIGJleW9uZCB0 aGUgam9iIG9mIE1VRCBhbmQgd291bGQgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIG5ldHdv cmsgYWRtaW5pc3RyYXRvciB0byBlbmZvcmNlIHJhdGUgbGltaXRzIHByb2JhYmx5IGF0IHRoZSBz YW1lIG5ldHdvcmsgZGV2aWNlcyB0aGF0IGFyZSBhbHNvIHJlc3BvbnNpYmxlIGZvciBpbXBsZW1l bnRpbmcgdGhlIHBhY2tldCBmaWx0ZXJzIGFuZCBzdWNoLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Y2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UaG9yc3RlbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDggU2VwdGVtYmVyIDIwMTcgYXQg MTk6NTQsIE0uIFJhbmdhbmF0aGFuIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86bXJhbmdhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm1y YW5nYUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhlbGxvITxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpNVUQgY3VycmVudGx5IGRv ZXMgbm90IGVuZm9yY2UgcmVzdHJpY3Rpb25zIG9uIHRlbXBvcmFsIGJlaGF2aW9yLiBGb3IgZXhh bXBsZSwgSSBjYW5ub3Qgc3BlY2lmeSBob3cgbWFueSB0aW1lcyBwZXIgc2Vjb25kIGEgZGV2aWNl IGlzIGFsbG93ZWQgdG8gY29ubmVjdCB0byBhIHJlbW90ZSBJUCBhZGRyZXNzIGFuZCBwb3J0Lg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpXb3VsZCB0aGlzIGJlIHdvcnRo IGNvbnNpZGVyaW5nPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Vc2UgY2FzZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+RERPUyBhdHRhY2sgbWl0aWdhdGlvbiAoPyk8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpS YW5nYTxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4IiBjbGFzcz0iIj48 YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCi0tIDxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9Im1fNzczNDk4ODY2MDE2MjIxNTQxZ21haWxfc2lnbmF0dXJlIj5N LiBSYW5nYW5hdGhhbjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBj bGFzcz0iIj4NCk9QU0FXRyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86T1BTQVdHQGlldGYub3JnIiBjbGFzcz0iIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNh d2ciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9vcHNhd2c8L2E+PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KLS0gPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0dXJl IiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj5UaG9yc3RlbiBEYWhtPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KTmV0d29yayBFbmdpbmVlcjxiciBjbGFzcz0iIj4NCkdvb2ds ZSBJcmVsYW5kIEx0ZC48YnIgY2xhc3M9IiI+DQpUaGUgR2Fzd29ya3MsIEJhcnJvdyBTdHJlZXQ8 YnIgY2xhc3M9IiI+DQpEdWJsaW4gNCwmbmJzcDsgSXJlbGFuZDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClJlZ2lzdGVyZWQgaW4gRHVibGluLCBJcmVsYW5kPGJyIGNsYXNzPSIiPg0KUmVn aXN0cmF0aW9uIE51bWJlcjogMzY4MDQ3PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT1BTQVdHIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciIGNs YXNzPSIiPk9QU0FXR0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_AD2B1DE40B9F432F864A82899BBA3646ciscocom_-- From nobody Tue Sep 12 06:48:55 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 00813133062 for ; Tue, 12 Sep 2017 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 WOIKPcudNexq for ; Tue, 12 Sep 2017 06:48:50 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 3FBD7132D22 for ; Tue, 12 Sep 2017 06:48:50 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l196so26520868lfl.1 for ; Tue, 12 Sep 2017 06:48:50 -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=is3A+qNM7oecsuIGGN0J4ow2741HtH6huAeM05rU2iI=; b=skHmN1O4thH8QBFOZmtSE96NnA17T4POEkD3L9iNqXNZdGnKRonzlL1XR66ZuiAJA/ bCOjrBlGdfGt5kYp5nmPp0+g0kr/+SOsN6Zi1YJVgzn3vzV1giZPPWUzqAq+ScXoxTJ8 Ic4gqyOAYYIya85OjAm4AipJAgb+0m1LLcp5z9vMg4LasQdOGZlzUMkl9bNwEWCA7xeB y8PDji8To/ug3dSeJovaXf5VKKOO+EHgacvYZN77jOA4KZ4L3DYAs7GvDkYLksqX30GC U7JihaoHPlbcync8lpLMJvav6GjFi3Hz1bO4Y/gqQ0CuqhIEt2vshaoDAEVawDKNXauK RPYw== 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=is3A+qNM7oecsuIGGN0J4ow2741HtH6huAeM05rU2iI=; b=m95FyLKNiXxNOOV6bT98MTwlcrOYop05ETJOZs0XPU3OL2uW4mHlr6wG5M6JKFmgeW aKcg2BCA/DnNtdVgJsJRJk9/CFc1M4XvIL9TsgCBnIxsY/aAy1a8/RCFXz9tUbvFGjza zoexDHGdXm5NgPNK2F3JJDscKADTNw2b5mGSlB9w4cXYzktY3sN1/s08tq4L0DLn6KVQ Kg9I3ziGmPbPCV7N2HDbqXG5qNXmE4NbYDDUdUbl4LKiVp14mVk2FOE+YXGZ0pK0yoxH ZlkAptBjUyt7OthD6zyLi474bC6+ur7avqdkj/FAZve8fka5eau2TZbm1p45ANgnIYzr YjIQ== X-Gm-Message-State: AHPjjUgPaIY2E4E+QFMfJSmCapciDrhs1kmVkZGHlbPuCt+DExZM4I5m lbKmpotxZux1ktxTEDTishKWbZVdII81 X-Google-Smtp-Source: AOwi7QDX1de/poPTr/WPXaa0gUOwY2xvUJafPRVgfpjVwnRTKSD6gwYHyP6FmDup34epw4UjvvG+FadBsyeHp+AlUZs= X-Received: by 10.25.21.149 with SMTP id 21mr5291191lfv.93.1505224128131; Tue, 12 Sep 2017 06:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.146 with HTTP; Tue, 12 Sep 2017 06:48:17 -0700 (PDT) In-Reply-To: References: From: Thorsten Dahm Date: Tue, 12 Sep 2017 14:48:17 +0100 Message-ID: To: "Einar Nilsen-Nygaard (einarnn)" Cc: "M. Ranganathan" , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary="001a113f2156777b130558fe4d78" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 12 Sep 2017 13:48:53 -0000 --001a113f2156777b130558fe4d78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Einar, thanks for the reply. Let me clarify my thoughts below. :-) On 11 September 2017 at 17:03, Einar Nilsen-Nygaard (einarnn) < einarnn@cisco.com> wrote: > > But I do also agree that things like rate limits are, and should continue > to be at the discretion of the network administrator. > What rate limits do we talk about? Something like "maximum 10% of the available network bandwidth" is still significant traffic, I have a bunch of 100G links in my network. Or do we talk about QPS (Queries Per Second)? > For example, if the administrator determines that her policy is =E2=80=9C= 20 > connection attempts per second=E2=80=9D, a MUD policy saying a device typ= e might be > =E2=80=9C30 connection attempts per second=E2=80=9D would just be taken a= s an advisory, not > something that needs to be embodied in policy. > So now I have to keep track of the packets, keep a state, because I need to count packets. That means I now DDoS my own network by having to keep huge connection table somewhere (because with IoT, we may have thousands of different IoT devices in a single building) and can no longer have a simple stateless packet filter that would only allow TCP/443 to www.example.com as specified in the MUD file. As a network administrator, I would most likely ignore such a policy. Especially if it would require me to buy more expensive hardware, when one of the main arguments used for deploying IoT is actually cost savings. ;-) Another thought, maybe not relevant here, but for completeness: if company Example, with the website www.example.com, sells 1 million IoT devices that all connect back to their cloud on www.example.com but then have to rely on the rate limit setting in MUD because if all 1 million devices would send more than 1 packet per second to the website www.example.com it would go down, I would argue that it is time to scale up www.example.com. :-) And it would't be possible to DoS any other website than www.example.com if the MUD file is written and implemented by the network correctly. > However, if a manufacturer defines an expected rate lower than they would > normally allow, that can potentially be an input to, for example, IDS > configs. > Right, but that would depend heavily on the IoT device, no? Like a temperature sensor, how would I know if I want to report the temperature once a day, once every hour, once every 2 minutes without looking at the config? As an IDS admin, I would worry more about watching if the temperature sensor would try to send packets to anything else than my temperature collection server than how often it reports the temperature during the day. It would also open the door for false positives, like if you say you would not expect more than 5 packets per hour being send to www.example.com but then a software update is available and the thing would exchange maybe 100 packets with www.example.com to download the new firmware, my IDS would fire. Maybe it is just me, but I wouldn't want to use MUD to configure my IDS. cheers, Thorsten > > Cheers, > > Einar > > On 11 Sep 2017, at 16:28, Thorsten Dahm wrote: > > > Hi Ranga, > > I think this would go beyond the job of MUD and would be at the discretio= n > of the network administrator to enforce rate limits probably at the same > network devices that are also responsible for implementing the packet > filters and such. > > cheers, > Thorsten > > On 8 September 2017 at 19:54, M. Ranganathan wrote: > >> Hello! >> >> MUD currently does not enforce restrictions on temporal behavior. For >> example, I cannot specify how many times per second a device is allowed = to >> connect to a remote IP address and port. >> >> Would this be worth considering? >> >> Use case: >> >> DDOS attack mitigation (?) >> >> >> Ranga >> >> -- >> M. Ranganathan >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> >> > > > -- > Thorsten Dahm > > Network Engineer > Google Ireland Ltd. > The Gasworks, Barrow Street > Dublin 4, Ireland > > Registered in Dublin, Ireland > Registration Number: 368047 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > --=20 Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047 --001a113f2156777b130558fe4d78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Einar,

thanks for the reply. Let me = clarify my thoughts below. :-)

On 11 September 2017 at 17:03, Einar Nilsen-N= ygaard (einarnn) <einarnn@cisco.com> wrote:
=C2=A0
But I do also agree that things like rate limits are, and should conti= nue to be at the discretion of the network administrator.

What rate limits do we talk about? Something lik= e "maximum 10% of the available network bandwidth" is still signi= ficant traffic, I have a bunch of 100G links in my network. Or do we talk a= bout QPS (Queries Per Second)?

=C2=A0
For examp= le, if the administrator determines that her policy is =E2=80=9C20 connecti= on attempts per second=E2=80=9D, a MUD policy saying a device type might be =E2=80=9C30 connection attempts per second=E2=80=9D= would just be taken as an advisory, not something that needs to be embodie= d in policy.

So now I have to = keep track of the packets, keep a state, because I need to count packets. T= hat means I now DDoS my own network by having to keep huge connection table= somewhere (because with IoT, we may have thousands of different IoT device= s in a single building) and can no longer have a simple stateless packet fi= lter that would only allow TCP/443 to ww= w.example.com as specified in the MUD file. As a network administrator,= I would most likely ignore such a policy. Especially if it would require m= e to buy more expensive hardware, when one of the main arguments used for d= eploying IoT is actually cost savings. ;-)

Another= thought, maybe not relevant here, but for completeness: if company Example= , with the website www.example.com, = sells 1 million IoT devices that all connect back to their cloud on www.example.com but then have to rely on th= e rate limit setting in MUD because if all 1 million devices would send mor= e than 1 packet per second to the website www.example.com it would go down, I would argue that it is time to sc= ale up www.example.com. :-) And it w= ould't be possible to DoS any other website than www.example.com if the MUD file is written and implemented= by the network correctly.

=C2=A0
However, if a = manufacturer defines an expected rate lower than they would normally allow,= that can potentially be an input to, for example, IDS configs.
Right, but that would depend heavily on the IoT device, no? Lik= e a temperature sensor, how would I know if I want to report the temperatur= e once a day, once every hour, once every 2 minutes without looking at the = config? As an IDS admin, I would worry more about watching if the temperatu= re sensor would try to send packets to anything else than my temperature co= llection server than how often it reports the temperature during the day. I= t would also open the door for false positives, like if you say you would n= ot expect more than 5 packets per hour being send to www.example.com but then a software update is available an= d the thing would exchange maybe 100 packets with www.example.com to download the new firmware, my IDS would fi= re.=C2=A0

Maybe it is just me, but I wouldn't = want to use MUD to configure my IDS.

cheers,
=
Thorsten=C2=A0
=C2=A0

Cheers,

Einar

On 11 Sep 2017, at 16:28, Thorsten Dahm <thorstendlux@google.com> wrote:

Hi Ranga,

I think this would go beyond the job of MUD and would be at the discretion = of the network administrator to enforce rate limits probably at the same ne= twork devices that are also responsible for implementing the packet filters= and such.

cheers,
Thorsten

On 8 September 2017 at 19:54, M. Ranganathan <mranga@gmail.com<= /a>> wrote:
Hello!

MUD currently does not enforce restrictions on temporal behavior. For examp= le, I cannot specify how many times per second a device is allowed to conne= ct to a remote IP address and port.

Would this be worth considering?

Use case:

DDOS attack mitigation (?)


Ranga<= br clear=3D"all">

--
M.= Ranganathan

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



--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.
The Gasworks, Barrow Street
Dublin 4,=C2=A0 Ireland

Registered in Dublin, Ireland
Registration Number: 368047
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg




--
Thorsten Dahm
Network Engineer
Google Ireland Ltd.
The Gasworks, Barrow StreetDublin 4,=C2=A0 Ireland

Registered in Dublin, Ireland
Registrati= on Number: 368047
--001a113f2156777b130558fe4d78-- From nobody Tue Sep 12 08:35:07 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 A696E1320D9 for ; Tue, 12 Sep 2017 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 hjxc8tcPuWws for ; Tue, 12 Sep 2017 08:35:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE43126D0C for ; Tue, 12 Sep 2017 08:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27052; q=dns/txt; s=iport; t=1505230501; x=1506440101; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eNiGPvANv4lBquEA/sCVrAN0rO8lZ8sd8kd0pNHvRG8=; b=PXRQjHYjK7jZfzmSTAT/4WojNhrimMViF+u2xmWPyLivBpuSm897leeT nNzIBWZJy6xwIrJvI6MCPl+E8Dm+3hwR45qovp5NIzhImJZAT4n0r1BZd gSerKLcdaJc1zxMrhps8L+9kOdWONx2J0gqXnKKEU7v3kPBz2xN2p2XDm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAQC2/bdZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4tZG4nB4NwiiGQJIFSiFyNboEzA1wKGAEKgWCCbE8CGoQnPxg?= =?us-ascii?q?BAgEBAQEBAQFrKIUZAgQBASEmJQsQAgEIBzgDAgICHwYLFBECBA4FiU1MAxUQq?= =?us-ascii?q?jERgSOCJ4c2DYNvAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMnBIEnW4MzKwuCcoJ?= =?us-ascii?q?YgXkQFT+CVTCCMQWKDAWOIogFPAKPWYR3ghOBb45wiX+CV4UigwoCERkBgTgBH?= =?us-ascii?q?zhOP3cVShIBgnKBWjSCCHaHSYExgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208,217";a="294450175" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 15:35:00 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8CFZ0DQ005781 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 15:35:00 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 11:34:59 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 11:34:59 -0400 From: "Einar Nilsen-Nygaard (einarnn)" To: Thorsten Dahm CC: "M. Ranganathan" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. Thread-Index: AQHTKNP164oCI7lBJUeOkNlowrSPV6KwFrkAgAAJqwCAAWyUgIAAHb2A Date: Tue, 12 Sep 2017 15:34:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.194.211] Content-Type: multipart/alternative; boundary="_000_B2B3519C17904D98A5C01F2E8A22F806ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 12 Sep 2017 15:35:06 -0000 --_000_B2B3519C17904D98A5C01F2E8A22F806ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxMiBTZXAgMjAxNywgYXQgMTQ6NDgsIFRob3JzdGVuIERhaG0gPHRob3JzdGVuZGx1eEBn b29nbGUuY29tPG1haWx0bzp0aG9yc3RlbmRsdXhAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpIaSBF aW5hciwNCg0KdGhhbmtzIGZvciB0aGUgcmVwbHkuIExldCBtZSBjbGFyaWZ5IG15IHRob3VnaHRz IGJlbG93LiA6LSkNCg0KT24gMTEgU2VwdGVtYmVyIDIwMTcgYXQgMTc6MDMsIEVpbmFyIE5pbHNl bi1OeWdhYXJkIChlaW5hcm5uKSA8ZWluYXJubkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lz Y28uY29tPj4gd3JvdGU6DQoNCkJ1dCBJIGRvIGFsc28gYWdyZWUgdGhhdCB0aGluZ3MgbGlrZSBy YXRlIGxpbWl0cyBhcmUsIGFuZCBzaG91bGQgY29udGludWUgdG8gYmUgYXQgdGhlIGRpc2NyZXRp b24gb2YgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvci4NCg0KV2hhdCByYXRlIGxpbWl0cyBkbyB3 ZSB0YWxrIGFib3V0PyBTb21ldGhpbmcgbGlrZSAibWF4aW11bSAxMCUgb2YgdGhlIGF2YWlsYWJs ZSBuZXR3b3JrIGJhbmR3aWR0aCIgaXMgc3RpbGwgc2lnbmlmaWNhbnQgdHJhZmZpYywgSSBoYXZl IGEgYnVuY2ggb2YgMTAwRyBsaW5rcyBpbiBteSBuZXR3b3JrLiBPciBkbyB3ZSB0YWxrIGFib3V0 IFFQUyAoUXVlcmllcyBQZXIgU2Vjb25kKT8NCg0KSSBhZ3JlZSB0aGVyZSBhcmUgbWFueSBkaWZm ZXJlbnQg4oCccmF0ZXPigJ0gdGhhdCB3ZSBjYW4gcG90ZW50aWFsbHkgdGFsayBhYm91dCwgYW5k IHRoYXQgY2hhcmFjdGVyaXNhdGlvbiBvZiB0aGlzIGluIGEgd2F5IHRoYXQgY2FuIGJlIHVzZWZ1 bGx5IGV4cHJlc3NlZCBhcyBhIOKAnHBvbGljeeKAnSAoeWVhaCwgb3ZlcnVzZWQgdGVybSwgc29y cnkhOy0pIGlzIGEgc2VwYXJhdGUgdGFzayBpbiBhbmQgb2YgaXRzZWxmLiBJbiBlc3NlbmNlLCBJ IHdvdWxkbuKAmXQgc2VlayB0byBkZWZpbmUgd2hhdCBhIG5ldHdvcmsgYWRtaW5pc3RyYXRvcuKA mXMg4oCccmF0ZSBsaW1pdHPigJ0gYXJlLCBidXQsIGZyb20gdGhlIE1VRCBwZXJzcGVjdGl2ZSwg dHJ5IGFuZCBnaXZlIGEgdXNlZnVsIGNoYXJhY3RlcmlzYXRpb24gb2YgaXRzIGV4cGVjdGVkIGJl aGF2aW9yLiBUaGlzIGNoYXJhY3RlcmlzYXRpb24gY291bGQgcGVyaGFwcyBiZSB1c2VkIGJ5IHRo ZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IgdG8gY29tcGxlbWVudCB0aGVpciBvd24gcG9saWNpZXMu DQoNCkZvciBleGFtcGxlLCBpZiB0aGUgYWRtaW5pc3RyYXRvciBkZXRlcm1pbmVzIHRoYXQgaGVy IHBvbGljeSBpcyDigJwyMCBjb25uZWN0aW9uIGF0dGVtcHRzIHBlciBzZWNvbmTigJ0sIGEgTVVE IHBvbGljeSBzYXlpbmcgYSBkZXZpY2UgdHlwZSBtaWdodCBiZSDigJwzMCBjb25uZWN0aW9uIGF0 dGVtcHRzIHBlciBzZWNvbmTigJ0gd291bGQganVzdCBiZSB0YWtlbiBhcyBhbiBhZHZpc29yeSwg bm90IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGVtYm9kaWVkIGluIHBvbGljeS4NCg0KU28g bm93IEkgaGF2ZSB0byBrZWVwIHRyYWNrIG9mIHRoZSBwYWNrZXRzLCBrZWVwIGEgc3RhdGUsIGJl Y2F1c2UgSSBuZWVkIHRvIGNvdW50IHBhY2tldHMuIFRoYXQgbWVhbnMgSSBub3cgRERvUyBteSBv d24gbmV0d29yayBieSBoYXZpbmcgdG8ga2VlcCBodWdlIGNvbm5lY3Rpb24gdGFibGUgc29tZXdo ZXJlIChiZWNhdXNlIHdpdGggSW9ULCB3ZSBtYXkgaGF2ZSB0aG91c2FuZHMgb2YgZGlmZmVyZW50 IElvVCBkZXZpY2VzIGluIGEgc2luZ2xlIGJ1aWxkaW5nKSBhbmQgY2FuIG5vIGxvbmdlciBoYXZl IGEgc2ltcGxlIHN0YXRlbGVzcyBwYWNrZXQgZmlsdGVyIHRoYXQgd291bGQgb25seSBhbGxvdyBU Q1AvNDQzIHRvIHd3dy5leGFtcGxlLmNvbTxodHRwOi8vd3d3LmV4YW1wbGUuY29tLz4gYXMgc3Bl Y2lmaWVkIGluIHRoZSBNVUQgZmlsZS4gQXMgYSBuZXR3b3JrIGFkbWluaXN0cmF0b3IsIEkgd291 bGQgbW9zdCBsaWtlbHkgaWdub3JlIHN1Y2ggYSBwb2xpY3kuIEVzcGVjaWFsbHkgaWYgaXQgd291 bGQgcmVxdWlyZSBtZSB0byBidXkgbW9yZSBleHBlbnNpdmUgaGFyZHdhcmUsIHdoZW4gb25lIG9m IHRoZSBtYWluIGFyZ3VtZW50cyB1c2VkIGZvciBkZXBsb3lpbmcgSW9UIGlzIGFjdHVhbGx5IGNv c3Qgc2F2aW5ncy4gOy0pDQoNCkZhaXIgcG9pbnQhIDotKQ0KDQpBbm90aGVyIHRob3VnaHQsIG1h eWJlIG5vdCByZWxldmFudCBoZXJlLCBidXQgZm9yIGNvbXBsZXRlbmVzczogaWYgY29tcGFueSBF eGFtcGxlLCB3aXRoIHRoZSB3ZWJzaXRlIHd3dy5leGFtcGxlLmNvbTxodHRwOi8vd3d3LmV4YW1w bGUuY29tLz4sIHNlbGxzIDEgbWlsbGlvbiBJb1QgZGV2aWNlcyB0aGF0IGFsbCBjb25uZWN0IGJh Y2sgdG8gdGhlaXIgY2xvdWQgb24gd3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5j b20vPiBidXQgdGhlbiBoYXZlIHRvIHJlbHkgb24gdGhlIHJhdGUgbGltaXQgc2V0dGluZyBpbiBN VUQgYmVjYXVzZSBpZiBhbGwgMSBtaWxsaW9uIGRldmljZXMgd291bGQgc2VuZCBtb3JlIHRoYW4g MSBwYWNrZXQgcGVyIHNlY29uZCB0byB0aGUgd2Vic2l0ZSB3d3cuZXhhbXBsZS5jb208aHR0cDov L3d3dy5leGFtcGxlLmNvbS8+IGl0IHdvdWxkIGdvIGRvd24sIEkgd291bGQgYXJndWUgdGhhdCBp dCBpcyB0aW1lIHRvIHNjYWxlIHVwIHd3dy5leGFtcGxlLmNvbTxodHRwOi8vd3d3LmV4YW1wbGUu Y29tLz4uIDotKSBBbmQgaXQgd291bGQndCBiZSBwb3NzaWJsZSB0byBEb1MgYW55IG90aGVyIHdl YnNpdGUgdGhhbiB3d3cuZXhhbXBsZS5jb208aHR0cDovL3d3dy5leGFtcGxlLmNvbS8+IGlmIHRo ZSBNVUQgZmlsZSBpcyB3cml0dGVuIGFuZCBpbXBsZW1lbnRlZCBieSB0aGUgbmV0d29yayBjb3Jy ZWN0bHkuDQoNCkkgZG9u4oCZdCB0aGluayBhbnkgSW9UIGRldmljZSBwcm92aWRlciBjYW4gb3Ig c2hvdWxkIHJlbHkgb24gYW55IG5ldHdvcmsgYWRtaW5pc3RyYXRvciBhY3R1YWxseSBpbXBsZW1l bnRpbmcgdGhlIHBvbGljaWVzIGRlZmluZWQgdmlhIE1VRC4gVGhlc2UgY2FuIG9ubHkgZXZlciBi ZSBhZHZpc29yeSBpbiBuYXR1cmUsIHJpZ2h0Pw0KDQpIb3dldmVyLCBpZiBhIG1hbnVmYWN0dXJl ciBkZWZpbmVzIGFuIGV4cGVjdGVkIHJhdGUgbG93ZXIgdGhhbiB0aGV5IHdvdWxkIG5vcm1hbGx5 IGFsbG93LCB0aGF0IGNhbiBwb3RlbnRpYWxseSBiZSBhbiBpbnB1dCB0bywgZm9yIGV4YW1wbGUs IElEUyBjb25maWdzLg0KDQpSaWdodCwgYnV0IHRoYXQgd291bGQgZGVwZW5kIGhlYXZpbHkgb24g dGhlIElvVCBkZXZpY2UsIG5vPw0KDQpZZXMsIGl0IGNvdWxkLg0KDQpMaWtlIGEgdGVtcGVyYXR1 cmUgc2Vuc29yLCBob3cgd291bGQgSSBrbm93IGlmIEkgd2FudCB0byByZXBvcnQgdGhlIHRlbXBl cmF0dXJlIG9uY2UgYSBkYXksIG9uY2UgZXZlcnkgaG91ciwgb25jZSBldmVyeSAyIG1pbnV0ZXMg d2l0aG91dCBsb29raW5nIGF0IHRoZSBjb25maWc/IEFzIGFuIElEUyBhZG1pbiwgSSB3b3VsZCB3 b3JyeSBtb3JlIGFib3V0IHdhdGNoaW5nIGlmIHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3Igd291bGQg dHJ5IHRvIHNlbmQgcGFja2V0cyB0byBhbnl0aGluZyBlbHNlIHRoYW4gbXkgdGVtcGVyYXR1cmUg Y29sbGVjdGlvbiBzZXJ2ZXIgdGhhbiBob3cgb2Z0ZW4gaXQgcmVwb3J0cyB0aGUgdGVtcGVyYXR1 cmUgZHVyaW5nIHRoZSBkYXkuIEl0IHdvdWxkIGFsc28gb3BlbiB0aGUgZG9vciBmb3IgZmFsc2Ug cG9zaXRpdmVzLCBsaWtlIGlmIHlvdSBzYXkgeW91IHdvdWxkIG5vdCBleHBlY3QgbW9yZSB0aGFu IDUgcGFja2V0cyBwZXIgaG91ciBiZWluZyBzZW5kIHRvIHd3dy5leGFtcGxlLmNvbTxodHRwOi8v d3d3LmV4YW1wbGUuY29tLz4gYnV0IHRoZW4gYSBzb2Z0d2FyZSB1cGRhdGUgaXMgYXZhaWxhYmxl IGFuZCB0aGUgdGhpbmcgd291bGQgZXhjaGFuZ2UgbWF5YmUgMTAwIHBhY2tldHMgd2l0aCB3d3cu ZXhhbXBsZS5jb208aHR0cDovL3d3dy5leGFtcGxlLmNvbS8+IHRvIGRvd25sb2FkIHRoZSBuZXcg ZmlybXdhcmUsIG15IElEUyB3b3VsZCBmaXJlLg0KDQpJIGNvbXBsZXRlbHkgYWNjZXB0IHRoYXQg dGhlcmUgd2lsbCBiZSBtYW55IHNjZW5hcmlvcyB3aGVyZSB0aGUgb3BlcmF0aW9uYWwgcHJvZmls ZSBvZiBhIGRldmljZSBtYWtlcyBpdCB1bnN1aXRhYmxlIGZvciBzaW1wbGUsIG1hbnVmYWN0dXJl ci1kZWZpbmVkIHBvbGljeSBleHRlbnNpb24gYmV5b25kIGFjY2VzcyBjb250cm9sIHZpYSBBQ0xz LiBJZiB0aGF0IGlzIHRoZSBjYXNlLCBhIG1hbnVmYWN0dXJlciBzaG91bGQgbm90IHRyeSB0byBk ZWZpbmUgYSBwb2xpY3kgdGhhdCBtYXkgZG8gbW9yZSBoYXJtIHRoYW4gZ29vZC4NCg0KTWF5YmUg aXQgaXMganVzdCBtZSwgYnV0IEkgd291bGRuJ3Qgd2FudCB0byB1c2UgTVVEIHRvIGNvbmZpZ3Vy ZSBteSBJRFMuDQoNCk1heWJlIGl04oCZcyBqdXN0IG1lLCBidXQgSSB3b3VsZG7igJl0IHVzZSBN VUQgdG8gZGlyZWN0bHkgY29uZmlndXJlIGFueXRoaW5nLiBJIHdvdWxkIGFsd2F5cyB1c2UgYSBN VUQgZmlsZSBhcyBhbiBhZHZpc29yeSB0aGF0IEkgY291bGQgdXNlIGFzIHBhcnQgb2YgdGhlIGlu cHV0cyB0byBkZXRlcm1pbmluZyBteSBjb25maWd1cmF0aW9uIGZvciBhbGwgdGhlIHJlbGV2YW50 IG1hbmFnZW1lbnQgYW5kIHNlY3VyaXR5IGNvbXBvbmVudHMgSSB1c2UuIFRha2luZyBhbiBJRFMg YXMgYW4gZXhhbXBsZSBvZiBzb21ldGhpbmcgdGhhdCBtaWdodCBjb25zdW1lIHBvbGljeSBiZXlv bmQgQUNMcywgSSB3b3VsZCB1c2UgYW55IGV4cHJlc3Npb24gb2Yg4oCccmF0ZXPigJ0gZnJvbSBh IG1hbnVmYWN0dXJlciBwdXJlbHkgYXMgYW5vdGhlciBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gYWJv dXQgY2VydGFpbiBkZXZpY2VzIGFuZCBmb3IgbXkgYW5hbHl0aWNzIGFsZ29yaXRobXMsIG5vdCBh cyBzb21ldGhpbmcgSSBibGluZGx5IGltcGxlbWVudC4NCg0KT3ZlcmFsbCwgSSB3YXMganVzdCBt YWtpbmcgdGhlIHBvaW50IHRoYXQgaXTigJlzIG5vdCBvbmx5IGFib3V0IEFDTHMuIFRoYXTigJlz IHdoeSBJIHN1Z2dlc3RlZCBhZGRpbmcgYW4gZXh0ZW5zaW9uIHBvaW50IHRvIHRoZSBwcm9wb3Nl ZCBtb2RlbCwgcmF0aGVyIHRoYW4gbG9ja2luZyBpdCBkb3duIHRvIGp1c3QgQUNMcy4NCg0KQ2hl ZXJzLA0KDQpFaW5hcg0KDQoNCmNoZWVycywNClRob3JzdGVuDQoNCg0KQ2hlZXJzLA0KDQpFaW5h cg0KDQpPbiAxMSBTZXAgMjAxNywgYXQgMTY6MjgsIFRob3JzdGVuIERhaG0gPHRob3JzdGVuZGx1 eEBnb29nbGUuY29tPG1haWx0bzp0aG9yc3RlbmRsdXhAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpI aSBSYW5nYSwNCg0KSSB0aGluayB0aGlzIHdvdWxkIGdvIGJleW9uZCB0aGUgam9iIG9mIE1VRCBh bmQgd291bGQgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRv ciB0byBlbmZvcmNlIHJhdGUgbGltaXRzIHByb2JhYmx5IGF0IHRoZSBzYW1lIG5ldHdvcmsgZGV2 aWNlcyB0aGF0IGFyZSBhbHNvIHJlc3BvbnNpYmxlIGZvciBpbXBsZW1lbnRpbmcgdGhlIHBhY2tl dCBmaWx0ZXJzIGFuZCBzdWNoLg0KDQpjaGVlcnMsDQpUaG9yc3Rlbg0KDQpPbiA4IFNlcHRlbWJl ciAyMDE3IGF0IDE5OjU0LCBNLiBSYW5nYW5hdGhhbiA8bXJhbmdhQGdtYWlsLmNvbTxtYWlsdG86 bXJhbmdhQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGVsbG8hDQoNCk1VRCBjdXJyZW50bHkgZG9lcyBu b3QgZW5mb3JjZSByZXN0cmljdGlvbnMgb24gdGVtcG9yYWwgYmVoYXZpb3IuIEZvciBleGFtcGxl LCBJIGNhbm5vdCBzcGVjaWZ5IGhvdyBtYW55IHRpbWVzIHBlciBzZWNvbmQgYSBkZXZpY2UgaXMg YWxsb3dlZCB0byBjb25uZWN0IHRvIGEgcmVtb3RlIElQIGFkZHJlc3MgYW5kIHBvcnQuDQoNCldv dWxkIHRoaXMgYmUgd29ydGggY29uc2lkZXJpbmc/DQoNClVzZSBjYXNlOg0KDQpERE9TIGF0dGFj ayBtaXRpZ2F0aW9uICg/KQ0KDQoNClJhbmdhDQoNCi0tDQpNLiBSYW5nYW5hdGhhbg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxp bmcgbGlzdA0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQoNCg0KDQotLQ0KVGhvcnN0 ZW4gRGFobQ0KDQpOZXR3b3JrIEVuZ2luZWVyDQpHb29nbGUgSXJlbGFuZCBMdGQuDQpUaGUgR2Fz d29ya3MsIEJhcnJvdyBTdHJlZXQNCkR1YmxpbiA0LCAgSXJlbGFuZA0KDQpSZWdpc3RlcmVkIGlu IER1YmxpbiwgSXJlbGFuZA0KUmVnaXN0cmF0aW9uIE51bWJlcjogMzY4MDQ3DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlz dA0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQoNCg0KDQotLQ0KVGhvcnN0ZW4gRGFo bQ0KDQpOZXR3b3JrIEVuZ2luZWVyDQpHb29nbGUgSXJlbGFuZCBMdGQuDQpUaGUgR2Fzd29ya3Ms IEJhcnJvdyBTdHJlZXQNCkR1YmxpbiA0LCAgSXJlbGFuZA0KDQpSZWdpc3RlcmVkIGluIER1Ymxp biwgSXJlbGFuZA0KUmVnaXN0cmF0aW9uIE51bWJlcjogMzY4MDQ3DQoNCg== --_000_B2B3519C17904D98A5C01F2E8A22F806ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxMiBT ZXAgMjAxNywgYXQgMTQ6NDgsIFRob3JzdGVuIERhaG0gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9y c3RlbmRsdXhAZ29vZ2xlLmNvbSIgY2xhc3M9IiI+dGhvcnN0ZW5kbHV4QGdvb2dsZS5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgRWluYXIsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj50aGFua3MgZm9y IHRoZSByZXBseS4gTGV0IG1lIGNsYXJpZnkgbXkgdGhvdWdodHMgYmVsb3cuIDotKTwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMSBTZXB0ZW1iZXIgMjAxNyBhdCAx NzowMywgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pDQo8c3BhbiBkaXI9Imx0ciIgY2xh c3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5CdXQgSSBkbyBhbHNvIGFncmVlIHRoYXQgdGhpbmdzIGxpa2UgcmF0ZSBsaW1p dHMgYXJlLCBhbmQgc2hvdWxkIGNvbnRpbnVlIHRvIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRo ZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQgcmF0 ZSBsaW1pdHMgZG8gd2UgdGFsayBhYm91dD8gU29tZXRoaW5nIGxpa2UgJnF1b3Q7bWF4aW11bSAx MCUgb2YgdGhlIGF2YWlsYWJsZSBuZXR3b3JrIGJhbmR3aWR0aCZxdW90OyBpcyBzdGlsbCBzaWdu aWZpY2FudCB0cmFmZmljLCBJIGhhdmUgYSBidW5jaCBvZiAxMDBHIGxpbmtzIGluIG15IG5ldHdv cmsuIE9yIGRvIHdlIHRhbGsgYWJvdXQgUVBTIChRdWVyaWVzIFBlciBTZWNvbmQpPzwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGFncmVlIHRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCDi gJxyYXRlc+KAnSB0aGF0IHdlIGNhbiBwb3RlbnRpYWxseSB0YWxrIGFib3V0LCBhbmQgdGhhdCBj aGFyYWN0ZXJpc2F0aW9uIG9mIHRoaXMgaW4gYSB3YXkgdGhhdCBjYW4gYmUgdXNlZnVsbHkgZXhw cmVzc2VkIGFzIGEg4oCccG9saWN54oCdICh5ZWFoLCBvdmVydXNlZCB0ZXJtLCBzb3JyeSE7LSkg aXMgYSBzZXBhcmF0ZSB0YXNrIGluIGFuZCBvZiBpdHNlbGYuIEluIGVzc2VuY2UsIEkgd291bGRu 4oCZdA0KIHNlZWsgdG8gZGVmaW5lIHdoYXQgYSBuZXR3b3JrIGFkbWluaXN0cmF0b3LigJlzIOKA nHJhdGUgbGltaXRz4oCdIGFyZSwgYnV0LCBmcm9tIHRoZSBNVUQgcGVyc3BlY3RpdmUsIHRyeSBh bmQgZ2l2ZSBhIHVzZWZ1bCBjaGFyYWN0ZXJpc2F0aW9uIG9mIGl0cyBleHBlY3RlZCBiZWhhdmlv ci4gVGhpcyBjaGFyYWN0ZXJpc2F0aW9uIGNvdWxkIHBlcmhhcHMgYmUgdXNlZCBieSB0aGUgbmV0 d29yayBhZG1pbmlzdHJhdG9yIHRvIGNvbXBsZW1lbnQgdGhlaXIgb3duDQogcG9saWNpZXMuPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPkZvciBleGFtcGxlLCBpZiB0aGUgYWRtaW5pc3RyYXRvciBkZXRlcm1pbmVz IHRoYXQgaGVyIHBvbGljeSBpcyDigJwyMCBjb25uZWN0aW9uIGF0dGVtcHRzIHBlciBzZWNvbmTi gJ0sIGEgTVVEIHBvbGljeSBzYXlpbmcgYSBkZXZpY2UgdHlwZSBtaWdodCBiZSDigJwzMCBjb25u ZWN0aW9uIGF0dGVtcHRzIHBlciBzZWNvbmTigJ0gd291bGQganVzdCBiZSB0YWtlbiBhcyBhbiBh ZHZpc29yeSwgbm90IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvDQogYmUgZW1ib2RpZWQgaW4gcG9s aWN5LiA8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28gbm93IEkgaGF2ZSB0byBrZWVwIHRyYWNr IG9mIHRoZSBwYWNrZXRzLCBrZWVwIGEgc3RhdGUsIGJlY2F1c2UgSSBuZWVkIHRvIGNvdW50IHBh Y2tldHMuIFRoYXQgbWVhbnMgSSBub3cgRERvUyBteSBvd24gbmV0d29yayBieSBoYXZpbmcgdG8g a2VlcCBodWdlIGNvbm5lY3Rpb24gdGFibGUgc29tZXdoZXJlIChiZWNhdXNlIHdpdGggSW9ULCB3 ZSBtYXkgaGF2ZSB0aG91c2FuZHMgb2YgZGlmZmVyZW50IElvVCBkZXZpY2VzDQogaW4gYSBzaW5n bGUgYnVpbGRpbmcpIGFuZCBjYW4gbm8gbG9uZ2VyIGhhdmUgYSBzaW1wbGUgc3RhdGVsZXNzIHBh Y2tldCBmaWx0ZXIgdGhhdCB3b3VsZCBvbmx5IGFsbG93IFRDUC80NDMgdG8NCjxhIGhyZWY9Imh0 dHA6Ly93d3cuZXhhbXBsZS5jb20vIiBjbGFzcz0iIj53d3cuZXhhbXBsZS5jb208L2E+IGFzIHNw ZWNpZmllZCBpbiB0aGUgTVVEIGZpbGUuIEFzIGEgbmV0d29yayBhZG1pbmlzdHJhdG9yLCBJIHdv dWxkIG1vc3QgbGlrZWx5IGlnbm9yZSBzdWNoIGEgcG9saWN5LiBFc3BlY2lhbGx5IGlmIGl0IHdv dWxkIHJlcXVpcmUgbWUgdG8gYnV5IG1vcmUgZXhwZW5zaXZlIGhhcmR3YXJlLCB3aGVuIG9uZSBv ZiB0aGUgbWFpbiBhcmd1bWVudHMNCiB1c2VkIGZvciBkZXBsb3lpbmcgSW9UIGlzIGFjdHVhbGx5 IGNvc3Qgc2F2aW5ncy4gOy0pPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5GYWlyIHBvaW50ISA6LSk8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPkFub3RoZXIgdGhvdWdodCwgbWF5 YmUgbm90IHJlbGV2YW50IGhlcmUsIGJ1dCBmb3IgY29tcGxldGVuZXNzOiBpZiBjb21wYW55IEV4 YW1wbGUsIHdpdGggdGhlIHdlYnNpdGUNCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20v IiBjbGFzcz0iIj53d3cuZXhhbXBsZS5jb208L2E+LCBzZWxscyAxIG1pbGxpb24gSW9UIGRldmlj ZXMgdGhhdCBhbGwgY29ubmVjdCBiYWNrIHRvIHRoZWlyIGNsb3VkIG9uDQo8YSBocmVmPSJodHRw Oi8vd3d3LmV4YW1wbGUuY29tLyIgY2xhc3M9IiI+d3d3LmV4YW1wbGUuY29tPC9hPiBidXQgdGhl biBoYXZlIHRvIHJlbHkgb24gdGhlIHJhdGUgbGltaXQgc2V0dGluZyBpbiBNVUQgYmVjYXVzZSBp ZiBhbGwgMSBtaWxsaW9uIGRldmljZXMgd291bGQgc2VuZCBtb3JlIHRoYW4gMSBwYWNrZXQgcGVy IHNlY29uZCB0byB0aGUgd2Vic2l0ZQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS8i IGNsYXNzPSIiPnd3dy5leGFtcGxlLmNvbTwvYT4gaXQgd291bGQgZ28gZG93biwgSSB3b3VsZCBh cmd1ZSB0aGF0IGl0IGlzIHRpbWUgdG8gc2NhbGUgdXANCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXhh bXBsZS5jb20vIiBjbGFzcz0iIj53d3cuZXhhbXBsZS5jb208L2E+LiA6LSkgQW5kIGl0IHdvdWxk J3QgYmUgcG9zc2libGUgdG8gRG9TIGFueSBvdGhlciB3ZWJzaXRlIHRoYW4NCjxhIGhyZWY9Imh0 dHA6Ly93d3cuZXhhbXBsZS5jb20vIiBjbGFzcz0iIj53d3cuZXhhbXBsZS5jb208L2E+IGlmIHRo ZSBNVUQgZmlsZSBpcyB3cml0dGVuIGFuZCBpbXBsZW1lbnRlZCBieSB0aGUgbmV0d29yayBjb3Jy ZWN0bHkuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGRvbuKAmXQgdGhpbmsgYW55IElvVCBkZXZp Y2UgcHJvdmlkZXIgY2FuIG9yIHNob3VsZCByZWx5IG9uIGFueSBuZXR3b3JrIGFkbWluaXN0cmF0 b3IgYWN0dWFsbHkgaW1wbGVtZW50aW5nIHRoZSBwb2xpY2llcyBkZWZpbmVkIHZpYSBNVUQuIFRo ZXNlIGNhbiBvbmx5IGV2ZXIgYmUgYWR2aXNvcnkgaW4gbmF0dXJlLCByaWdodD88L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIsIGlmIGEgbWFudWZhY3R1cmVyIGRlZmluZXMgYW4g ZXhwZWN0ZWQgcmF0ZSBsb3dlciB0aGFuIHRoZXkgd291bGQgbm9ybWFsbHkgYWxsb3csIHRoYXQg Y2FuIHBvdGVudGlhbGx5IGJlIGFuIGlucHV0IHRvLCBmb3IgZXhhbXBsZSwgSURTIGNvbmZpZ3Mu PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJpZ2h0LCBidXQgdGhhdCB3b3VsZCBkZXBlbmQgaGVh dmlseSBvbiB0aGUgSW9UIGRldmljZSwgbm8/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIGl0 IGNvdWxkLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+TGlrZSBhIHRlbXBl cmF0dXJlIHNlbnNvciwgaG93IHdvdWxkIEkga25vdyBpZiBJIHdhbnQgdG8gcmVwb3J0IHRoZSB0 ZW1wZXJhdHVyZSBvbmNlIGEgZGF5LCBvbmNlIGV2ZXJ5IGhvdXIsIG9uY2UgZXZlcnkgMiBtaW51 dGVzIHdpdGhvdXQgbG9va2luZyBhdCB0aGUgY29uZmlnPyBBcyBhbiBJRFMgYWRtaW4sIEkgd291 bGQgd29ycnkgbW9yZSBhYm91dCB3YXRjaGluZyBpZiB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yIHdv dWxkDQogdHJ5IHRvIHNlbmQgcGFja2V0cyB0byBhbnl0aGluZyBlbHNlIHRoYW4gbXkgdGVtcGVy YXR1cmUgY29sbGVjdGlvbiBzZXJ2ZXIgdGhhbiBob3cgb2Z0ZW4gaXQgcmVwb3J0cyB0aGUgdGVt cGVyYXR1cmUgZHVyaW5nIHRoZSBkYXkuIEl0IHdvdWxkIGFsc28gb3BlbiB0aGUgZG9vciBmb3Ig ZmFsc2UgcG9zaXRpdmVzLCBsaWtlIGlmIHlvdSBzYXkgeW91IHdvdWxkIG5vdCBleHBlY3QgbW9y ZSB0aGFuIDUgcGFja2V0cyBwZXIgaG91ciBiZWluZyBzZW5kDQogdG8gPGEgaHJlZj0iaHR0cDov L3d3dy5leGFtcGxlLmNvbS8iIGNsYXNzPSIiPnd3dy5leGFtcGxlLmNvbTwvYT4gYnV0IHRoZW4g YSBzb2Z0d2FyZSB1cGRhdGUgaXMgYXZhaWxhYmxlIGFuZCB0aGUgdGhpbmcgd291bGQgZXhjaGFu Z2UgbWF5YmUgMTAwIHBhY2tldHMgd2l0aA0KPGEgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxlLmNv bS8iIGNsYXNzPSIiPnd3dy5leGFtcGxlLmNvbTwvYT4gdG8gZG93bmxvYWQgdGhlIG5ldyBmaXJt d2FyZSwgbXkgSURTIHdvdWxkIGZpcmUuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGNvbXBsZXRl bHkgYWNjZXB0IHRoYXQgdGhlcmUgd2lsbCBiZSBtYW55IHNjZW5hcmlvcyB3aGVyZSB0aGUgb3Bl cmF0aW9uYWwgcHJvZmlsZSBvZiBhIGRldmljZSBtYWtlcyBpdCB1bnN1aXRhYmxlIGZvciBzaW1w bGUsIG1hbnVmYWN0dXJlci1kZWZpbmVkIHBvbGljeSBleHRlbnNpb24gYmV5b25kIGFjY2VzcyBj b250cm9sIHZpYSBBQ0xzLiBJZiB0aGF0IGlzIHRoZSBjYXNlLCBhIG1hbnVmYWN0dXJlciBzaG91 bGQgbm90IHRyeSB0bw0KIGRlZmluZSBhIHBvbGljeSB0aGF0IG1heSBkbyBtb3JlIGhhcm0gdGhh biBnb29kLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+TWF5YmUgaXQgaXMg anVzdCBtZSwgYnV0IEkgd291bGRuJ3Qgd2FudCB0byB1c2UgTVVEIHRvIGNvbmZpZ3VyZSBteSBJ RFMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5NYXliZSBpdOKAmXMganVzdCBtZSwgYnV0IEkgd291 bGRu4oCZdCB1c2UgTVVEIHRvIDxpIGNsYXNzPSIiPmRpcmVjdGx5PC9pPiZuYnNwO2NvbmZpZ3Vy ZSBhbnl0aGluZy4gSSB3b3VsZCBhbHdheXMgdXNlIGEgTVVEIGZpbGUgYXMgYW4gYWR2aXNvcnkg dGhhdCBJIGNvdWxkIHVzZSBhcyBwYXJ0IG9mIHRoZSBpbnB1dHMgdG8gZGV0ZXJtaW5pbmcgbXkg Y29uZmlndXJhdGlvbiBmb3IgYWxsIHRoZSByZWxldmFudCBtYW5hZ2VtZW50IGFuZCBzZWN1cml0 eQ0KIGNvbXBvbmVudHMgSSB1c2UuIFRha2luZyBhbiBJRFMgYXMgYW4gZXhhbXBsZSBvZiBzb21l dGhpbmcgdGhhdCBtaWdodCBjb25zdW1lIHBvbGljeSBiZXlvbmQgQUNMcywgSSB3b3VsZCB1c2Ug YW55IGV4cHJlc3Npb24gb2Yg4oCccmF0ZXPigJ0gZnJvbSBhIG1hbnVmYWN0dXJlciBwdXJlbHkg YXMgYW5vdGhlciBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgY2VydGFpbiBkZXZpY2VzIGFu ZCBmb3IgbXkgYW5hbHl0aWNzIGFsZ29yaXRobXMsIG5vdCBhcw0KIHNvbWV0aGluZyBJIGJsaW5k bHkgaW1wbGVtZW50LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+T3Zl cmFsbCwgSSB3YXMganVzdCBtYWtpbmcgdGhlIHBvaW50IHRoYXQgaXTigJlzIG5vdCBvbmx5IGFi b3V0IEFDTHMuIFRoYXTigJlzIHdoeSBJIHN1Z2dlc3RlZCBhZGRpbmcgYW4gZXh0ZW5zaW9uIHBv aW50IHRvIHRoZSBwcm9wb3NlZCBtb2RlbCwgcmF0aGVyIHRoYW4gbG9ja2luZyBpdCBkb3duIHRv IGp1c3QgQUNMcy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj5DaGVlcnMsPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5FaW5hcjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+Y2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaG9y c3RlbiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PbiAxMSBTZXAgMjAxNywgYXQgMTY6 MjgsIFRob3JzdGVuIERhaG0gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9yc3RlbmRsdXhAZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRob3JzdGVuZGx1eEBnb29nbGUuY29tPC9h PiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0ibV8tODI4NDczODU4MTU3NzQ4Nzk2OEFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBSYW5nYSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQpJIHRoaW5rIHRoaXMgd291bGQgZ28gYmV5b25kIHRoZSBqb2Ig b2YgTVVEIGFuZCB3b3VsZCBiZSBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgbmV0d29yayBhZG1p bmlzdHJhdG9yIHRvIGVuZm9yY2UgcmF0ZSBsaW1pdHMgcHJvYmFibHkgYXQgdGhlIHNhbWUgbmV0 d29yayBkZXZpY2VzIHRoYXQgYXJlIGFsc28gcmVzcG9uc2libGUgZm9yIGltcGxlbWVudGluZyB0 aGUgcGFja2V0IGZpbHRlcnMgYW5kIHN1Y2guDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5jaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRob3Jz dGVuPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gOCBTZXB0ZW1iZXIgMjAxNyBhdCAxOTo1NCwg TS4gUmFuZ2FuYXRoYW4gPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzptcmFuZ2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bXJhbmdhQGdt YWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGVsbG8hPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk1VRCBjdXJyZW50bHkgZG9lcyBub3Qg ZW5mb3JjZSByZXN0cmljdGlvbnMgb24gdGVtcG9yYWwgYmVoYXZpb3IuIEZvciBleGFtcGxlLCBJ IGNhbm5vdCBzcGVjaWZ5IGhvdyBtYW55IHRpbWVzIHBlciBzZWNvbmQgYSBkZXZpY2UgaXMgYWxs b3dlZCB0byBjb25uZWN0IHRvIGEgcmVtb3RlIElQIGFkZHJlc3MgYW5kIHBvcnQuDQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCldvdWxkIHRoaXMgYmUgd29ydGggY29uc2lk ZXJpbmc/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlVzZSBjYXNlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5ERE9TIGF0dGFjayBtaXRpZ2F0aW9uICg/KTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClJhbmdhPHNw YW4gY2xhc3M9Im1fLTgyODQ3Mzg1ODE1Nzc0ODc5NjhIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4 ODg4IiBjbGFzcz0iIj48YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCi0tIDxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1fLTgyODQ3Mzg1ODE1Nzc0ODc5Njht Xzc3MzQ5ODg2NjAxNjIyMTU0MWdtYWlsX3NpZ25hdHVyZSI+TS4gUmFuZ2FuYXRoYW48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9mb250Pjwv c3Bhbj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPUFNBV0cgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9QU0FXR0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9sPHdiciBjbGFzcz0iIj5pc3RpbmZvL29wc2F3ZzwvYT48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGVhcj0iYWxsIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQotLSA8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtXy04Mjg0NzM4NTgxNTc3NDg3 OTY4Z21haWxfc2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj4NClRo b3JzdGVuIERhaG08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOZXR3b3JrIEVuZ2luZWVy PGJyIGNsYXNzPSIiPg0KR29vZ2xlIElyZWxhbmQgTHRkLjxiciBjbGFzcz0iIj4NClRoZSBHYXN3 b3JrcywgQmFycm93IFN0cmVldDxiciBjbGFzcz0iIj4NCkR1YmxpbiA0LCZuYnNwOyBJcmVsYW5k PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnaXN0ZXJlZCBpbiBEdWJsaW4sIElyZWxh bmQ8YnIgY2xhc3M9IiI+DQpSZWdpc3RyYXRpb24gTnVtYmVyOiAzNjgwNDc8L2Rpdj4NCjwvZGl2 Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCk9QU0FXRyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ T1BTQVdHQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3RpbmZvL29wc2F3 ZzwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGVhcj0iYWxsIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQotLSA8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9zaWduYXR1cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPlRob3Jz dGVuIERhaG08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOZXR3b3JrIEVuZ2luZWVyPGJy IGNsYXNzPSIiPg0KR29vZ2xlIElyZWxhbmQgTHRkLjxiciBjbGFzcz0iIj4NClRoZSBHYXN3b3Jr cywgQmFycm93IFN0cmVldDxiciBjbGFzcz0iIj4NCkR1YmxpbiA0LCZuYnNwOyBJcmVsYW5kPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnaXN0ZXJlZCBpbiBEdWJsaW4sIElyZWxhbmQ8 YnIgY2xhc3M9IiI+DQpSZWdpc3RyYXRpb24gTnVtYmVyOiAzNjgwNDc8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B2B3519C17904D98A5C01F2E8A22F806ciscocom_-- From nobody Wed Sep 13 02:15:14 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 8738D1329C8; Wed, 13 Sep 2017 02:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.392 X-Spam-Level: X-Spam-Status: No, score=-13.392 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, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gyuAzniaf0dU; Wed, 13 Sep 2017 02:15:05 -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 A0880132195; Wed, 13 Sep 2017 02:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9674; q=dns/txt; s=iport; t=1505294104; x=1506503704; h=to:from:subject:cc:message-id:date:mime-version; bh=SeAHMijWT3DZOFtOgZ/z0nF9f160qweumeeaAn0LPgo=; b=LWHn8MTuypvUZTAKTYD0RYS1uoRpedSCBJ7Od6ZkeSqAGBcvr3mfxeSi hmDMaKGb8jCaEvB53hicP7pHNsJvb4h3jmwicX20LaZ0eWpXkVATWihF3 FC18yqTf+Cz0NBi8AtUfi5KPf72bCSfuUVMLOuYzSTN4E2XDPHg6WReEd 4=; X-IronPort-AV: E=Sophos;i="5.42,387,1500940800"; d="scan'208,217";a="657428973" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 09:15:01 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8D9F1iG017083; Wed, 13 Sep 2017 09:15:01 GMT To: draft-ietf-opsawg-mud@ietf.org From: Benoit Claise Cc: draft-ietf-netmod-acl-model@ietf.org, "opsawg@ietf.org" , "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" Message-ID: <5eeb51f5-56c1-5f82-6c33-04d9cf15608e@cisco.com> Date: Wed, 13 Sep 2017 11:15:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2FEC69CE5F624212BFAE981C" Content-Language: en-US Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-mud: YANG validation 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, 13 Sep 2017 09:15:08 -0000 This is a multi-part message in MIME format. --------------2FEC69CE5F624212BFAE981C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear draft-ietf-opsawg-mud authors, A new version of the draft-ietf-netmod-acl-model has been posted, and it now passes validation. It failed previously with:     /ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'upper-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found ./ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'lower-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found     ... As a consequence, this error is not reported any longer in the draft-ietf-opsawg-mud YANG models. However, there are still some errors: warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl'). warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl'). warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl'). warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl'). warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl'). warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl'). warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl'). warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl'). warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl'). warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl'). warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl'). warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl'). warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl'). warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl'). See http://www.claise.be/IETFYANGPageCompilation.html Please correct those mistakes and post a new version. Also, make sure both revisions match (for all your YANG modules in the draft) and are up to date    file "ietf-acldns@2016-09-07.yang"    module ietf-acldns {      yang-version 1.1;      namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";      prefix "ietf-acldns";     revision "2016-07-20" {        description "Base version of dnsname extension of ACL model";        reference "RFC XXXX: Manufacturer Usage Description                   Specification";      } While this revision mismatch seems like a minor thing, this is a pain from a tooling point of view (as we need to index YANG modules per name, revision, organization) We discovered that version 8 contains a newer revision than the version 9. That confused our tooling. version 8: file "ietf-acldns@2016-07-20.yang" ... revision "2017-07-03" { description "Clone across IP ACL types."; reference "RFC XXXX: Manufacturer Usage Description Specification"; } version 9: file "ietf-acldns@2016-09-07.yang" ... revision "2016-07-20" { description "Base version of dnsname extension of ACL model"; reference "RFC XXXX: Manufacturer Usage Description Specification"; } All these metadata are important. We're working on: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-acldns Also, is your YANG module NMDA compliant? It reports tree-type as "unclassified". Regards, Benoit --------------2FEC69CE5F624212BFAE981C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear draft-ietf-opsawg-mud authors,

A new version of the draft-ietf-netmod-acl-model has been posted, and it now passes validation. It failed previously with:
    /ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'upper-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found
./ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'lower-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found
    ...

As a consequence, this error is not reported any longer in the draft-ietf-opsawg-mud YANG models.
However, there are still some errors:
warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl').
warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl').
warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl').
warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl').
warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl').

warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl').
warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl').
warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl').
warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl').
warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl').
See http://www.claise.be/IETFYANGPageCompilation.html

Please correct those mistakes and post a new version.

Also, make sure both revisions match (for all your YANG modules in the draft) and are up to date
   <CODE BEGINS>file "ietf-acldns@2016-09-07.yang"
   module ietf-acldns {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
     prefix "ietf-acldns";

    revision "2016-07-20" {
       description "Base version of dnsname extension of ACL model";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }

While this revision mismatch seems like a minor thing, this is a pain from a tooling point of view (as we need to index YANG modules per name, revision, organization)
We discovered that version 8 contains a newer revision than the version 9. That confused our tooling.
version 8:
   <CODE BEGINS>file "ietf-acldns@2016-07-20.yang"

   ...

     revision "2017-07-03" {
       description "Clone across IP ACL types.";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }

  
version 9: 
   <CODE BEGINS>file "ietf-acldns@2016-09-07.yang"

   ...

     revision "2016-07-20" {
       description "Base version of dnsname extension of ACL model";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }
All these metadata are important.
We're working on: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-acldns
Also, is your YANG module NMDA compliant? It reports tree-type as "unclassified".

Regards, Benoit
--------------2FEC69CE5F624212BFAE981C-- From nobody Wed Sep 13 06:53:37 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 8A507132949 for ; Wed, 13 Sep 2017 06:53:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tsheXyt38bha for ; Wed, 13 Sep 2017 06:53:34 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 ACFFA13232C for ; Wed, 13 Sep 2017 06:53:33 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id q132so778058lfe.5 for ; Wed, 13 Sep 2017 06:53:33 -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=PAOJN7/sMoTGbghC6KT4nxowyEGes9pSgZ174Xrev18=; b=L0y/0B/hVD92fQJFAKtP5QMe0dn35RFKOpyPoalMG96ObbFBVt+EYLAncMDaYNmKxc zZG9ZIsnmbrCCGEoj4KeMCfRG+uuqOu0rC70KsByNAfKREwDeaKF2KSmiPfBqm+Cij/O EvaqDH92aceNVCbwbk0Po8J6LiR0JUpgS1jZbBpcOYP/RwPaKddsKZuMovOPXK0rzrqA p5KE6APT37oQlNfd8QTODShjNNLrFShSiCVcaqIXjvVl2hVBm7+HUU9jCt2z3YBYkKyu J9c3BhRqB3mYjABM3qKAj7zRl8L/NL5332Vy037X21g77YBRJ2778ZcH0Ov8u/4Zz/Cn OKpA== 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=PAOJN7/sMoTGbghC6KT4nxowyEGes9pSgZ174Xrev18=; b=la0/7S+SoLqxa9OMiU9ZitM/fBsqshw4cHUwbKutsBtWnxFCo1ziz/3SfgJgX9I8Sj 4K9iq1R6MWn5D2v4TguXXklazaGLm1RKpuv4e/XcYsze4cJzO1JtrojM18KzU3KCU1F6 vswpqK7DzkzOb5OZOlodDx801ztf6xnFylExfgM86BTKrDwhHvZhoAemFdZa2Qx6Xbwh LSRqRxAey6eOGk8XyF7xoeZQpjmKAY08HJWhD5hHgLSXAYgjZtAkRMmiiXojnjDBjC6C dzDUcodxphGq+MfSIkkcSYsnRoi4V4ejN4/EIq9OIUGfcZYI76ye/jtCujM4MgWr1cb8 6yYg== X-Gm-Message-State: AHPjjUirz8ELSP/DIa5JB+Ne+tgkQpFUK0ekWuRqkQqV2rf3FtU14twS delosMgQhD1HCkxIfWRDiVwEyOIHHTgR/IXaEIsGYQ== X-Google-Smtp-Source: ADKCNb7g5HxdYH8uI1cTGPymckFCVBFerd1rYT6zMirjIoDt8K8o+9U4Dx1I3yZo1S0RLnqMZ5XsiMgWOwtdvnJ16L4= X-Received: by 10.46.34.67 with SMTP id i64mr7581288lji.71.1505310811826; Wed, 13 Sep 2017 06:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.146 with HTTP; Wed, 13 Sep 2017 06:53:01 -0700 (PDT) In-Reply-To: References: From: Thorsten Dahm Date: Wed, 13 Sep 2017 14:53:01 +0100 Message-ID: To: "Einar Nilsen-Nygaard (einarnn)" Cc: "M. Ranganathan" , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary="f4030439ea503792000559127c42" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-08: Restricting temporal behavior using MUD. 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, 13 Sep 2017 13:53:35 -0000 --f4030439ea503792000559127c42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 12 September 2017 at 16:34, Einar Nilsen-Nygaard (einarnn) < einarnn@cisco.com> wrote: > Maybe it=E2=80=99s just me, but I wouldn=E2=80=99t use MUD to *directly* = configure > anything. > I couldn't agree more. Yes, absolutely, full ACK. It's only an advise given by the manufacturer, not a network confg file. cheers, Thorsten --=20 Thorsten Dahm Network Engineer Google Ireland Ltd. The Gasworks, Barrow Street Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047 --f4030439ea503792000559127c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 1= 2 September 2017 at 16:34, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.c= om> wrote:
Maybe it=E2=80=99s just me, b= ut I wouldn=E2=80=99t use MUD to directly=C2=A0configure anything.

I couldn't agree more.= Yes, absolutely, full ACK. It's only an advise given by the manufactur= er, not a network confg file.

cheers,
T= horsten

--
Thorsten Dahm

Network Engineer=
Google Ireland Ltd.
The Gasworks, Barrow Street
Dublin 4,=C2=A0 I= reland

Registered in Dublin, Ireland
Registration Number: 368047<= /div>
--f4030439ea503792000559127c42-- From nobody Wed Sep 13 09:51:50 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 41E9D1321DF for ; Wed, 13 Sep 2017 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 il6QWo8qF87a for ; Wed, 13 Sep 2017 09:51:43 -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 2284D132D8F for ; Wed, 13 Sep 2017 09:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17479; q=dns/txt; s=iport; t=1505321503; x=1506531103; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=DDWFMbIyiBfjLW8R/s7rDyASjIx/ZRIYxEbKRFhr8uM=; b=kXxaGfwo/hWrdCta93fmC5maZRfAdeVN4D8Q8Db1UxuVNhGbV2t+u8f4 rbs7XS9Al+mTuVYaGuRDmCte8ELjfsAJMn6hqTe3Lc43KSRkxOqLfzMKE khTBJ8fUvdZQGpyo9fz01fVoU4ngsm2LGGMxYzHygfZdG06OfODT6b+zs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAwBmYblZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy2CJoN3ixWQeiuQaYVNggQKggODOwKFGBQBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAwEjTwwLCxEBAgECKwICSQYIBgEMBgIBAYolCKwyfoInJ4sEAQEBAQEFAQEBA?= =?us-ascii?q?QEBAQEggyuDUoIOgn2EQCE3gnOCYQEEigaWc4psiWeCE4Vog1qHH41bh1WBOTY?= =?us-ascii?q?hgQ0yIQgcFYVjHIFpPjaLXwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,389,1500940800"; d="scan'208,217";a="657440259" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 16:51:40 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8DGpdAM013682; Wed, 13 Sep 2017 16:51:40 GMT To: Warren Kumari , opsawg@ietf.org References: From: Benoit Claise Message-ID: <57bf897c-e73d-9f80-a950-e4c4488afd34@cisco.com> Date: Wed, 13 Sep 2017 18:51:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------958F9C1864F0F9B3DFCCE3BF" Content-Language: en-US Archived-At: Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Wed, 13 Sep 2017 16:51:48 -0000 This is a multi-part message in MIME format. --------------958F9C1864F0F9B3DFCCE3BF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Warren asked me to review this document part of the AD review. I know we're in last call right now: Whether the comments are part of AD review or IETF LC comment doesn't matter at this point in time. Here is my feedback. Figure 3: Network configuration model is a brand new term that is only mentioned in the figure, and not explained. In the same figure, could the "Device Configuration Model" be renamed to RFC 8199 "Network Element YANG module" (this is what you did in figure 4 anyway) - section 6.2 "service delivery and network element model work" Some of these models are classified as service delivery models, while others have details that are related to specific element configuration and so are classed as network element models (also called device models). Next to each model description, that would help the audience to clarify what the correct term is: customer service model, service delivery model, network service YANG modules [RFC8199] - In RFC 8199, we made a distinction between model and YANG modules. This is why we defined the terms "Network Service YANG_modules_" and "Network Element YANG_modules_" and not models. You should follow this convention. After all, from the abstract, this document focuses on YANG. Ex: should "model" be replaced by "YANG module"? - section 6.4 "The MEF architecture". Do we want to mention that MEF currently focuses on the customer service model? - I'm glad you cleverly avoided the term "intend" Regards, Benoit > Apologies, I forgot to CC the WG. > > I'll also be asking Benoit to give it the once over, as he is much > more familiar with this topic. > W > > ---------- Forwarded message ---------- > From: Warren Kumari > Date: Mon, Sep 4, 2017 at 8:43 PM > Subject: AD Review of draft-ietf-opsawg-service-model-explained > To: draft-ietf-opsawg-service-model-explained.all@ietf.org > > > Hi there, > > First off, thanks for a really well written document -- this is one of > the cleanest AD reviews I've done. > I do have some very minor grammar nits. > I'd prefer a new version with these addressed, but they are all > sufficiently minor that I'm also OK starting the LC as is. Please let > me know which you'd prefer. > > > > > 1: While unfortunate, I think many will not understand the q.v. in the > Service definition in Section 2. Terms and Concepts. Perhaps break it > out, or more clearly point where more info is to be found. > > 2: Section 6.3. Customer Service Model Work > "The most advanced presents the L3VPN service..." - I'd suggest > "Currently the most advanced presents the L3VPN service..." -- there > may be another, more advanced one soon... > > The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason > / Rational / format. > > > Section Abstract > This document describes service models as used within the IETF, and > [O] IETF, and > [P] IETF and > [R] grammar > > > Section 1. Introduction. > > Within the context of Software Defined Networking (SDN) [RFC7149] > [RFC7426] YANG data models may be used on the interface between a > [O] [RFC7426] YANG data models > [P] [RFC7426], YANG data models > [R] grammar > > Ultimately they could be used in online, software-driven dynamic > systems, and eventually as part of an SDN system. > [O] systems, and > [P] systems and > [R] grammar > > Equally, this document clarifies what a service model is > not, and dispels some common misconceptions. > [O] not, and > [P] not and > [R] grammar - I think. > > > > Section 2. Terms and Concepts > > An example of where such details are relevant to the customer > are when they describe the behavior or interactions on the > [O] are when > [P] is when > [R] subject/verb agreement ("An example [...] is [...]") > > > The distinction between a customer service model and a service > delivery model needs to be repeatedly clarified. A customer service > > [O] repeatedly clarified. > [R] This seems like an odd thing to say. Maybe, "needs to be > emphasized" or "bears repeating" instead? > > > Section 4. Service Models in an SDN Context > > That is, there should be an independence between the > behavior and functions that a customer requests and the technology > that the network operator has available to deliver the service. The > [O] That is, there should be an independence between the behavior and > functions that a customer requests and the technology that the network > operator has available to deliver the service. > [P] That is, the behavior and functions that a customer requests > should be independent of the technology that the network operator has > available to deliver the service. > [R] readability. Not sure if P is much better. > > > Section 5. Possible Causes of Confusion > > SLAs are also linked to commercial terms > with penalties and so forth, and so are also not good topics for > [O] and so are also not good > [P] and thus SLAs are also not good > [R] grammar/clarity > > > Section 6.1. Comparison With Network Service Models > These are > service delivery models as described in this document, that is, they > > [O] document, that is, they > [P] document; that is, they > [R] grammar > > are the models used on the interface between the Service Orchestrator > or OSS/BSS and the Network Orchestrator as shown in Figure 3. > > Figure 1 of [RFC8199] can be modified to make this more clear and to > add an additional example of a Network Service YANG model as shown in > Figure 4. This figure illustrates a functional architecture and an > > [O] architecture and an > [P] architecture, and an > [R] grammar > > Section 6.2. Service Delivery and Network Element Model Work > > These models focus on how the network operator configures > the network through protocols and devices to deliver a service. Some > of these models are classified as service delivery models while > > [O] models while > [P] models, while > [R] grammar > > 6.4. The MEF Architecture > > This does not invalidate either approach, but only > > [O] approach, but > [P] approach; > [R] grammar (or "either approach, it only" ?) > > 7.2. Relationship to Policy > > As with commercial terms and SLAs discussed in Section 5 it is > > [O] Section 5 it is > [P] Section 5, it is > [R] grammar > > > 7.3. Operator-Specific Features > > They also understood > that should an individual network operator want to describe > additional features (operator-specific features) they could do so by > > [O] that should an individual network operator want to describe > additional features (operator-specific features) > > [P] that, should an individual network operator want to describe > additional features (operator-specific features), > [R] grammar > > > 7.4. Supporting Multiple Services > > [O] It is an implementation and deployment choice whether all service > > models are processed by a single Service Orchestrator that can > coordinate between the different services, or whether each service > model is handled by a specialized Service Orchestrator able to > provide tuned behavior for a specific service. > [P] Whether each service model is handled by a specialized Service > Orchestrator able to provide tuned behavior for a specific service or > whether all service models are handled by a single Service > Orchestrator is an implementation and deployment choice. > [R] readability > > > Section 8. Security Considerations > > Therefore it is important that the protocol interface used to > exchange service request information between customer and network > operator is subject to authorization, authentication, and encryption. > Equally, all external intefaces, such as any of those between the > > [O] intefaces > [P] interfaces > [R] spelling > > > > > W > > > > -- > 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 > > --------------958F9C1864F0F9B3DFCCE3BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Dear all,

Warren asked me to review this document part of the AD review.
I know we're in last call right now: Whether the comments are part of AD review or IETF LC comment doesn't matter at this point in time.
Here is my feedback.

Figure 3: Network configuration model is a brand new term that is only mentioned in the figure, and not explained.
In the same figure, could the "Device Configuration Model" be renamed to RFC 8199 "Network Element YANG module"
(this is what you did in figure 4 anyway)

- section 6.2 "service delivery and network element model work"

   Some
   of these models are classified as service delivery models, while
   others have details that are related to specific element
   configuration and so are classed as network element models (also
   called device models).

Next to each model description, that would help the audience to clarify what the correct term is: customer service model, service delivery model, network service YANG modules [RFC8199]

- In RFC 8199, we made a distinction between model and YANG modules. This is why we defined the terms "Network Service YANG modules" and "Network Element YANG modules" and not models.
You should follow this convention. After all, from the abstract, this document focuses on YANG.
Ex: should "model" be replaced by "YANG module"?

- section 6.4 "The MEF architecture".
Do we want to mention that MEF currently focuses on the customer service model?

- I'm glad you cleverly avoided the term "intend"
Regards, Benoit

Apologies, I forgot to CC the WG.

I'll also be asking Benoit to give it the once over, as he is much
more familiar with this topic.
W

---------- Forwarded message ----------
From: Warren Kumari <warren@kumari.net>
Date: Mon, Sep 4, 2017 at 8:43 PM
Subject: AD Review of draft-ietf-opsawg-service-model-explained
To: draft-ietf-opsawg-service-model-explained.all@ietf.org


Hi there,

First off, thanks for a really well written document -- this is one of
the cleanest AD reviews I've done.
I do have some very minor grammar nits.
I'd prefer a new version with these addressed, but they are all
sufficiently minor that I'm also OK starting the LC as is. Please let
me know which you'd prefer.




1: While unfortunate, I think many will not understand the q.v. in the
Service definition in Section 2. Terms and Concepts. Perhaps break it
out, or more clearly point where more info is to be found.

2: Section 6.3.  Customer Service Model Work
"The most advanced presents the L3VPN service..."  - I'd suggest
"Currently the most advanced presents the L3VPN service..." -- there
may be another, more advanced one soon...

The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason
/ Rational / <something else that starts with R> format.


Section Abstract
This document describes service models as used within the IETF, and
[O] IETF, and
[P] IETF and
[R] grammar


Section 1. Introduction.

 Within the context of Software Defined Networking (SDN) [RFC7149]
   [RFC7426] YANG data models may be used on the interface between a
[O] [RFC7426] YANG data models
[P] [RFC7426], YANG data models
[R] grammar

Ultimately they could be used in online, software-driven dynamic
   systems, and eventually as part of an SDN system.
[O] systems, and
[P] systems and
[R] grammar

 Equally, this document clarifies what a service model is
   not, and dispels some common misconceptions.
[O] not, and
[P] not and
[R] grammar - I think.



Section 2.  Terms and Concepts

   An example of where such details are relevant to the customer
         are when they describe the behavior or interactions on the
[O] are when
[P] is when
[R] subject/verb agreement ("An example [...] is [...]")


   The distinction between a customer service model and a service
   delivery model needs to be repeatedly clarified.  A customer service

[O] repeatedly clarified.
[R] This seems like an odd thing to say. Maybe, "needs to be
emphasized" or "bears repeating" instead?


Section 4.  Service Models in an SDN Context

 That is, there should be an independence between the
   behavior and functions that a customer requests and the technology
   that the network operator has available to deliver the service.  The
[O] That is, there should be an independence between the behavior and
functions that a customer requests and the technology that the network
operator has available to deliver the service.
[P] That is, the behavior and functions that a customer requests
should be independent of the technology that the network operator has
available to deliver the service.
[R] readability. Not sure if P is much better.


Section 5. Possible Causes of Confusion

 SLAs are also linked to commercial terms
      with penalties and so forth, and so are also not good topics for
[O] and so are also not good
[P] and thus SLAs are also not good
[R] grammar/clarity


Section 6.1. Comparison With Network Service Models
  These are
   service delivery models as described in this document, that is, they

[O] document, that is, they
[P] document; that is, they
[R] grammar

   are the models used on the interface between the Service Orchestrator
   or OSS/BSS and the Network Orchestrator as shown in Figure 3.

   Figure 1 of [RFC8199] can be modified to make this more clear and to
   add an additional example of a Network Service YANG model as shown in
   Figure 4.  This figure illustrates a functional architecture and an

[O] architecture and an
[P] architecture, and an
[R] grammar

Section 6.2. Service Delivery and Network Element Model Work

These models focus on how the network operator configures
   the network through protocols and devices to deliver a service.  Some
   of these models are classified as service delivery models while

[O] models while
[P] models, while
[R] grammar

6.4.  The MEF Architecture

This does not invalidate either approach, but only

[O] approach, but
[P] approach;
[R] grammar (or "either approach, it only" ?)

7.2.  Relationship to Policy

 As with commercial terms and SLAs discussed in Section 5 it is

[O] Section 5 it is
[P] Section 5, it is
[R] grammar


7.3.  Operator-Specific Features

They also understood
   that should an individual network operator want to describe
   additional features (operator-specific features) they could do so by

[O] that should an individual network operator want to describe
additional features (operator-specific features)

[P] that, should an individual network operator want to describe
additional features (operator-specific features),
[R] grammar


7.4.  Supporting Multiple Services

[O] It is an implementation and deployment choice whether all service

   models are processed by a single Service Orchestrator that can
   coordinate between the different services, or whether each service
   model is handled by a specialized Service Orchestrator able to
   provide tuned behavior for a specific service.
[P] Whether each service model is handled by a specialized Service
Orchestrator able to provide tuned behavior for a specific service or
whether all service models are handled by a single Service
Orchestrator is an implementation and deployment choice.
[R] readability


Section 8.  Security Considerations

Therefore it is important that the protocol interface used to
   exchange service request information between customer and network
   operator is subject to authorization, authentication, and encryption.
   Equally, all external intefaces, such as any of those between the

[O] intefaces
[P] interfaces
[R] spelling




W



--
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

--------------958F9C1864F0F9B3DFCCE3BF-- From nobody Thu Sep 14 07:39:12 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 6C34D13302B; Thu, 14 Sep 2017 07:39:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, opsawg@ietf.org, jclarke@cisco.com, opsawg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539995139.12557.4991731963252006621.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 07:39:11 -0700 Archived-At: Subject: [OPSAWG] opsawg - New Meeting Session Request for IETF 100 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 14:39:11 -0000 A new meeting session request has just been submitted by Joe Clarke, a Chair of the opsawg working group. --------------------------------------------------------- Working Group Name: Operations and Management Area Working Group Area Name: Operations and Management Area Session Requester: Joe Clarke Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: nvo3 ippm Second Priority: idr detnet People who must be present: Benoit Claise Warren Kumari Joe Clarke Tianran Zhou Ignas Bagdonas Resources Requested: Special Requests: PLEASE NOTE: Combined OpsAWG / OpsAREA --------------------------------------------------------- From nobody Fri Sep 15 03:27:54 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 7F8711330A3; Fri, 15 Sep 2017 03:27:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150547126847.2942.16551085667494192923@ietfa.amsl.com> Date: Fri, 15 Sep 2017 03:27:48 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 10:27:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-10.txt Pages : 53 Date : 2017-09-15 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-10 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 15 04:01:00 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 7C64C132C3F for ; Fri, 15 Sep 2017 04:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 z1AOqHBY9Jjd for ; Fri, 15 Sep 2017 04:00:53 -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 E355C132026 for ; Fri, 15 Sep 2017 04:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10808; q=dns/txt; s=iport; t=1505473253; x=1506682853; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=BsMjG7JST+tZOM9dUNs0yN8IZIVuR7M2zs6er9gYTBs=; b=TcN+UvOoVSEmQpWC+S+MjjgIq9a0IoSgS7H5R6JCWv6crNQPaPWPONrj Xe9PtvhHvZp1YJ4iT+wRPYKkzeFySr/K2NrFr+Df7r1PTSsvlqsBvBHAS uz9mbhaMroja8TFBGZeLTBRqiq/IQPDYbwE8Q9FY8bcnK3VMV/E662HZq o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQDvsbtZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD5uJ4N1iiB0kEqRE4U/ghIHAyOFGQKEahgBAgEBAQEBAQFrHQuFDwo?= =?us-ascii?q?DAyNUEg4BDjACAkkECgYNCAEBii8QqzWCJyeLCwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDw+DK4U1KwuCcoMohGOCYAWKFYcaj1WEOYIhgQGMeoITW4UPg1qHIYl/izO?= =?us-ascii?q?BOR84QUwyIQgcFR+HSD42AYkQAQEB?= X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="asc'?eml'208?scan'208,208,217";a="655662505" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 11:00:50 +0000 Received: from [10.61.216.42] ([10.61.216.42]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8FB0oi7015795 for ; Fri, 15 Sep 2017 11:00:50 GMT References: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" From: Eliot Lear X-Forwarded-Message-Id: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> Message-ID: <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> Date: Fri, 15 Sep 2017 13:00:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R6cK7CIUeuJKkqoLqXqv2D36qHhSdMcJU" Archived-At: Subject: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 11:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R6cK7CIUeuJKkqoLqXqv2D36qHhSdMcJU Content-Type: multipart/mixed; boundary="RSJUipOtr7LkK22jN8SAxF1scTFs8hHI7"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> Subject: Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt References: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> In-Reply-To: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> --RSJUipOtr7LkK22jN8SAxF1scTFs8hHI7 Content-Type: multipart/mixed; boundary="------------BDD1F88DB7E5D7D5EA306C56" Content-Language: en-US This is a multi-part message in MIME format. --------------BDD1F88DB7E5D7D5EA306C56 Content-Type: multipart/alternative; boundary="------------6021231308606618E29E2359" --------------6021231308606618E29E2359 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This update addresses both of Benoit's issues: * The dates on the YANG files are now consistent. * There is a statement of conformance as to which features are expected to be implemented. * One or two small editorials. Note that the draft DOES produce a yanglint warning which is expected.=C2= =A0 This is because yanglint does not know what to expect in terms of what features are implemented in the ACL model.=C2=A0 Thus the above statement= =2E Eliot --------------6021231308606618E29E2359 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

This update addresses both of Benoit's issues:
  • The dates on the YANG files are now consistent.
  • There is a statement of conformance as to which features are expected to be implemented.
  • One or two small editorials.

Note that the draft DOES produce a yanglint warning which is expected.=C2=A0 This is because yanglint does not know what to expe= ct in terms of what features are implemented in the ACL model.=C2=A0 T= hus the above statement.

Eliot

--------------6021231308606618E29E2359-- --------------BDD1F88DB7E5D7D5EA306C56 Content-Type: message/rfc822; name="New Version Notification for draft-ietf-opsawg-mud-10_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-ietf-opsawg-mud-10_txt.em"; filename*1="l" X-Mozilla-Keys: Received: from xch-rcd-004.cisco.com (173.37.102.14) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Mailbox Transport; Fri, 15 Sep 2017 05:27:50 -0500 Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 05:27:50 -0500 Received: from rcdn-iport-4.cisco.com (173.37.86.75) by mail.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Fri, 15 Sep 2017 05:27:50 -0500 Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 10:27:49 +0000 Received: from alln-inbound-b.cisco.com (alln-inbound-b.cisco.com [173.37.147.232]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8FARlIw030019 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK) for ; Fri, 15 Sep 2017 10:27:49 GMT Received-SPF: Pass (alln-inbound-b.cisco.com: domain of internet-drafts@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-b.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="internet-drafts@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-b.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-b.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-b.cisco.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=internet-drafts@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dmarc=pass (p=none dis=none) d=ietf.org X-from-outside-Cisco: 4.31.198.44 IronPort-PHdr: =?us-ascii?q?9a23=3A4DgdfRRbmekXc0Q72GG0hQr6Mtpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa69YxON2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRODYyg?= =?us-ascii?q?YIUBD/QPM/tAr4Tmu1sDrweyCRWwCO/zyDJFgGL9060g0+QmFAHLxA0gH9QSsH?= =?us-ascii?q?vKttX1MrkdUfyswKbV1zXMdf1W2Svm6IXTcxAuv+2MXbxqfcrW00kvGAXIhUie?= =?us-ascii?q?p4ziOjOazOUNs26D4uphS+2vl2Anpxt2oji1ycchjJTCiIENyl3c+ih12og4Kc?= =?us-ascii?q?CiREJmZdOpE4Fcui6VOoZwX8gsWXtnuDwgxb0DoZO7fDYFyJAgxxPHbvyIaYmI?= =?us-ascii?q?4hb5WOaQPzh4mHxldKi4hxao/kis0uz8Vs+q31ZWtidIncPAu34Q2xDJ98SKTv?= =?us-ascii?q?hw8l2u1DuAzwzT7/tLIUEwlarVMZ4hxbswm4ISsUTFAi/5hl/2jKmIeUU44+Sn?= =?us-ascii?q?9v7nba/opp+ALI95kQD+PboymsyxG+g4NRIOX2eD9eSmyLLj5VH5QKlNjvAulq?= =?us-ascii?q?nWrorVJd4Aq6GlAg9VyZos6xGlAzi619QYmCpPEFUQMj+Djo/1c3XDKeqyRaO7?= =?us-ascii?q?jl22uDxq3PvBeLbmB8OJZjL5mbP5ff5R8UlZ00B7mcpT/ZVREZkOJfvyXgn6s9?= =?us-ascii?q?mOSldzHwWyi9zgDdxm3YoYRCjHVqODN6bbqlSBzu0qKuiIIoQSvWCuBeIi4qvv?= =?us-ascii?q?i2M0g1kQYeylx5IZdGuQH/l6LQOee3W/0Z86DW4Ws19mH6TRg1qYXGsWPi7qUg?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0GeAACwqrtZhizGHwRdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgmaBLW4ng3WLFI8BgVKYUQoKGAu?= =?us-ascii?q?FGYQtVwEBAQEBAQEBAgECEAEBAQoJCwgoL4IzJAENRiwBAQEBAQEmAQEBAQEBI?= =?us-ascii?q?wI+NAIgVBEeCAImAgIDRAIUAReKLwICC6sygieLMgEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAR2BDoIdggKDaYJygyiBbYJ2gmAFihWHGoEPjkaHW4x6ghNbhQ+Ke5Uyg?= =?us-ascii?q?TmBZYEEJ4VTghNWAYkQAQEB?= X-IPAS-Result: =?us-ascii?q?A0GeAACwqrtZhizGHwRdGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgmaBLW4ng3WLFI8BgVKYUQoKGAuFGYQtVwEBAQEBA?= =?us-ascii?q?QEBAgECEAEBAQoJCwgoL4IzJAENRiwBAQEBAQEmAQEBAQEBIwI+NAIgVBEeCAI?= =?us-ascii?q?mAgIDRAIUAReKLwICC6sygieLMgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BDoIdg?= =?us-ascii?q?gKDaYJygyiBbYJ2gmAFihWHGoEPjkaHW4x6ghNbhQ+Ke5UygTmBZYEEJ4VTghN?= =?us-ascii?q?WAYkQAQEB?= X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="24752028" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-b.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 10:27:49 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0551330A9; Fri, 15 Sep 2017 03:27:48 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: To: Eliot Lear , Ralph Droms , Dan Romascanu Subject: New Version Notification for draft-ietf-opsawg-mud-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> Date: Fri, 15 Sep 2017 03:27:48 -0700 Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-ALN-004.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 4591c795-e255-46ce-c1e4-08d4fc246a95 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 A new version of I-D, draft-ietf-opsawg-mud-10.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-ietf-opsawg-mud Revision: 10 Title: Manufacturer Usage Description Specification Document date: 2017-09-15 Group: opsawg Pages: 53 URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-mud-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-10 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. 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 --------------BDD1F88DB7E5D7D5EA306C56-- --RSJUipOtr7LkK22jN8SAxF1scTFs8hHI7-- --R6cK7CIUeuJKkqoLqXqv2D36qHhSdMcJU 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 iQEcBAEBCAAGBQJZu7LqAAoJEIe2a0bZ0nozmxQIAJhQHVaUidCndReTC7FqYGQO h8kSjuYQrLTu2sH2l9ifnGHtIUJnCZrIHB4gngLnfQ/um6IDVJxLT0aAtLtEQLfL ykql+ItrnFDxGu1eED1lbnaDcgdQiT8DCdxmVfooFXPdWXpXBgJVquV/57BHeDG4 xu2tkLWcG5ibtvpH+e5GC/ZFugiDj3K+ctfaOrOV7oKWafgA3/PmUDCiQ4VjMJXV JnPdpyy31z0XGWuA8UBRfj8UqIe3aSmCESJ/tfbxAi9UaImQVaKqJOXmcBcNlEUB XAkCs2lEeKjkJhRaqCrxXM0FEOspM2sx9gYSzz2xd0ZndP1x7POvGGWUXYXrjXE= =M0zF -----END PGP SIGNATURE----- --R6cK7CIUeuJKkqoLqXqv2D36qHhSdMcJU-- From nobody Sat Sep 16 20:41:37 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 3BC90126B7E for ; Sat, 16 Sep 2017 20:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 uncEvRig-zl7 for ; Sat, 16 Sep 2017 20:41:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24BD1200F3 for ; Sat, 16 Sep 2017 20:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8950; q=dns/txt; s=iport; t=1505619691; x=1506829291; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vLN7tRzgsp99kzL6T52GQ3GWuvnMnFb0vrXCpHa14i0=; b=k+DBTI29U3JslZrIn+hxDxY5DrbZmGnuopUhMv0TVYA2Q2GSe63S1aOb UHm6SrJPkYqw2S64kj58YDSfOZThL3IODKtG6OS2/8uLS23bk3ddTwrV3 OCOvnEvh7WgWo7hILRryhyrvnILo01QeJ8X0fszjxLLSKwnJswy2/tCzt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAABC7r1Z/5xdJa1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZG4nB44Oj3OBdJYmghIKGAuESU8ChCw/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBDFcJCwwEAgEIFgEBLicLHQgCBAENBYozEK1+iyUBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYMrggKDM4MohE4DEYYJBZExj1cCizWJHoIThWqKe5U?= =?us-ascii?q?IAhEZAYE4AR84gQ13FUmHHHaIV4EygQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,406,1500940800"; d="scan'208";a="299351917" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Sep 2017 03:41:30 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8H3fU3l024667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Sep 2017 03:41:30 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 16 Sep 2017 22:41:29 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1263.000; Sat, 16 Sep 2017 22:41:29 -0500 From: "Douglas Gash (dcmgash)" To: "t.petch" , Alan DeKok , Eliot Lear CC: IETF OOPSAWG Thread-Topic: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII Thread-Index: AQHS0IzaXjAQTdEMlkK3vjl1WRHGuA== Date: Sun, 17 Sep 2017 03:41:29 +0000 Message-ID: References: <61D9FC7A-6F10-44E6-8400-578C4FEE1988@deployingradius.com> <006101d2cd9c$e8c0afe0$4001a8c0@gateway.2wire.net> <010d01d2ce79$477ceda0$4001a8c0@gateway.2wire.net> <632EB4D0-15C0-4BF7-9187-9AFCD7EDE306@ll.mit.edu> <6B9DFA23-41BD-4896-B80C-EC0EAB51D5FD@deployingradius.com> <017f01d2d08c$7096de20$4001a8c0@gateway.2wire.net> <61BFF2A7-680E-433F-8D7E-E0F0B95A2DC6@deployingradius.com> <5210a082-6c5d-c7fc-b55d-abe11689c090@cisco.com> <00cd01d2d271$9fce4ac0$4001a8c0@gateway.2wire.net> In-Reply-To: <00cd01d2d271$9fce4ac0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.136.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 03:41:34 -0000 Hi All, We=B9re preparing the next revision. Regarding attribute value encoding, we=B9re proposing to add the following, then to assign a type to each attribute. As always with T+, the issue is getting the right balance in adding some order without changing too much the draft spec. Proposed content is as below, please share any views: 7. Attribute-Value Pairs TACACS+ is intended to be an extensible protocol. The attributes used in Authorization and Accounting are not limited by this document. Some attributes are defined below for common use cases, clients MUST use these attributes when supporting the corresponding use cases. 7.1. Value Encoding All attribute values are encoded as printable US-ASCII strings. The following type representations SHOULD be followed Numeric All numeric values in an attribute-value string are provided as decimal printable US-ASCII numbers, unless otherwise stated. Boolean All boolean attributes are encoded with values "true" or "false". IP-Address It is recommended that hosts be specified as a IP address so as to avoid any ambiguities. ASCII numeric IPV4 address are specified as octets separated by dots ('.'), IPV6 address text representation defined in RFC 4291. Date Time Absolute date/times are specified in seconds since the epoch, 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is specified.=20 String Many values have no specific type representation and so are interpreted as plain strings. Empty Values Attributes may be submitted with no value, in which case they consist of the name and the mandatory or optional separator. For example, the attribute "cmd" which has no value is transmitted as a string of four characters "cmd=3D" 7.2. Authorization Attributes service (String) The primary service. Specifying a service attribute indicates that this is a request for authorization or accounting of that service. For example: "shell", "tty-server", "connection", "system" and "firewall". This attribute MUST always be included. protocol (String) the ptotocol field may be used to indicate a subset of a service. cmd-arg (String) an argument to a shell (exec) command. This indicates an argument for the shell command that is to be run. Multiple cmd-arg attributes may be specified, and they are order dependent. acl (Numeric) printable US-ASCII number representing a connection access list. Applicable only to session-based shell authorization. =8A etc On 21/05/2017 21:34, "t.petch" wrote: >----- Original Message ----- >Sent: Friday, May 19, 2017 7:06 PM > >Isn't this handled by RFC 20? > > >Eliot > >RFC20, AFACT, does not define Boolean, or Numeric or Printable (albeit >something which the current I-D does not currently use) while its >definition of 'text' (which the I-D does use) is based on starting with >STX so IMHO, no. > >RFC20 is just a list of 128 characters with a numeric code. Every other >protocol specification I can think of places restrictions thereon; DC3 >in a username, anyone? > >RFC4234 is to me a good example of an RFC that starts with RFC20 (or the >equivalent thereof) and produces something more usable. > >Tom Petch > >On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote: >> >> On 19/05/2017 18:11, "Alan DeKok" wrote: >> >>> On May 19, 2017, at 6:38 AM, t.petch wrote: >>>> Another fresh topic, so a slight change in the Subject: >>>> >>>> I think that the use of the term ASCII needs more thought. >>> Speaking only as an opinionated WG member... yes. >>> >>>> d) in some places, I think that the term ASCII is being used too >>>> loosely. ASCII is a character set and an encoding. If you simply >say >>>> US-ASCII, then you are including DC3 and FF, for example, which are >>>> unlikely to be valid. Some use US-ASCII to mean printable ASCII, >some >>>> to mean alphameric plus a few others such as hyphen-minus and >period. >>>> This needs defining. I don't know how many different character sets >you >>>> have - I was surprised that '&=A3#' (or some such) is a valid >identifier >>>> in places where an equal sign is not - so this needs more work. >>> I agree. >> Will align the ASCII references for sure, and tie down. I propose to >> restrict to printable. Though, to add to complexity: it is common >> practice, for example, to include newline in banners. >> >>>> e) this leads into data types, which Alan raised. Boolean is used >as a >>>> data type. (I have seen it as a character string of 'true'/'false' >of >>>> '0'/'1' with zero meaning either true or false or vice versa or as a >>>> binary integer of some number of bits or ....) As Alan implied, >section >>>> 7 and others are full of data types but on the one hand, what type >it is >>>> is usually omitted and on the other hand, the data types are not >>>> defined. >>> The main issue with data types is that TACACS+ is a protocol based >on >>> printable strings. So "data types" really means "printed versions of >>> data types", which is a lot more problematic than "32-bit integer". >> I agree. Will put a section in regarding at a types, specifically for >> attributes (As Alan pointed out). >> >>>> You need to define datatypes; from the current I-D, I do not know >how >>>> many there would be; probably not many. Look for example at TLS >>>> (RFC5246) or YANG (RFC6020) which nail down the datatypes, semantic >and >>>> encoding, before they define data structures. This is what I think >that >>>> you should do, on a smaller scale. Since YANG is being so widely >>>> deployed, you would get brownie points IMO for being in line with >YANG >>>> wherever possible >>> That's good, tho there are inconsistencies. e.g. Yang "string" >doesn't >>> exactly map to TACACS+ "US-ASCII thing". Yang "boolean" is >"true/false", >>> while TACACS+ has used "yes/no". >>> >>> We added data types to RADIUS, because it had (roughly) data types >from >>> day one, 32-bit integers, and all of the implementors had already >agreed >>> on meanings / encodings for them. So RFC8044 was just a codification >of >>> existing practices, and not any change to implementations. >>> >>> Then there's the additional issue of trying to define data types for >a >>> protocol that's entirely string based, and has 18 years of >implementation >>> practice. >>> >>> i.e. before defining data types, it would be good to know what >>> implementors have done, and then define types that match that. >>> >>> However, implementors are largely silent about all possible TACACS+ >>> issues. Which makes me think that the draft should name the data >types, >>> but be a bit vague about what they contain. >> Agreed, but try to be explicit about the vagueness. >> >> >>>> I see a need for boolean, character string/text, IPv4 address, IPv6 >>>> address, time interval, integer (positive ?negative). I would like >a >>>> section on datatypes at the front, section 1 or 2. >>> I'd agree, subject to the caveats raised above. i.e. "boolean is >>> boolean, typically yes/no, but maybe also true/false, we really don't >>> know..." >>> >>>> f) in a similar vein, you use what I take to be hexadecimal >>>> representation but are inconsistent with it. I see >>>> OX0D 0x0D 0x1 0x01 >>>> This should be consistent and is also worth defining, as a >>>> representation. >>> I agree, subject to the same caveats. It would also be nice to know >>> what implementations do... >>> >>>> g) and then there is i18n, which gets an implicit mention with UTF8 >but >>>> harks back to d). How much of UTF8 is allowed and where; it >encompasses >>>> over 65k characters these day:-( >> >> Well, the approach we had in mind is printable US-ASCII for all >fields, >> apart form username and passwords, which are the hard points in >> interfacing to identity provides which support. For these fields, to >allow >> UTF-8 on top of the byte streams. >> >> >>> IMHO, the draft should just mention 18n, and run away screaming. :( >>> >>> As in, "we know about it, we don't know how to fix it, we don't know >>> what implementations do, the fields are defined to be US-ASCII, if >they >>> contain anything else, that's bad." >>> >>>> This amounts to a lot of potential detailed change, but I would like >to >>>> see consensus on the approach first before edits are proposed or >made. >>> I think this is the right approach. >>> >>> Alan DeKok. >>> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > From nobody Sun Sep 17 05:26:39 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 4FD021331BA for ; Sun, 17 Sep 2017 05:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkMk6NH71Jsz for ; Sun, 17 Sep 2017 05:26:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6962913219C for ; Sun, 17 Sep 2017 05:26:35 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 151945EA; Sun, 17 Sep 2017 12:26:33 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Sun, 17 Sep 2017 08:26:33 -0400 Cc: "t.petch" , Eliot Lear , IETF OOPSAWG Content-Transfer-Encoding: quoted-printable Message-Id: <817F293D-33C9-4842-A394-70A46DE2B02C@deployingradius.com> References: <61D9FC7A-6F10-44E6-8400-578C4FEE1988@deployingradius.com> <006101d2cd9c$e8c0afe0$4001a8c0@gateway.2wire.net> <010d01d2ce79$477ceda0$4001a8c0@gateway.2wire.net> <632EB4D0-15C0-4BF7-9187-9AFCD7EDE306@ll.mit.edu> <6B9DFA23-41BD-4896-B80C-EC0EAB51D5FD@deployingradius.com> <017f01d2d08c$7096de20$4001a8c0@gateway.2wire.net> <61BFF2A7-680E-433F-8D7E-E0F0B95A2DC6@deployingradius.com> <5210a082-6c5d-c7fc-b55d-abe11689c090@cisco.com> <00cd01d2d271$9fce4ac0$4001a8c0@gateway.2wire.net> To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 12:26:37 -0000 On Sep 16, 2017, at 11:41 PM, Douglas Gash (dcmgash) = wrote: >=20 > We=B9re preparing the next revision. Regarding attribute value = encoding, > we=B9re proposing to add the following, then to assign a type to each > attribute. As always with T+, the issue is getting the right balance = in > adding some order without changing too much the draft spec. The right balance is to document the protocol. If documenting the spec means tossing the draft and starting from = scratch, then so be it. > Proposed content is as below, please share any views: It definitely seems better that the previous ad-hoc definitions. > Boolean >=20 > All boolean attributes are encoded with values "true" or "false". Nit: encoded as US-ASCII strings with values... Alan DeKok. From nobody Sun Sep 17 05:47:55 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 E679B132D44 for ; Sun, 17 Sep 2017 05:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wsqXOJVUyay0 for ; Sun, 17 Sep 2017 05:47:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F45132026 for ; Sun, 17 Sep 2017 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1726; q=dns/txt; s=iport; t=1505652469; x=1506862069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PWVghrJW1i6wOCnyrvwfEm6IJGuzelw/8UW5yT5++Yw=; b=AjC5xWhfyc1IuL6Koi5/RFTfHYSI/cuJH+u9A59F1D6mp9GqbG+zELLi bZFjyrf+yJDFjap0p7TK5pJJeAZZJhbFFhUn9F5g3UWWfzyNCJWPPSa3+ DFob6KUDPXw6JNUlGCW5dRqK6tjA9LmeaBPsiPOlUDraOwqmtKPqP4DyB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAABkbr5Z/5hdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHg26KII9ymBqCEgqFOwIahBI/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?GDiYxFBACAQgcKAICMCUCBA4FijOOGJ1eBoIpiyQBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQiCI4IChluFD4J2gmYFmECISAKLNYkeghOFaop7lQgCERkBgTgBHzi?= =?us-ascii?q?BDXcVhWIcgWd2iBqBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,407,1500940800"; d="scan'208";a="300073846" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Sep 2017 12:47:46 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8HCljIa026096 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Sep 2017 12:47:46 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 17 Sep 2017 07:47:45 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1263.000; Sun, 17 Sep 2017 07:47:45 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok CC: "t.petch" , Eliot Lear , IETF OOPSAWG Thread-Topic: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII Thread-Index: AQHS0IzaXjAQTdEMlkK3vjl1WRHGuKK6ExyAgAA4PIA= Date: Sun, 17 Sep 2017 12:47:45 +0000 Message-ID: References: <61D9FC7A-6F10-44E6-8400-578C4FEE1988@deployingradius.com> <006101d2cd9c$e8c0afe0$4001a8c0@gateway.2wire.net> <010d01d2ce79$477ceda0$4001a8c0@gateway.2wire.net> <632EB4D0-15C0-4BF7-9187-9AFCD7EDE306@ll.mit.edu> <6B9DFA23-41BD-4896-B80C-EC0EAB51D5FD@deployingradius.com> <017f01d2d08c$7096de20$4001a8c0@gateway.2wire.net> <61BFF2A7-680E-433F-8D7E-E0F0B95A2DC6@deployingradius.com> <5210a082-6c5d-c7fc-b55d-abe11689c090@cisco.com> <00cd01d2d271$9fce4ac0$4001a8c0@gateway.2wire.net> <817F293D-33C9-4842-A394-70A46DE2B02C@deployingradius.com> In-Reply-To: <817F293D-33C9-4842-A394-70A46DE2B02C@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.136.18] Content-Type: text/plain; charset="euc-kr" Content-ID: <0A1014277CA61D4B8615A3336740143F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 12:47:54 -0000 VGhhbmtzIEFsYW4sIHdpbGwgY29ycmVjdCB0aGUgbml0Lg0KDQpJIG5lZWQgdG8gY29ycmVjdCBi eSBwcmV2aW91cyBhbWJpZ3VpdHk6IEJ5OiAnd2l0aG91dCBjaGFuZ2luZyB0b28gbXVjaA0KdGhl IGRyYWZ0IHNwZWMnIEkgc2hvdWxkIGhhdmUgc2FpZDogJ3dpdGhvdXQgY2hhbmdpbmcgdG9vIG11 Y2ggdGhlDQpwcm90b2NvbCB0aGF0IHdhcyAiZGVmaW5lZCIgZHJhZnQgc3BlYy4gVGhlIG9yaWdp bmFsIGRyYWZ0IHNwZWMgdGV4dCBoYXMNCmFscmVhZHkgYmVlbiBsYXJnZWx5IHJld3JpdHRlbiBi eSB0aGUgcmVjZW50IHN1Ym1pc3Npb25zLg0KDQpUaGFua3MsDQoNClJlZ2FyZHMsDQoNCkRvdWcu DQoNCg0KT24gMTcvMDkvMjAxNyAxNToyNiwgIkFsYW4gRGVLb2siIDxhbGFuZEBkZXBsb3lpbmdy YWRpdXMuY29tPiB3cm90ZToNCg0KPk9uIFNlcCAxNiwgMjAxNywgYXQgMTE6NDEgUE0sIERvdWds YXMgR2FzaCAoZGNtZ2FzaCkgPGRjbWdhc2hAY2lzY28uY29tPg0KPndyb3RlOg0KPj4gDQo+PiBX Zan2cmUgcHJlcGFyaW5nIHRoZSBuZXh0IHJldmlzaW9uLiBSZWdhcmRpbmcgYXR0cmlidXRlIHZh bHVlIGVuY29kaW5nLA0KPj4gd2Wp9nJlIHByb3Bvc2luZyB0byBhZGQgdGhlIGZvbGxvd2luZywg dGhlbiB0byBhc3NpZ24gYSB0eXBlIHRvIGVhY2gNCj4+IGF0dHJpYnV0ZS4gQXMgYWx3YXlzIHdp dGggVCssIHRoZSBpc3N1ZSBpcyBnZXR0aW5nIHRoZSByaWdodCBiYWxhbmNlIGluDQo+PiBhZGRp bmcgc29tZSBvcmRlciB3aXRob3V0IGNoYW5naW5nIHRvbyBtdWNoIHRoZSBkcmFmdCBzcGVjLg0K Pg0KPiAgVGhlIHJpZ2h0IGJhbGFuY2UgaXMgdG8gZG9jdW1lbnQgdGhlIHByb3RvY29sLg0KPg0K PiAgSWYgZG9jdW1lbnRpbmcgdGhlIHNwZWMgbWVhbnMgdG9zc2luZyB0aGUgZHJhZnQgYW5kIHN0 YXJ0aW5nIGZyb20NCj5zY3JhdGNoLCB0aGVuIHNvIGJlIGl0Lg0KPg0KPj4gUHJvcG9zZWQgY29u dGVudCBpcyBhcyBiZWxvdywgcGxlYXNlIHNoYXJlIGFueSB2aWV3czoNCj4NCj4gIEl0IGRlZmlu aXRlbHkgc2VlbXMgYmV0dGVyIHRoYXQgdGhlIHByZXZpb3VzIGFkLWhvYyBkZWZpbml0aW9ucy4N Cj4NCj4+ICAgQm9vbGVhbg0KPj4gDQo+PiAgIEFsbCBib29sZWFuIGF0dHJpYnV0ZXMgYXJlIGVu Y29kZWQgd2l0aCB2YWx1ZXMgInRydWUiIG9yICJmYWxzZSIuDQo+DQo+ICBOaXQ6IGVuY29kZWQg YXMgVVMtQVNDSUkgc3RyaW5ncyB3aXRoIHZhbHVlcy4uLg0KPg0KPg0KPiAgQWxhbiBEZUtvay4N Cj4NCg0K From nobody Sun Sep 17 12:32:12 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 5B4D813331E; Sun, 17 Sep 2017 12:32:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-service-model-explained.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150567672431.672.1037086780979343658@ietfa.amsl.com> Date: Sun, 17 Sep 2017 12:32:04 -0700 Archived-At: Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-service-model-explained-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:32:04 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is ready for publication. I think the document could be improved slightly by touching on the fact that the service models themselves may involve security parameters. You could add a sentence to the security considerations section following the last sentence: "The service model should expose security related parameters where they are available to the customer." Cheers, Joe From nobody Sun Sep 17 19:26: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 17F1613247A; Sun, 17 Sep 2017 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 9mAar6Io_NVl; Sun, 17 Sep 2017 19:26:41 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0121.outbound.protection.outlook.com [104.47.33.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEE413234B; Sun, 17 Sep 2017 19:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fY9fu9wmD+9EVGLnXBy77whHmwUu1eKuGK69Q4FYwQ8=; b=Ubd+LwdYuwvln2FMmM/SwtXrzpi6EQjjEoKobokW1kSc2LoNTB3P7xxAEpITvBB2sWDvwQn0q8ooHl7BRkxUEZxPswebFtEaPNWsIshALpndIrZJiAPEdfZpv2EO0uOCoZucTwu3Z5iAzivhhWZLsgSG16YjTkYb+ssCqIz6GQs= Received: from CO2PR05MB971.namprd05.prod.outlook.com (10.141.226.17) by CO2PR05MB764.namprd05.prod.outlook.com (10.141.227.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 18 Sep 2017 02:26:38 +0000 Received: from CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) by CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) with mapi id 15.20.0077.008; Mon, 18 Sep 2017 02:26:38 +0000 From: Adrian Farrel To: Joseph Salowey , "secdir@ietf.org" CC: "opsawg@ietf.org" , "iesg@ietf.org" , "draft-ietf-opsawg-service-model-explained.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-service-model-explained-03 Thread-Index: AQHTL+umKROSgFAImUSAR1bBXyKHlqK56xUQ Date: Mon, 18 Sep 2017 02:26:38 +0000 Message-ID: References: <150567672431.672.1037086780979343658@ietfa.amsl.com> In-Reply-To: <150567672431.672.1037086780979343658@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=afarrel@juniper.net; x-originating-ip: [116.197.184.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR05MB764; 6:6KaWQA5B9Uy1B46Botl6XAPI11lWV/QOJTKj7ZRUFeKRSWIZacVNekrT/ADP24++3uRjzLJyP1i0Tv/CBGsBgQhWBLS8zQ64QtcYNerf/6XTT0UkgWJD9fKXjD7qjqU6gK9ayUa/IzVybTOqMpEInEGShz5whQ/+efQQrM7tTXiaMgsjrUbXUbqnSTDj0Ytu+iZY4a+wTOR9dWRTwGrhxjX0Oa0J0krsKw9H3eH6Kic0tWUPf65Ybh8o1R0AkIyX7ieo8vhyHqe3dVCvJ58jahHFZOknYEnO7Lii++JOVLv0d+z+GcKKpce+pLk7waxLdjEn1VMfaukR33QUPY53LA==; 5:2eL6uX9uv4ouOmfsdrY3zMVfDrgoAnOT25p8tH9zOoKYe46QOGJ+8rKi6d6le8Vb0Wj2C8UySAE+Kvh5AzeHbmIwjspjum/m/xTQU+QLVnK37BzykUv6e1wMO5pKsqlP+lJkLZRwqRgtcVI2YERM1w==; 24:EvNrTwstW7nxRCGp9MQr+AzGJUsKxzApG2Kd8Aakl2HJnKFGdUuN6om51yuyavnZiVTloLT7ybOKgrFvEwjiY6L+IsXB1e+NL1Dh3mzW8nQ=; 7:RXgOJXFCBX8o+EmMtrQBEAoN+LVaQEPd9IlbxZV/gnOIpLEq/K6j/yTfshY9GvR9yLQJjWq5qqpCdltjVbsy45/n7PRbsPvWPg//L5k4ltmjlC6nw7Oqp2ey18rlqMdxzfXERzj6lskpx9+Fu8lMqi10fIdldBBoGWthpW3zjVbttAeotPfHmNdLK356LYvxCEIUcmn3D/z3m/Dl6XDE5izIB0fRzhSTvoVxuaFjTVs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d38af553-e7ee-4bb0-5add-08d4fe3cb0be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB764; x-ms-traffictypediagnostic: CO2PR05MB764: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB764; x-forefront-prvs: 04347F8039 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(13464003)(189002)(199003)(99286003)(189998001)(25786009)(3280700002)(55016002)(54906002)(6116002)(3846002)(106356001)(102836003)(105586002)(9686003)(14454004)(8936002)(53936002)(97736004)(68736007)(86362001)(8676002)(3660700001)(81156014)(81166006)(478600001)(316002)(2906002)(229853002)(4326008)(33656002)(7696004)(305945005)(5660300001)(101416001)(6246003)(7736002)(66066001)(50986999)(76176999)(53546010)(54356999)(230783001)(77096006)(2950100002)(6436002)(6506006)(2501003)(74316002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB764; H:CO2PR05MB971.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2017 02:26:38.2059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB764 Archived-At: Subject: Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-service-model-explained-03 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, 18 Sep 2017 02:26:43 -0000 SGV5IEpvZSwNCg0KVGhhbmtzIGZvciB0aGF0LiBMb29rcyBsaWtlIGFuIGVhc3kgY2hhbmdlIGZv ciB1cyB0byBwaWNrIHVwIGFsb25nIHRoZSB3YXkuDQoNCkJlc3QsDQpBZHJpYW4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvc2VwaCBTYWxvd2V5IFttYWlsdG86am9lQHNh bG93ZXkubmV0XSANClNlbnQ6IDE3IFNlcHRlbWJlciAyMDE3IDIwOjMyDQpUbzogc2VjZGlyQGll dGYub3JnDQpDYzogb3BzYXdnQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRmLW9w c2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhw bGFpbmVkLTAzDQoNClJldmlld2VyOiBKb3NlcGggU2Fsb3dleQ0KUmV2aWV3IHJlc3VsdDogUmVh ZHkNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoZSBz dW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNh dGlvbi4NCg0KSSB0aGluayB0aGUgZG9jdW1lbnQgY291bGQgYmUgaW1wcm92ZWQgc2xpZ2h0bHkg YnkgdG91Y2hpbmcgb24gdGhlIGZhY3QgdGhhdCB0aGUgc2VydmljZSBtb2RlbHMgdGhlbXNlbHZl cyBtYXkgaW52b2x2ZSBzZWN1cml0eSBwYXJhbWV0ZXJzLiAgWW91IGNvdWxkIGFkZCBhIHNlbnRl bmNlIHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGZvbGxvd2luZyB0aGUg bGFzdCBzZW50ZW5jZToNCg0KIlRoZSBzZXJ2aWNlIG1vZGVsIHNob3VsZCBleHBvc2Ugc2VjdXJp dHkgcmVsYXRlZCBwYXJhbWV0ZXJzIHdoZXJlIHRoZXkgYXJlIGF2YWlsYWJsZSB0byB0aGUgY3Vz dG9tZXIuIg0KDQpDaGVlcnMsDQoNCkpvZQ0KDQo= From nobody Mon Sep 18 02:42: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 B2BA0132932 for ; Mon, 18 Sep 2017 02:42:21 -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, 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 I-6TE8EMPYnl for ; Mon, 18 Sep 2017 02:42: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 1EAB7129B7A for ; Mon, 18 Sep 2017 02:42:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVR30219; Mon, 18 Sep 2017 09:42:15 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 18 Sep 2017 10:42:14 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 18 Sep 2017 17:42:09 +0800 From: Duzongpeng To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt Thread-Index: AQHTKJ8OvbFHcfxE/Ua8Ob5dckxENqK6cAcw Date: Mon, 18 Sep 2017 09:42:10 +0000 Message-ID: References: <150487415301.17285.8385247668098511742@ietfa.amsl.com> In-Reply-To: <150487415301.17285.8385247668098511742@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.0A020203.59BF94F8.0075, 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: 3b0e55d6cc09f0b4faa741852daef97d Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 09:42:22 -0000 Hi, Everyone, We have submitted a new version for the "Alternate Tunnel Encapsulation fo= r Data Frames in CAPWAP". It has been changed to an Experimental draft, and we have added a new sect= ion to introduce the History of the document. 1.3. History of the document This document was started to accommodate Service Provider's need of a more flexible deployment mode with alternative tunnels [RFC7494]. Experiments and tests have been done for this alt-tunnel network infrastructure. However important, the deployment of relevant technology is yet to complete. This experimental document is intended to serve as a historical reference for any future work as to the operational and deployment requirements. Welcome for comments. If no objection, please trigger the last call. This draft has gone through a last call last year.=20 After that, we have changed it according to the comments collected. Best Regards Zongpeng Du -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Friday, September 08, 2017 8:36 PM To: i-d-announce@ietf.org Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gro= up WG of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in= CAPWAP Authors : Rong Zhang Rajesh S. Pazhyannur Sri Gundavelli Zhen Cao Hui Deng Zongpeng Du Filename : draft-ietf-opsawg-capwap-alt-tunnel-10.txt Pages : 26 Date : 2017-09-08 Abstract: Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-10 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-1= 0 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Sep 18 05:43:04 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 F36C3124F57; Mon, 18 Sep 2017 05:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150573857595.29085.1183832890030255439@ietfa.amsl.com> Date: Mon, 18 Sep 2017 05:42:55 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 12:42:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT) Authors : Mohamed Boucadair Senthil Sivakumar Christian Jacquenet Suresh Vinapamula Qin Wu Filename : draft-ietf-opsawg-nat-yang-03.txt Pages : 76 Date : 2017-09-18 Abstract: For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a data model for configuring and managing the NAT is essential. This document defines a YANG data model for the NAT function. NAT44, Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and IPv6 Network Prefix Translation (NPTv6) are covered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-03 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 18 05:48:24 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 B7731124F57; Mon, 18 Sep 2017 05:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 sIunOzXO1suB; Mon, 18 Sep 2017 05:48:21 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2996129A89; Mon, 18 Sep 2017 05:48:20 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4461FC0992; Mon, 18 Sep 2017 14:48:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 2426C6006D; Mon, 18 Sep 2017 14:48:19 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 14:48:18 +0200 From: To: "opsawg@ietf.org" CC: "draft-ietf-opsawg-nat-yang@ietf.org" Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-03.txt Thread-Index: AQHTMHuoNPavYvErT0CqqjaBRKRQ7qK6lrUA Date: Mon, 18 Sep 2017 12:48:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0448B5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150573857663.29085.17548912723618235915.idtracker@ietfa.amsl.com> In-Reply-To: <150573857663.29085.17548912723618235915.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] TR: New Version Notification for draft-ietf-opsawg-nat-yang-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 12:48:23 -0000 RGVhciBhbGwsIA0KDQpUaGlzIG5ldyB2ZXJzaW9uIGZpeGVzIGEgZmV3IHR5cG9zIGFuZCBhZGRy ZXNzZXMgYSByZXZpZXcgZnJvbSBUb3JlIEFuZGVyc29uIChFQU0gcGFydCkuIA0KDQpGV0lXLCBJ J20gcGFzdGluZyBoZXJlIHRoZSBpbml0aWFsIGNvbW1lbnRzIGZyb20gVG9yZSBhbmQgaG93IHRo ZXNlIGFyZSBhZGRyZXNzZWQgaW4gdGhlIG5ldyByZXZpc2lvbi4gDQoNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+IEhpIE1vaGFtZWQuIEknbSBub3QgZmFtaWxpYXIgd2l0 aCBZQU5HLCBzbyBJIGNhbid0IHRlbGwgeW91IGZvciBjZXJ0YWluDQo+IHRoYXQgaXQgaXMgb3Ig bm90LiBJdCBkb2VzIHNlZW0gb2theSBlbm91Z2ggdG8gbWUsIHRob3VnaC4gSnVzdCBhIGNvdXBs ZQ0KPiBvZiBvYnNlcnZhdGlvbnM6DQo+IA0KPiAxKSAiRUlNIiBpbiB0aGUgQWJzdHJhY3Qgc2hv dWxkIHJlYWQgIkVBTSIuDQoNCltNZWRdIEZpeGVkLiBUaGFua3MuDQoNCj4gDQo+IDIpIEluIEFw cGVuZGl4IEEuNSBJIHNlZSB0aGF0IHRoZSBtYXJrdXAgbGFuZ3VhZ2UgaW5jbHVkZXMgYW4gPGlu ZGV4Pg0KPiB0YWcuIEknZCBqdXN0IGxpa2UgdG8gcG9pbnQgb3V0IHRoZSBmb2xsb3dpbmcgcGFy YWdyYXBoIGZyb20gUkZDIDc3NTc6DQo+IHNlY3Rpb24gMy4xOg0KPiANCj4gICAgVGhyb3VnaG91 dCB0aGlzIGRvY3VtZW50LCBmaWd1cmVzIHJlcHJlc2VudGluZyB0aGUgRUFNVCBjb250YWluIGFu DQo+ICAgIEluZGV4IGNvbHVtbiB1c2luZyB0aGUgcG91bmQgc2lnbiBhcyB0aGUgaGVhZGVyLiAg VGhpcyBjb2x1bW4gaXMgbm90DQo+ICAgIGEgcmVxdWlyZWQgcGFydCBvZiB0aGlzIHNwZWNpZmlj YXRpb247IGl0IGlzIGluY2x1ZGVkIG9ubHkgYXMgYQ0KPiAgICBjb252ZW5pZW5jZSB0byB0aGUg cmVhZGVyLg0KPiANCg0KW01lZF0gVGhhbmsgeW91IGZvciBwb2ludGluZyB0aGlzLiBUaGUgaW5k ZXggaXMgaW1wb3J0ZWQgZnJvbSB0aGUgTkFUNjQgc3RydWN0dXJlOyBzZWUgYmVsb3cuDQoNCj4g MykgVGhlIG1hcmt1cCBsYW5ndWFnZSBkZXNjcmliZXMgImV4dGVybmFsLWRzdC1hZGRyZXNzIiB2 cw0KPiAiaW50ZXJuYWwtZHN0LWFkZHJlc3MiLiBOb3RlIHRoYXQgU0lJVCAoYm90aCB3aXRoIGFu ZCB3aXRob3V0IEVBTSkgaXMNCj4gY29tcGxldGVseSBiaWRpcmVjdGlvbmFsLCBzbyB0aGVyZSdz IG5vIGZpeGVkIGNvbmNlcHQgb2YgImludGVybmFsIiBhbmQNCj4gImV4dGVybmFsIi4gVGhhdCBk ZXBlbmRzIGVudGlyZWx5IG9uIGhvdyBhbiBvcGVyYXRvciBkZXBsb3lzIGl0IGluIGENCj4gbmV0 d29yay4NCg0KW01lZF0gU3RhdGljIGVudHJpZXMgYXJlIGJpZGlyZWN0aW9uYWwsIHRvby4gQWN0 dWFsbHksIHRoZSB1c2Ugb2YgImludGVybmFsLSoiIGFuZCAiZXh0ZXJuYWwtKiIgaXMgYSBzaWRl IGVmZmVjdCBvZiB0cnlpbmcgdG8gdXNlIHRoZSBzYW1lIHN0cnVjdHVyZSBmb3IgYm90aCBOQVQ2 NCBhbmQgRUFNLiBJIHVuZGVyc3RhbmQgdGhpcyBtYXkgYmUgY29uZnVzaW5nLiANCg0KSXQgaXMg bW9yZSBjbGVhbmVyIHRvIGRlZmluZSBhIGRlZGljYXRlZCBvYmplY3QgZm9yIEVBTSB0aGF0IHdp bGwgbG9vayBsaWtlOiANCg0KICAgICAgICAgICAgICstLXJ3IGVhbXQqIFtpcHY0LXByZWZpeF0N CiAgICAgICAgICAgICB8ICArLS1ydyBlYW0taXB2NC1wcmVmaXggICBpbmV0OmlwdjYtcHJlZml4 DQogICAgICAgICAgICAgfCAgKy0tcncgZWFtLWlwdjYtcHJlZml4ICAgaW5ldDppcHY2LXByZWZp eCAgDQoNCldpbGwgdXBkYXRlIHRoZSBtb2R1bGUgYWNjb3JkaW5nbHkuDQo9PT09PT09PT09DQoN CkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd DQo+IEVudm95w6nCoDogbHVuZGkgMTggc2VwdGVtYnJlIDIwMTcgMTQ6NDMNCj4gw4DCoDogQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgU2VudGhpbCBTaXZha3VtYXI7IEpBQ1FVRU5FVCBDaHJp c3RpYW4NCj4gSU1UL09MTjsgb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzsgUWluIFd1DQo+IE9iamV0 wqA6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlh bmctMDMudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtb3Bz YXdnLW5hdC15YW5nLTAzLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IE1vaGFtZWQgQm91Y2FkYWlyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZw0KPiBSZXZpc2lvbjoJMDMN Cj4gVGl0bGU6CQlBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0 aW9uIChOQVQpDQo+IGFuZCBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBUKQ0KPiBEb2N1 bWVudCBkYXRlOgkyMDE3LTA5LTE4DQo+IEdyb3VwOgkJb3BzYXdnDQo+IFBhZ2VzOgkJNzYNCj4g VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW9wc2F3Zy0NCj4gbmF0LXlhbmctMDMudHh0DQo+IFN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQtDQo+IHlh bmcvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vcHNhd2ctbmF0LXlhbmctMDMNCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC15YW5nLTAz DQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1vcHNhd2ctbmF0LQ0KPiB5YW5nLTAzDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgRm9y IHRoZSBzYWtlIG9mIG5ldHdvcmsgYXV0b21hdGlvbiBhbmQgdGhlIG5lZWQgZm9yIHByb2dyYW1t aW5nDQo+ICAgIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFUKSBmdW5jdGlvbiBpbiBw YXJ0aWN1bGFyLCBhIGRhdGENCj4gICAgbW9kZWwgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2lu ZyB0aGUgTkFUIGlzIGVzc2VudGlhbC4gIFRoaXMNCj4gICAgZG9jdW1lbnQgZGVmaW5lcyBhIFlB TkcgZGF0YSBtb2RlbCBmb3IgdGhlIE5BVCBmdW5jdGlvbi4NCj4gDQo+ICAgIE5BVDQ0LCBOZXR3 b3JrIEFkZHJlc3MgYW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGllbnRzIHRv DQo+ICAgIElQdjQgU2VydmVycyAoTkFUNjQpLCBDdXN0b21lci1zaWRlIHRyYW5zTEFUb3IgKENM QVQpLCBFeHBsaWNpdA0KPiAgICBBZGRyZXNzIE1hcHBpbmdzIGZvciBTdGF0ZWxlc3MgSVAvSUNN UCBUcmFuc2xhdGlvbiAoU0lJVCBFQU0pLCBhbmQNCj4gICAgSVB2NiBOZXR3b3JrIFByZWZpeCBU cmFuc2xhdGlvbiAoTlBUdjYpIGFyZSBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAN Cj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Sep 18 09:00:15 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 2088A1321A2 for ; Mon, 18 Sep 2017 09:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 LVCLE_xcSWQ1 for ; Mon, 18 Sep 2017 09:00:08 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB301342CD for ; Mon, 18 Sep 2017 09:00:07 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id c23so893295wrg.9 for ; Mon, 18 Sep 2017 09:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RqfTI7N6hZfk345uxBOkrRQJiH1TrjIQTau50g0EsRA=; b=XUgf1KJ4hjORQFddCX4iWLiwmOiXXk+jW+lEqhtHoCt4GTEtH2iVjXNZgQjBffTYiY okVwVwpHteccZOqsVCoDSoPAv4V5G2qMJQ63ShX3PhSiew86T8UY1zC8WTQJPWLpavce CcbwKii8g1JCOf0kZ72kJYzk6m+m6J4J5xq4l/kcAMjz6f7t29XWIatBmhhpim+pf//O HjhaOMdEJalipTTNLTVXhbm4L6sY/uV0esMA9+PbE3fq1EIeGZqQzmV+1Dc3fK7qdsQ8 lXEQKz9uV1e5fGI3xAgiPKCXl36XQCaSanO1tmSjiq5Ve1ixLVwkS8Poo8rGitfDJ9zN cYcA== 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=RqfTI7N6hZfk345uxBOkrRQJiH1TrjIQTau50g0EsRA=; b=lpM2ufW1CjoIP1wbbBxoBoVyXh2SivvFAL1SPhBO85dPd66GVmTL6Kse9i59isPwJ/ 2vnq4+9gPqBfb3diuIjLMvuaEZTslMp3vWkXd/bT7qEBcJfTw2JwrWZZeC7O4G2MelAj TszCIzJDaXnnd2QB7wN37+HLDq2j51eg/V5v8HDhvB2CqD9co4IVECeWtnLdxn5rNWD4 MjGyQC6JfxaEPlvBfY8hG5Xj9mCTiUrdLG5wIEjB6fRJ2zR+rh3LO6QcI8H6PLgqXqAQ 4XEes51LSfhfflsLC+Nh+PxLt//H2n8ajqh8qmltRh3DmuXBeep/FbVF3SNAW1FObNzI +QUw== X-Gm-Message-State: AHPjjUj8Ed6iidao8g03LyEwlfHcry5Wa3yF8QmVabWGypHhBEKUvd2W lbDe1Yy82k3emsiuLwFJktF4W2iUpCQDIlkzoqw= X-Google-Smtp-Source: ADKCNb5lfxLGzftCjNUl9tD2iB/TzhpoJcKBIN6u/JPbhUqBnfdM83/9aS4MpvrWcVyEg1RZOTxHs/x+1oYu1TMDlO0= X-Received: by 10.223.198.202 with SMTP id c10mr28192864wrh.230.1505750406122; Mon, 18 Sep 2017 09:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.176.149 with HTTP; Mon, 18 Sep 2017 08:59:25 -0700 (PDT) In-Reply-To: <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> References: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> From: "M. Ranganathan" Date: Mon, 18 Sep 2017 11:59:25 -0400 Message-ID: To: Eliot Lear Cc: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary="089e0829e11c13d329055978d634" Archived-At: Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:00:13 -0000 --089e0829e11c13d329055978d634 Content-Type: text/plain; charset="UTF-8" I tried compiling the YANG model. I had to make the following corrections: /* augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" */ augment "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ace/acl:matches" /*augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches/acl:tcp-acl" */ augment "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ace/acl:matches/acl:tcp-acl" I am basing this on ietf-access-control-list@2017-06-16.yang, which I believe to be the latest draft of the ietf-access-control-list Perhaps I am mistaken (in which case please correct me). Thanks, Ranga On Fri, Sep 15, 2017 at 7:00 AM, Eliot Lear wrote: > Hi, > > This update addresses both of Benoit's issues: > > - The dates on the YANG files are now consistent. > - There is a statement of conformance as to which features are > expected to be implemented. > - One or two small editorials. > > Note that the draft DOES produce a yanglint warning which is expected. > This is because yanglint does not know what to expect in terms of what > features are implemented in the ACL model. Thus the above statement. > > Eliot > > > ---------- Forwarded message ---------- > From: > To: Eliot Lear , Ralph Droms , Dan > Romascanu > Cc: > Bcc: > Date: Fri, 15 Sep 2017 03:27:48 -0700 > Subject: New Version Notification for draft-ietf-opsawg-mud-10.txt > > A new version of I-D, draft-ietf-opsawg-mud-10.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name: draft-ietf-opsawg-mud > Revision: 10 > Title: Manufacturer Usage Description Specification > Document date: 2017-09-15 > Group: opsawg > Pages: 53 > URL: https://www.ietf.org/internet- > drafts/draft-ietf-opsawg-mud-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-mud-10 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg- > mud-10 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-10 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an > LLDP TLV, a URL suffix specification, an X.509 certificate extension > and a means to sign and verify the descriptions. > > > > > 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 > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > -- M. Ranganathan --089e0829e11c13d329055978d634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tried compiling the YANG model.= I had to make the following corrections:


=C2=A0 /* augmen= t "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" */
= =C2=A0=C2=A0=C2=A0=C2=A0 augment "/acl:access-lists/acl:acl/acl:access= -list-entries/acl:ace/acl:matches"


=C2=A0/*augment "/= acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches/acl:tcp-acl" */<= br>=C2=A0=C2=A0=C2=A0=C2=A0 augment "/acl:access-lists/acl:acl/acl:acc= ess-list-entries/acl:ace/acl:matches/acl:tcp-acl"

I am b= asing this on ietf-access-control-list@2017-06-16.yang, which I believe to = be the latest draft of the ietf-access-control-list

Perhaps I = am mistaken (in which case please correct me).

Thanks,

=
Ranga



On Fri, = Sep 15, 2017 at 7:00 AM, Eliot Lear <lear@cisco.com> wrote:
=
=20 =20 =20
Hi,

This update addresses both of Benoit's issues:
  • The dates on the YANG files are now consistent.
  • There is a statement of conformance as to which features are expected to be implemented.
  • One or two small editorials.

Note that the draft DOES produce a yanglint warning which is expected.=C2=A0 This is because yanglint does not know what to expect in terms of what features are implemented in the ACL model.=C2=A0 Thu= s the above statement.

Eliot



---------- Forwarded message ----------
From:=C2=A0<internet-drafts@ietf.org>
To= :=C2=A0Eliot Lear <lear@cisco.com&= gt;, Ralph Droms <rdroms@gmail.com>, Dan Romascanu <dromasca@gm= ail.com>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Fri, 15 Sep 2017 0= 3:27:48 -0700
Subject:=C2=A0New Version Notification for draft-ietf-opsa= wg-mud-10.txt

A new version of I-D, draft-ietf-opsawg-mud-10.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-opsawg-mud
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Manufacturer Usage Description Spe= cification
Document date:=C2=A0 2017-09-15
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opsawg
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud= -10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-ietf-opsawg-mud-10
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-10<= br> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-10=

Abstract:
=C2=A0 =C2=A0This memo specifies a component-based architecture for manufac= turer
=C2=A0 =C2=A0usage descriptions (MUD).=C2=A0 The goal of MUD is to provide = a means for
=C2=A0 =C2=A0Things to signal to the network what sort of access and networ= k
=C2=A0 =C2=A0functionality they require to properly function.=C2=A0 The ini= tial focus
=C2=A0 =C2=A0is on access control.=C2=A0 Later work can delve into other as= pects.

=C2=A0 =C2=A0This memo specifies two YANG modules, IPv4 and IPv6 DHCP optio= ns, an
=C2=A0 =C2=A0LLDP TLV, a URL suffix specification, an X.509 certificate ext= ension
=C2=A0 =C2=A0and a means to sign and verify the descriptions.




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

The IETF Secretariat



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



--
M. Ranganathan
--089e0829e11c13d329055978d634-- From nobody Mon Sep 18 09:58: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 B0B7B1331E4 for ; Mon, 18 Sep 2017 09:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 v7_URrrQ7ppk for ; Mon, 18 Sep 2017 09:58:14 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A27B1342B6 for ; Mon, 18 Sep 2017 09:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15843; q=dns/txt; s=iport; t=1505753888; x=1506963488; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=77mSfrE9KFGprHQK8TB7Sc7aL81IK8k94fJSCWK5p1Y=; b=QIbE4ytQ7z5sz1as0RsEg53Zcz5WTIyjfaxEYsxqzjWh5tUCL0bpnPuE xwaKl2EaftMFpiUKe+2VJ2GmUTH+sHhicaN0KMf9tqQ7DA5Yohb/WzYnn RSAdgcEnbGcBn9FZwxs55SFt6EQf0+QzzvwthNEVXQjeZ77FVOyctQUkP g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAADM+b9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1iiB0kEsriDuFD4MdhT+CEgcDGAEKhElPAoUGGAECAQE?= =?us-ascii?q?BAQEBAWsohRgBAQEBAwEBIUsJAhAJAhEBAgECAScDAgIhBh8DBggGDQYCAQGKF?= =?us-ascii?q?wMVEIwznWaCJyeDL4NhDYNqAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+DK4U1K4J?= =?us-ascii?q?9glhQgXCCc4JgBYoMC4cajxs8hDmCIYEBiAOEd4ITW4UPg1qHIYoAglqIW4E5H?= =?us-ascii?q?zhBTDIhCBwVHyqEYII+PjYBiB4BAQE?= X-IronPort-AV: E=Sophos;i="5.42,413,1500940800"; d="asc'?scan'208,217";a="697280746" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 16:58:06 +0000 Received: from [10.61.83.137] (ams3-vpn-dhcp5002.cisco.com [10.61.83.137]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8IGw5j3001605; Mon, 18 Sep 2017 16:58:05 GMT To: "M. Ranganathan" Cc: "opsawg@ietf.org" References: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> From: Eliot Lear Message-ID: <60de5e33-f1a0-87ae-0b20-5aabc151b1f6@cisco.com> Date: Mon, 18 Sep 2017 18:58:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tmEQE1eaNTgbT2dXup0DmnHDFCWMLsAN4" Archived-At: Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:58:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tmEQE1eaNTgbT2dXup0DmnHDFCWMLsAN4 Content-Type: multipart/mixed; boundary="6pNE3G2OiPapa1lB4SoOaERipw8AEfkBL"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" Cc: "opsawg@ietf.org" Message-ID: <60de5e33-f1a0-87ae-0b20-5aabc151b1f6@cisco.com> Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt References: <150547126863.2942.10258719507980708101.idtracker@ietfa.amsl.com> <5be5544b-3826-1687-1e0b-94bac09be826@cisco.com> In-Reply-To: --6pNE3G2OiPapa1lB4SoOaERipw8AEfkBL Content-Type: multipart/alternative; boundary="------------D70BA9B81385C34416D8AB19" Content-Language: en-US This is a multi-part message in MIME format. --------------D70BA9B81385C34416D8AB19 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rang, The ACL model is currently dated ietf-access-control-list@2017-09-12.yang= =2E Eliot On 9/18/17 5:59 PM, M. Ranganathan wrote: > I tried compiling the YANG model. I had to make the following correctio= ns: > > > =C2=A0 /* augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:match= es" */ > =C2=A0=C2=A0=C2=A0=C2=A0 augment > "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ace/acl:matches"= > > > =C2=A0/*augment > "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches/acl:tcp-acl" */= > =C2=A0=C2=A0=C2=A0=C2=A0 augment > "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ace/acl:matches/= acl:tcp-acl" > > > I am basing this on ietf-access-control-list@2017-06-16.yang, which I > believe to be the latest draft of the ietf-access-control-list > > Perhaps I am mistaken (in which case please correct me). > > Thanks, > > Ranga > > > > On Fri, Sep 15, 2017 at 7:00 AM, Eliot Lear > wrote: > > Hi, > > This update addresses both of Benoit's issues: > > * The dates on the YANG files are now consistent. > * There is a statement of conformance as to which features are > expected to be implemented. > * One or two small editorials. > > Note that the draft DOES produce a yanglint warning which is > expected.=C2=A0 This is because yanglint does not know what to expe= ct > in terms of what features are implemented in the ACL model.=C2=A0 T= hus > the above statement. > > Eliot > > > > ---------- Forwarded message ---------- > From:=C2=A0> > To:=C2=A0Eliot Lear >, Ralph= > Droms >, Dan Romascanu > > > Cc:=C2=A0 > Bcc:=C2=A0 > Date:=C2=A0Fri, 15 Sep 2017 03:27:48 -0700 > Subject:=C2=A0New Version Notification for draft-ietf-opsawg-mud-10= =2Etxt > > A new version of I-D, draft-ietf-opsawg-mud-10.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-opsawg-mud= > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010 > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Manufacturer Usage Descrip= tion Specification > Document date:=C2=A0 2017-09-15 > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opsawg > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53 > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud-10.txt > = > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > Htmlized:=C2=A0 =C2=A0 =C2=A0 > =C2=A0https://tools.ietf.org/html/draft-ietf-opsawg-mud-10 > > Htmlized:=C2=A0 =C2=A0 =C2=A0 > =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-1= 0 > > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-10 > > > Abstract: > =C2=A0 =C2=A0This memo specifies a component-based architecture for= manufacturer > =C2=A0 =C2=A0usage descriptions (MUD).=C2=A0 The goal of MUD is to = provide a > means for > =C2=A0 =C2=A0Things to signal to the network what sort of access an= d network > =C2=A0 =C2=A0functionality they require to properly function.=C2=A0= The initial focus > =C2=A0 =C2=A0is on access control.=C2=A0 Later work can delve into = other aspects. > > =C2=A0 =C2=A0This memo specifies two YANG modules, IPv4 and IPv6 DH= CP > options, an > =C2=A0 =C2=A0LLDP TLV, a URL suffix specification, an X.509 certifi= cate > extension > =C2=A0 =C2=A0and a means to sign and verify the descriptions. > > > > > 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 > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > --=20 > M. Ranganathan --------------D70BA9B81385C34416D8AB19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Rang,

The ACL model is currently dated ietf-access-control-list@2017-09-12.yang.=

Eliot


On 9/18/17 5:59 PM, M. Ranganathan wrote:
I tried compiling the YANG model. I had to make the following corrections:


=C2=A0 /* augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" */
=C2=A0=C2=A0=C2=A0=C2=A0 augment "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ac= e/acl:matches"


=C2=A0/*augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches/a= cl:tcp-acl" */
=C2=A0=C2=A0=C2=A0=C2=A0 augment "/acl:access-lists/acl:acl/acl:access-list-entries/acl:ace/acl:matches/ac= l:tcp-acl"

I am basing this on ietf-access-control-list@2017-06-16.y= ang, which I believe to be the latest draft of the ietf-access-control-list

Perhaps I am mistaken (in which case please correct me).

Thanks,

Ranga



On Fri, Sep 15, 2017 at 7:00 AM, Eliot= Lear <lear@cisco.com> wrote:
Hi,

This update addresses both of Benoit's issues:
  • The dates on the YANG files are now consistent.
  • There is a statement of conformance as to which features are expected to be implemented.
  • One or two small editorials.

Note that the draft DOES produce a yanglint warning which is expected.=C2=A0 This is because yanglint does no= t know what to expect in terms of what features are implemented in the ACL model.=C2=A0 Thus the above statem= ent.

Eliot



---------- Forwarded message ----------
From:=C2=A0<internet-drafts@ietf.org> To:=C2=A0Eliot Lear <lear@cisco.com>, Ralph Drom= s <rdroms@gmail.com>, Dan Romascanu <dromasca@gmail.com>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Fri, 15 Sep 2017 03:27:48 -0700
Subject:=C2=A0New Version Notification for draft-ietf-opsawg-mud-10.txt

A new version of I-D, draft-ietf-opsawg-mud-10.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-opsa= wg-mud
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Manufacturer Usage D= escription Specification
Document date:=C2=A0 2017-09-15
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opsawg
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud-1= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-opsawg-mud-10
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-= 10
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-10<= br>
Abstract:
=C2=A0 =C2=A0This memo specifies a component-based architectu= re for manufacturer
=C2=A0 =C2=A0usage descriptions (MUD).=C2=A0 The goal of MUD = is to provide a means for
=C2=A0 =C2=A0Things to signal to the network what sort of acc= ess and network
=C2=A0 =C2=A0functionality they require to properly function.= =C2=A0 The initial focus
=C2=A0 =C2=A0is on access control.=C2=A0 Later work can delve= into other aspects.

=C2=A0 =C2=A0This memo specifies two YANG modules, IPv4 and I= Pv6 DHCP options, an
=C2=A0 =C2=A0LLDP TLV, a URL suffix specification, an X.509 certificate extension
=C2=A0 =C2=A0and a means to sign and verify the descriptions.=




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



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




--
M. Ranganathan

--------------D70BA9B81385C34416D8AB19-- --6pNE3G2OiPapa1lB4SoOaERipw8AEfkBL-- --tmEQE1eaNTgbT2dXup0DmnHDFCWMLsAN4 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 iQEcBAEBCAAGBQJZv/sdAAoJEIe2a0bZ0nozdz0H/22ncSI+Xb6MitYJ9jEfbMco Iuz3QrdZ/ScHnBzGdFZjPwRJcXjUSokTY+GhOYu+f0KC7tHhNGCPuFoyuHMZxlJI d2ShfV3hSbntOdXi3v7srZgrRYQqrCViAkXdvrxLhzCcw0VnnQhu1pnjMjhQrk9s 8z+NQyoPwZ6yeKaehNSgRlZk/KrPwj+NeNJvNq822GHDIKNHZ8doSv5ZsvQ94EGZ 8zTnZlB7fIDqKPAGyJUGUzjPRwSvtte+BjvelEBtUXJkV7UHfgqUpMv/QiO7tdTF gmiOSVtREfNHDz+ux9h185YZF+Mz9V6Fu6Z+F/mS5Gsoi6b7o8XZdBoMx4w9Hc4= =Lt80 -----END PGP SIGNATURE----- --tmEQE1eaNTgbT2dXup0DmnHDFCWMLsAN4-- From nobody Tue Sep 19 08:06:22 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 24E51134298 for ; Tue, 19 Sep 2017 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 yFQqhVSj8837 for ; Tue, 19 Sep 2017 08:06:14 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DEE1342BC for ; Tue, 19 Sep 2017 08:06:11 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id a43so277437wrc.0 for ; Tue, 19 Sep 2017 08:06:11 -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=CHQEahZby4S9VGlomzdvbDoISy3DK3oseVbV55uurl4=; b=eEKJiS+USvCDN3PTJDhyzVLNzlalcTcTDM/HN3t3FvT4ers9PqRBxxNHI1wsAyCBY/ KXVuzhJEdblK3wDJ3moif3xfzBKbW+XCiBBlvWtilL7z45a0sNY7RMBUe96HslMY7NcX NbtOEtNWmBl71NGBtEbNZljJOapoJrsOdX9u97e/sSX09d5aAybE7GLlFPn5q3Itezy+ 2xacB+gf6a1mBaJXTizlUh4Q6nlR7i1sPgWULYyU/KClQGm9lRDUjTAlLrU1C7zZ8CYV 07NKamAgKQi7iIb4oBVfHRAgs1SSkg1Zc/MjhNZN4G6mg7t0EzHgMkjDYBl+Chr8fB61 cmKQ== 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=CHQEahZby4S9VGlomzdvbDoISy3DK3oseVbV55uurl4=; b=qZJL3D9Y9rbsprm/aIiiSbYBJH0uZNyvB6fcC1HZYe0asQlmBn2hvZD0HCgFFIXj4q ffQHm3Ubg/ffvOUxomM88n5PykUGtslMC8o82sofw2S6b1cQFqMwEN3Ga2o0742YQyKo zrGNyJvC260GUzQFQXA3NoMX69zOrNPxaR1mNT9FJag4MXwZA5oDOLPDc6Z7toKedTZ0 fYxON/PwJhV8aJNdIEXnrLnB0FAWw2ZnBqXNOpUAocNM9qemsYlyyOaH/pZoJF3jW7lU YZUtWNs5adRyouJoftNF1CUodPav1paoTqldWHhlAp7Vk6B9gzZVksueQcHOqJILH6A2 VQMA== X-Gm-Message-State: AHPjjUjSZwR26oEq7JproDsMSWjBHZKTeXUSp8a6Om/15Lj6d62K2HrA ClU14tp7Lf4jZL9I2Vvvmj2w7bv7Mz/eV0qdTG0= X-Google-Smtp-Source: AOwi7QCFfXBLqz+3tQQDSxDXijRTnN+LIkKU6eaaYUDmpHgPUnWcoW3pkGwJyjzyWgl0p/01vB13PWGIgTE1qORK04c= X-Received: by 10.223.155.194 with SMTP id e2mr1850591wrc.49.1505833569776; Tue, 19 Sep 2017 08:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.176.149 with HTTP; Tue, 19 Sep 2017 08:05:28 -0700 (PDT) From: "M. Ranganathan" Date: Tue, 19 Sep 2017 11:05:28 -0400 Message-ID: To: opsawg@ietf.org Content-Type: multipart/mixed; boundary="94eb2c1b4e9204962305598c33a7" Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-mud-10.txt : Error in sample MUD profile. 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, 19 Sep 2017 15:06:21 -0000 --94eb2c1b4e9204962305598c33a7 Content-Type: multipart/alternative; boundary="94eb2c1b4e9204961f05598c33a5" --94eb2c1b4e9204961f05598c33a5 Content-Type: text/plain; charset="UTF-8" Hello, I believe there is an error in the sample MUD profile that has been supplied in section 8. I corrected the error. Attached is what I believe to be correct. Please verify and let me know if I have made an error. Thank you, Ranga -- M. Ranganathan --94eb2c1b4e9204961f05598c33a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I believe th= ere is an error in the sample MUD profile that has been supplied in section= 8.

I corrected the error. Attached is what I believe to be co= rrect. Please verify and let me know if I have made an error.

Thank you,


Ranga

--
M. Ranganathan
--94eb2c1b4e9204961f05598c33a5-- --94eb2c1b4e9204962305598c33a7 Content-Type: application/json; name="mud-sample.json" Content-Disposition: attachment; filename="mud-sample.json" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j7rqdd7d0 ewogICAgImlldGYtbXVkOm11ZCI6IHsKICAgICAgICAibXVkLXVybCI6ICJodHRwczovL2Jtcy5l eGFtcGxlLmNvbS8ud2VsbC1rbm93bi9tdWQvdjEvbGlnaHRidWxiMjAwMCIsCiAgICAgICAgImxh c3QtdXBkYXRlIjogIjIwMTctMDktMDdUMTM6NDc6NTIrMDI6MDAiLAogICAgICAgICJpcy1zdXBw b3J0ZWQiOiAidHJ1ZSIsCiAgICAgICAgInN5c3RlbWluZm8iOiAiaHR0cHM6Ly9ibXMuZXhhbXBs ZS5jb20vZGVzY3JpcHRpb25zL2xpZ2h0YnVsYjIwMDAiLAogICAgICAgICJjYWNoZS12YWxpZGl0 eSI6IDQ4LAogICAgICAgICJmcm9tLWRldmljZS1wb2xpY3kiOiB7CiAgICAgICAgICAgICJhY2Nl c3MtbGlzdHMiOiB7CiAgICAgICAgICAgICAgICAiYWNjZXNzLWxpc3QiOiBbewogICAgICAgICAg ICAgICAgICAgICJhY2wtbmFtZSI6ICJtdWQtODMzMTItdjZmciIsCiAgICAgICAgICAgICAgICAg ICAgImFjbC10eXBlIjogImlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdDppcHY2LWFjbCIKICAgICAg ICAgICAgICAgIH1dCiAgICAgICAgICAgIH0KICAgICAgICB9LAogICAgICAgICJ0by1kZXZpY2Ut cG9saWN5IjogewogICAgICAgICAgICAiYWNjZXNzLWxpc3RzIjogewogICAgICAgICAgICAgICAg ImFjY2Vzcy1saXN0IjogW3sKICAgICAgICAgICAgICAgICAgICAiYWNsLW5hbWUiOiAibXVkLTgz MzEyLXY2dG8iLAogICAgICAgICAgICAgICAgICAgICJhY2wtdHlwZSI6ICJpZXRmLWFjY2Vzcy1j b250cm9sLWxpc3Q6aXB2Ni1hY2wiCiAgICAgICAgICAgICAgICB9XQogICAgICAgICAgICB9CiAg ICAgICAgfQogICAgfSwKICAgICJpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3Rz IjogewogICAgICAgICJhY2wiOiBbewogICAgICAgICAgICAgICAgImFjbC1uYW1lIjogIm11ZC04 MzMxMi12NnRvIiwKICAgICAgICAgICAgICAgICJhY2wtdHlwZSI6ICJpcHY2LWFjbCIsCiAgICAg ICAgICAgICAgICAiYWNlcyI6IHsKICAgICAgICAgICAgICAgICAgICAiYWNlIjogW3sKICAgICAg ICAgICAgICAgICAgICAgICAgInJ1bGUtbmFtZSI6ICJjbDAtdG9kZXYiLAogICAgICAgICAgICAg ICAgICAgICAgICAibWF0Y2hlcyI6IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICJpcHY2 LWFjbCI6IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaWV0Zi1hY2xkbnM6c3Jj LWRuc25hbWUiOiAic2VydmljZS5ibXMuZXhhbXBsZS5jb20iLAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICJwcm90b2NvbCI6IDYsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgInNvdXJjZS1wb3J0LXJhbmdlIjogewogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAibG93ZXItcG9ydCI6IDQ0MywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgInVwcGVyLXBvcnQiOiA0NDMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB9LAogICAgICAgICAgICAgICAgICAgICAgICAgICAg InRjcC1hY2wiOiB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImlldGYtbXVkOmRp cmVjdGlvbi1pbml0aWF0ZWQiOiAiZnJvbS1kZXZpY2UiCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIH0sCiAgICAgICAgICAgICAgICAgICAgICAg ICJhY3Rpb25zIjogewogICAgICAgICAgICAgICAgICAgICAgICAgICAgInBlcm1pdCI6IFsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBudWxsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBdCiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB9XQog ICAgICAgICAgICAgICAgfQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAg ICAgICAiYWNsLW5hbWUiOiAibXVkLTgzMzEyLXY2ZnIiLAogICAgICAgICAgICAgICAgImFjbC10 eXBlIjogImlwdjYtYWNsIiwKICAgICAgICAgICAgICAgICJhY2VzIjogewogICAgICAgICAgICAg ICAgICAgICJhY2UiOiBbewogICAgICAgICAgICAgICAgICAgICAgICAicnVsZS1uYW1lIjogImNs MC1mcmRldiIsCiAgICAgICAgICAgICAgICAgICAgICAgICJtYXRjaGVzIjogewogICAgICAgICAg ICAgICAgICAgICAgICAgICAgImlwdjYtYWNsIjogewogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICJpZXRmLWFjbGRuczpkc3QtZG5zbmFtZSI6ICJzZXJ2aWNlLmJtcy5leGFtcGxlLmNv bSIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInByb3RvY29sIjogNiwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAiZGVzdGluYXRpb24tcG9ydC1yYW5nZSI6IHsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImxvd2VyLXBvcnQiOiA0NDMsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ1cHBlci1wb3J0IjogNDQzCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfSwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ0Y3AtYWNsIjogewogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJpZXRmLW11ZDpkaXJlY3Rpb24taW5pdGlhdGVkIjogImZyb20tZGV2 aWNlIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAg ICB9LAogICAgICAgICAgICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICJwZXJtaXQiOiBbCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bnVsbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgXQogICAgICAgICAgICAgICAgICAgICAg ICB9CiAgICAgICAgICAgICAgICAgICAgfV0KICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg fQogICAgICAgIF0KICAgIH0KfQo= --94eb2c1b4e9204962305598c33a7-- From nobody Tue Sep 19 08:22: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 D1D9A133200 for ; Tue, 19 Sep 2017 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 641yedAWQ7F4 for ; Tue, 19 Sep 2017 08:22:02 -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 9CAA3133020 for ; Tue, 19 Sep 2017 08:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5194; q=dns/txt; s=iport; t=1505834521; x=1507044121; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=BOICayAtS9LIcjfP5fS0wfjCqngmm12YQ1UeZMITA00=; b=F9/yuriRj4jLdW4il4Hh9fjmQcelZ8zMlXoqLR2YQ/H/6W2fKaquvb71 W6rYxlUk1t6xnZZ17gNfY77b0qzFzDSAKYOtPs0qzlzo6OwPf3l3428vg hsiXZAiLtBW89vWUfQ1WHDfpWAULkXyUVd4czYWBtFg5rDSv5x9bXnGpb 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAQBENcFZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQTAkikGaHUAcDGAEKhElPAoUdFQECAQEBAQEBAWs?= =?us-ascii?q?ohRkBAQEDAQEhSxsLBBQqAgInMAYBDAYCAQGKLxCqe4InJ4p6AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBDgoFgyuFYAuCcogLgkEfAQSKBQ2JCY1xhDqCIY17ghOBb4N?= =?us-ascii?q?7g1qHI5U3gTk1IoENMiEIHBVJhx4+NohtAQEB?= X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="asc'?scan'208,217";a="657586081" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 15:21:59 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8JFLxYI026890; Tue, 19 Sep 2017 15:21:59 GMT To: "M. Ranganathan" , opsawg@ietf.org References: From: Eliot Lear Message-ID: <0e684e4c-36d2-3778-3cbe-99cdfd4cc791@cisco.com> Date: Tue, 19 Sep 2017 17:22:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U37mQ1v2Gh3aumrfjht3SboM3WXC2Ux2e" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-10.txt : Error in sample MUD profile. 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, 19 Sep 2017 15:22:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U37mQ1v2Gh3aumrfjht3SboM3WXC2Ux2e Content-Type: multipart/mixed; boundary="rkGcDtVBXQajGXbPTCwBkdCfln0E9b33A"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , opsawg@ietf.org Message-ID: <0e684e4c-36d2-3778-3cbe-99cdfd4cc791@cisco.com> Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-10.txt : Error in sample MUD profile. References: In-Reply-To: --rkGcDtVBXQajGXbPTCwBkdCfln0E9b33A Content-Type: multipart/alternative; boundary="------------CED7F9D015528A3DDD7E3D98" Content-Language: en-US This is a multi-part message in MIME format. --------------CED7F9D015528A3DDD7E3D98 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Ranga.=C2=A0 I confirm this is indeed a bug in the example, and w= ill take your correction.=C2=A0 What happened was that we changed "is-support= ed" to mandatory based on Joe's suggestion, but I failed to make the change in the tool that generated the example.=C2=A0 I am correcting this in my working copy. Eliot On 9/19/17 5:05 PM, M. Ranganathan wrote: > Hello, > > I believe there is an error in the sample MUD profile that has been > supplied in section 8. > > I corrected the error. Attached is what I believe to be correct. > Please verify and let me know if I have made an error. > > Thank you, > > > Ranga > > --=20 > M. Ranganathan > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------CED7F9D015528A3DDD7E3D98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks, Ranga.=C2=A0 I confirm this is indeed a bug in the example= , and will take your correction.=C2=A0 What happened was that we chan= ged "is-supported" to mandatory based on Joe's suggestion, but I failed to make the change in the tool that generated the example.=C2= =A0 I am correcting this in my working copy.

Eliot


On 9/19/17 5:05 PM, M. Ranganathan wrote:
Hello,

I believe there is an error in the sample MUD profile that has been supplied in section 8.

I corrected the error. Attached is what I believe to be correct. Please verify and let me know if I have made an error.

Thank you,


Ranga

--
M. Ranganathan 


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

--------------CED7F9D015528A3DDD7E3D98-- --rkGcDtVBXQajGXbPTCwBkdCfln0E9b33A-- --U37mQ1v2Gh3aumrfjht3SboM3WXC2Ux2e 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 iQEcBAEBCAAGBQJZwTYYAAoJEIe2a0bZ0nozjM8IAK6L2H+UrJZETOps+0qFElv6 vT8mLU8tQe6opo3636uBb/ZP6vg0ABSmIsNwiCAdKo1NZ0my/5EWw12qidcPb6ov r46kylyRZUKQbjHG80+5ttRbcSnv6dzDjjwbSAAex8bPlgcO/gnCjEYDTS0105IG 8ieZR5IMNw/XZo65Z1pAecb/1mhAYrv7jNpMhv08kiBab2SjKfdyZh3XEmm/uz5c vFakrboF6LpIJ8nmQLrbC833R6Np4z1po85zfIDb7Un3N3nATFHzTenjN9D8pcy6 FjlEKHVANJU9xBA3dj8IGn3QYMgPqM7iLCs7KLlUJJBbKGD7pHs+oDFxL1tFedg= =u5fV -----END PGP SIGNATURE----- --U37mQ1v2Gh3aumrfjht3SboM3WXC2Ux2e-- From nobody Tue Sep 19 13:11:33 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 19352132320 for ; Tue, 19 Sep 2017 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 a9JqU_lSIGBM for ; Tue, 19 Sep 2017 13:11:31 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A789A1321A2 for ; Tue, 19 Sep 2017 13:11:30 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id i189so1903764wmf.1 for ; Tue, 19 Sep 2017 13:11:30 -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=c2cSK/zdyPt6UQnvMF+MRrYvCaeeXqLHySvxd5iBXJ0=; b=ZrRnNxMC2BfX2wZQriGBBVl+fvaWSfnlLmEesXx5Nwu2Mr+TkBc3dXl7sVf7M0uraO SVa2RpGrVfMs4Z2YJSIj9cmmLVfySvu0mEiq6XXv7+Oho4UXnxGflLbhZEfrRATZYHF4 CLzGSSJ2c3r43SjpQY93s5TD/lrzTpPaIdk2ZYYGnnwVz0dn/D0Jn5j6/zZyhFQtzNd+ ueykMrS0XRgPGzcLv1G2BiW/vYq8El5wZCpmB/vYdR9mBcuOvdQkUOtUnYZqPajiWhA8 lA9nNWAIDj6ymcVQB1jDlNJCkziHoGLGZQmR6b/sxAgT9zAzv3niG/RcVFyVsjo5Occt lczw== 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=c2cSK/zdyPt6UQnvMF+MRrYvCaeeXqLHySvxd5iBXJ0=; b=YdoXTLG8LLP6QO7HU0ruVMCnHN0oaFlIJDf+hH/I/PQZ+PwAnc3tYVToKZbviMqaSo M/KZUJEyogcVObalhxalzn9JtzKMQpqBjA5kkPmWWQrZkscwxbniKkuxTeo+R6HXxbtj wU8xXLgmrlyesCgbe/M9DrgjrQJkB4oMlxfgsv3aPtNtFNwaGHJXHeeGUrnF+3N1C/+g JmONA1a6/Wq/TFIuVSbXQnICr4snO7icLbehg6LvCZytENBoo1mtLMq6IrUOGQND1zBr fyKiqppraaXPDnEEgoNmE3tgfPjAYwdbgkLuhFUHI/Uh6LFAiPmGce3XxYpnQs4pxPoo AFAQ== X-Gm-Message-State: AHPjjUjbBoVW1eFFVrVgQ1rQ4Bqjt5U8qvc6gugq4kSwHN+iOrBWOYUZ ksdKogjTXkKvQVLzl+Zg4C+VSHmGw7hce1O1ECI= X-Google-Smtp-Source: AOwi7QDGL4iW/Y0OEiYvybwEKcXfCBBQzRQWUjePfpyIg+l5VkoyIfNX+nBXn0d8K9qA0C9wedNJ2ix39bCzQ0t8luk= X-Received: by 10.28.132.73 with SMTP id g70mr1890080wmd.33.1505851888704; Tue, 19 Sep 2017 13:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.176.149 with HTTP; Tue, 19 Sep 2017 13:10:47 -0700 (PDT) From: "M. Ranganathan" Date: Tue, 19 Sep 2017 16:10:47 -0400 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a114445f8e9250005599076bc" Archived-At: Subject: [OPSAWG] Associating a MUD profile with a specific device 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, 19 Sep 2017 20:11:32 -0000 --001a114445f8e9250005599076bc Content-Type: text/plain; charset="UTF-8" Hello! MUD profiles are globally identified by the MUD URL. Devices are identified by a global Identifier (e.g. MAC address). In implementing this, I need to associate a specific MUD profile with a specific device. Would the authors consider it within scope to provide some guidance on this (for example a simple YANG model that provides the structure of a JSON document that can give such a mapping) ? Thanks for reading. Ranga. -- M. Ranganathan --001a114445f8e9250005599076bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

MUD profiles are globally identified by= the MUD URL. Devices are identified by a global Identifier (e.g. MAC addre= ss).

In implementing this, I need to associate a specific MUD profil= e with a specific device.

Would the authors consider it within= scope to provide some guidance on this (for example a simple YANG model th= at provides the structure of a JSON document that can give such a mapping) = ?


Thanks for reading.

Ranga.


--
M. Ranganathan
--001a114445f8e9250005599076bc-- From nobody Tue Sep 19 14:39:38 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 6A490132D42 for ; Tue, 19 Sep 2017 14:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 2ZfZDY5Eqt6b for ; Tue, 19 Sep 2017 14:39:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54921132026 for ; Tue, 19 Sep 2017 14:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6265; q=dns/txt; s=iport; t=1505857175; x=1507066775; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=/SyiePdBZ/r9yG+V9RmzwcuXT7I5lGtwoB/+9U4BW5Q=; b=TLzGXlwRQUvDAECIupn7rNdBwB0oiNpJEcMyleb6oBn/3WuAh/ZxmC75 RIPlFW9esOhgk12bPIH8J9V/SBrEuN2dksgbXqMMfkwT+wlAvVug54fBT Jw0SAjRa9i8CgjZPjPvVelTcbpXdvwL9T5viTurxgegU6dD1dCi4qz+6W w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApCABJjcFZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQSyuQZ4dQBwMYAQqESU8ChR0VAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDAQEhSxsLBBQqAgInMAYBDAYCAQGKLxCoaIInJ4p4AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBDgoFgyuFYguCcoRlgymCQR8FihKOMIhKhDqCIY17hAKHVYc?= =?us-ascii?q?jlTeBOTUigQ0yIQgcFUmFGRyBZgM+Noh6AQEB?= X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="asc'?scan'208,217";a="654749857" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 21:39:32 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8JLdWD9009205; Tue, 19 Sep 2017 21:39:32 GMT To: "M. Ranganathan" , opsawg@ietf.org References: From: Eliot Lear Message-ID: Date: Tue, 19 Sep 2017 23:39:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OIRf950Lo2rVoeWBlDwv5KVvMmfqx5tfO" Archived-At: Subject: Re: [OPSAWG] Associating a MUD profile with a specific device 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, 19 Sep 2017 21:39:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OIRf950Lo2rVoeWBlDwv5KVvMmfqx5tfO Content-Type: multipart/mixed; boundary="4NF6RNARpplxljxJjHmVanPiI8SK4HVm1"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] Associating a MUD profile with a specific device References: In-Reply-To: --4NF6RNARpplxljxJjHmVanPiI8SK4HVm1 Content-Type: multipart/alternative; boundary="------------E3CCAB0353EC1F2D192109E6" Content-Language: en-US This is a multi-part message in MIME format. --------------E3CCAB0353EC1F2D192109E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ranga, The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.=C2=A0 And= so the MUD Controller functionality sits next to FreeRadius through callouts.=C2=A0 I don't think we want to get that specific in the draft, = and there are others who don't want to bother with Radius at all in their implementations but would just assume use other control functions.=C2=A0 = And that's fine.=C2=A0 In fact, you could build the functionality into a DHCP= server, which I did in my first implementation.=C2=A0 So I'm not quite su= re what to write.=C2=A0 Suggestions welcome ;-) Eliot ps: thanks for kinking out the example.=C2=A0 Chairs, I'll submit an upda= ted draft with the example corrected. On 9/19/17 10:10 PM, M. Ranganathan wrote: > Hello! > > MUD profiles are globally identified by the MUD URL. Devices are > identified by a global Identifier (e.g. MAC address). > > In implementing this, I need to associate a specific MUD profile with > a specific device. > > Would the authors consider it within scope to provide some guidance on > this (for example a simple YANG model that provides the structure of a > JSON document that can give such a mapping) ? > > > Thanks for reading. > > Ranga. > > > --=20 > M. Ranganathan > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------E3CCAB0353EC1F2D192109E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ranga,

The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.=C2=A0 And so the MUD Controller functionality sits next to= FreeRadius through callouts.=C2=A0 I don't think we want to get tha= t specific in the draft, and there are others who don't want to bother with Radius at all in their implementations but would just assume use other control functions.=C2=A0 And that's fine.=C2=A0 In= fact, you could build the functionality into a DHCP server, which I did in my first implementation.=C2=A0 So I'm not quite sure what to wri= te.=C2=A0 Suggestions welcome ;-)

Eliot

ps: thanks for kinking out the example.=C2=A0 Chairs, I'll submit = an updated draft with the example corrected.


On 9/19/17 10:10 PM, M. Ranganathan wrote:
Hello!

MUD profiles are globally identified by the MUD URL. Devices are identified by a global Identifier (e.g. MAC address).

In implementing this, I need to associate a specific MUD profile with a specific device.

Would the authors consider it within scope to provide some guidance on this (for example a simple YANG model that provides the structure of a JSON document that can give such a mapping) ?


Thanks for reading.

Ranga.


--
M. Ranganathan


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

--------------E3CCAB0353EC1F2D192109E6-- --4NF6RNARpplxljxJjHmVanPiI8SK4HVm1-- --OIRf950Lo2rVoeWBlDwv5KVvMmfqx5tfO 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 iQEcBAEBCAAGBQJZwY6UAAoJEIe2a0bZ0nozrycH/Rc1SCfX4QakmqR/Na0L3l+A mrhI0DEqcl83ktDz4KOlKJrEuGDQbo1sedLsUC2tKSStcjKf80PijPZowA9nNdXk Hf59JZ/OtGtiTBSa3u86LR2hN7eBQ5FQC/4cukIxc6PYDVgu+uh0M2IvowkMf3eq y4YalWYlklmdO7CjDjve/Ki0bIwS6u1/8b2jfysfwCD2cAzH6V3fi4BuZUINMp5B hcWVX16v4mghi0LfSk0ItP0On5PWYBoANyQv94H2ZArwf9tUiowGJ74gP2bxEVfb M8fxGp14rRqxrvXNUcSsslr4N44vMwEGEVplqOOAynbXvu/BDxg8jrLLKyBLdfA= =Ca8L -----END PGP SIGNATURE----- --OIRf950Lo2rVoeWBlDwv5KVvMmfqx5tfO-- From nobody Tue Sep 19 19:23: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 02E43132D45 for ; Tue, 19 Sep 2017 19:23:22 -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 bfJBlGV-g95f for ; Tue, 19 Sep 2017 19:23:19 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F78F132A05 for ; Tue, 19 Sep 2017 19:23:19 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id g206so3316251wme.0 for ; Tue, 19 Sep 2017 19:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mt7ipll6UOd7MvfsnHR8GgitJRdYZJiDXWsxJo0t9Sw=; b=n/hj91BDnb3zh05nOm0Cm4S+XPn2GQzd3Jn3vjOKMc12mJxdsY6pZonZgNIrBvCol0 PPxnOYva2Hw2SXy5clmqPe9zXZBRYkn9zS50rPZ7Aowkynv4eW2Oa2QXGxry5wOyvWvJ IQPcvClY9frltPibqRbMV79BDHlET1sXeqyI43pQFB6+iE6aVEyZliEGPiQ5PGjWGif5 Di6XX0XL0hH4eMpTbzAyONAnnBj4SKb2OkgzKvolPj1pUcqZ0/ysEFtwOXavcso1el1m iPCeMNA3vQUQNWQsBC2bjWHPHAmYjKKq53Swnpx4YnoQweb28sPQlsWdGT4kbuuRjsSe UBSg== 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=Mt7ipll6UOd7MvfsnHR8GgitJRdYZJiDXWsxJo0t9Sw=; b=VzrcW+kTtB/0NV0feUU/ndFOOSxjeITIF55EenXSqAthgHaEHxGMThMcJMhn17ztCI MkZG0nUVN2AajTamrRnLjPWPgnmkqaSKO0l8PmsQvo5HNCEYNYxQLnZesmr8Fc/RdZAS iPcD7nb8lcmzLp19rXLF6GZDpbfBzNxhGDZ9fF4CCaIZmBrO6BAra8E+Nxi8Dm5S5ymO yXbJz3XZWABn8ASPypU/SJFuejCiBNVpdyAK6YfWUkML6ycskJwrtYdKWJqT9KWekXqt GfvV7nBIdMsyHNF3sJzWvIKWI565rrkftLi6gVpofaf9zvJ4GFJtFy8jzUmFASPpJio3 2VvA== X-Gm-Message-State: AHPjjUiJsnHRe9CvZFEjiyWR9cK69/7LhbTddlsrgfXTfJ4tvHh9y2NK 9znQqMKq8fyz+yrkg2u/pW51/gh6C30rvbYO83I= X-Google-Smtp-Source: AOwi7QC7WrffB534Ohw0BGV43nF8/M6XfJqy4DTx4ntab9Io0c6w/XtE6Xp0SwnSogflzT3rewh9fmZqFEPibY5t8gA= X-Received: by 10.28.63.134 with SMTP id m128mr2724486wma.137.1505874197521; Tue, 19 Sep 2017 19:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.176.149 with HTTP; Tue, 19 Sep 2017 19:22:36 -0700 (PDT) In-Reply-To: References: From: "M. Ranganathan" Date: Tue, 19 Sep 2017 22:22:36 -0400 Message-ID: To: Eliot Lear Cc: opsawg@ietf.org Content-Type: multipart/mixed; boundary="001a1148be069ef1fb055995a887" Archived-At: Subject: Re: [OPSAWG] Associating a MUD profile with a specific device 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, 20 Sep 2017 02:23:22 -0000 --001a1148be069ef1fb055995a887 Content-Type: multipart/alternative; boundary="001a1148be069ef1f3055995a885" --001a1148be069ef1f3055995a885 Content-Type: text/plain; charset="UTF-8" Hi Eliot, Attached is a proposed YANG file that defines a device to MUD association. May I suggest words to the following effect: Implementations MAY choose to implement a mapping between a MUD URL and a device identifier. Such a mapping may be communicated to the MUD controller, which can then install access control rules based on a previously retrieved MUD file. The mapping must conform to the YANG specification below. How does this sound? Thanks. On Tue, Sep 19, 2017 at 5:39 PM, Eliot Lear wrote: > Hi Ranga, > > The way we did the early code on github was just with FreeRadius and > leveraging sessions which are indexed precisely by MAC address. And so the > MUD Controller functionality sits next to FreeRadius through callouts. I > don't think we want to get that specific in the draft, and there are others > who don't want to bother with Radius at all in their implementations but > would just assume use other control functions. And that's fine. In fact, > you could build the functionality into a DHCP server, which I did in my > first implementation. So I'm not quite sure what to write. Suggestions > welcome ;-) > > Eliot > > ps: thanks for kinking out the example. Chairs, I'll submit an updated > draft with the example corrected. > > On 9/19/17 10:10 PM, M. Ranganathan wrote: > > Hello! > > MUD profiles are globally identified by the MUD URL. Devices are > identified by a global Identifier (e.g. MAC address). > > In implementing this, I need to associate a specific MUD profile with a > specific device. > > Would the authors consider it within scope to provide some guidance on > this (for example a simple YANG model that provides the structure of a JSON > document that can give such a mapping) ? > > > Thanks for reading. > > Ranga. > > > -- > M. Ranganathan > > > _______________________________________________ > OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg > > > -- M. Ranganathan --001a1148be069ef1f3055995a885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

Attached is a propos= ed YANG file that defines a device to MUD association. May I suggest words = to the following effect:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implem= entations MAY choose to implement a mapping between a MUD URL and a device = identifier. Such a mapping may be communicated to the MUD controller, which= can then install access control rules based on a previously retrieved MUD = file. The mapping must conform to the YANG specification below.

How does this sound? Thanks.



On Tue, Se= p 19, 2017 at 5:39 PM, Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20

Hi Ranga,

The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.=C2=A0 And so the MUD Controller functionality sits next to FreeRadius through callouts.=C2=A0 I don't think we want to get t= hat specific in the draft, and there are others who don't want to bother with Radius at all in their implementations but would just assume use other control functions.=C2=A0 And that's fine.=C2=A0 = In fact, you could build the functionality into a DHCP server, which I did in my first implementation.=C2=A0 So I'm not quite sure what to w= rite.=C2=A0 Suggestions welcome ;-)

Eliot

ps: thanks for kinking out the example.=C2=A0 Chairs, I'll submi= t an updated draft with the example corrected.


On 9/19/17 10:10 P= M, M. Ranganathan wrote:
=20
Hello!

MUD profiles are globally identified by the MUD URL. Devices are identified by a global Identifier (e.g. MAC address).

In implementing this, I need to associate a specific MUD profile with a specific device.

Would the authors consider it within scope to provide some guidance on this (for example a simple YANG model that provides the structure of a JSON document that can give such a mapping) ?


Thanks for reading.

Ranga.


--
M. Ranganathan


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




--
M. Ranganathan
--001a1148be069ef1f3055995a885-- --001a1148be069ef1fb055995a887 Content-Type: application/octet-stream; name="ietf-mud-device-association.yang" Content-Disposition: attachment; filename="ietf-mud-device-association.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j7se79os1 bW9kdWxlIGlldGYtbXVkLWRldmljZS1hc3NvY2lhdGlvbiB7CiAgeWFuZy12ZXJzaW9uIDEuMTsK ICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW11ZC1kZXZpY2Ut YXNzb2NpYXRpb24iOwogIHByZWZpeCBpZXRmLW11ZC1kZXZpY2UtYXNzb2NpYXRpb247CgogIGlt cG9ydCBpZXRmLWluZXQtdHlwZXMgewogICAgcHJlZml4IGluZXQ7CiAgfQoKICBvcmdhbml6YXRp b24KICAgICJJRVRGIE9QU0FXRyAoT3BzIEFyZWEpIFdvcmtpbmcgR3JvdXAiOwogIGNvbnRhY3QK ICAgICJXRyBXZWI6IGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9vcHNhd2cvCiAgICAgV0cgTGlz dDogb3BzYXdnQGlldGYub3JnCiAgICAgQXV0aG9yOiBFbGlvdCBMZWFyCiAgICAgbGVhckBjaXNj by5jb20KICAgICBBdXRob3I6IFJhbHBoIERyb21zCiAgICAgcmRyb21zQGdtYWlsLmNvbQogICAg IEF1dGhvcjogRGFuIFJvbWFzY2FudQogICAgIGRyb21hc2NhQGdtYWlsLmNvbQogICAgIjsKICBk ZXNjcmlwdGlvbgogICAgIkEgY29ycmVsYXRpb24gYmV0d2VlbiBEZXZpY2UgSWRlbnRpZmllciBh bmQgWWFuZyBVUkwiOwoKICByZXZpc2lvbiAyMDE3LTA5LTE1IHsKICAgIGRlc2NyaXB0aW9uCiAg ICAgICJJbml0aWFsIHByb3Bvc2VkIHN0YW5kYXJkLiI7CiAgICByZWZlcmVuY2UKICAgICAgIlJG QyBYWFhYOiBNYW51ZmFjdHVyZXIgVXNhZ2UgRGVzY3JpcHRpb24KICAgICAgIFNwZWNpZmljYXRp b24iOwogIH0KICAKICBjb250YWluZXIgbWFwcGluZyB7CiAgICAgZGVzY3JpcHRpb24KICAgICAg ICAgIk1hcHBpbmcgYmV0d2VlbiBkZXZpY2UgSUQgYW5kIE1VRCBVUkkiOwogICAgIGxlYWYgZGV2 aWNlLWlkIHsKICAgICAgCWRlc2NyaXB0aW9uCiAgICAgICAgICAgIklPVCBkZXZpY2UgaWRlbnRp Zmllci4gKGUuZy4gTUFDIGFkZHJlc3MpIjsKICAgICAgICB0eXBlIHN0cmluZyB7CiAgICAgICAg ICAgbGVuZ3RoICIxLi42NCI7CiAgICAgICAgfQogICAgIH0KCiAgICAgbGVhZiBtdWQtdXJpIHsK ICAgICAgCWRlc2NyaXB0aW9uCiAgICAgICAgICAgIk1VRCB1cmkgdG8gYXNzb2NpYXRlIHdpdGgg dGhpcyBkZXZpY2UiOwogICAgICAgICB0eXBlIGluZXQ6dXJpOwogICAgIH0KICB9Cn0KCg== --001a1148be069ef1fb055995a887-- From nobody Tue Sep 19 23:05:14 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 3FF231331FF; Tue, 19 Sep 2017 23:05:13 -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, 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 jlgyCwNKtcKS; Tue, 19 Sep 2017 23:05:12 -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 8743F1331F5; Tue, 19 Sep 2017 23:05:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOY34644; Wed, 20 Sep 2017 06:05:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 20 Sep 2017 07:05:09 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 20 Sep 2017 14:05:06 +0800 From: Tianran Zhou To: "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-capwap-alt-tunnel-10 Thread-Index: AdMx1mdmlA5ckKCRRgOkkH52TiYS4g== Date: Wed, 20 Sep 2017 06:05:05 +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.0A0B0204.59C20516.0058, 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: 66e27cdcded1c4e138201a5414d61482 Archived-At: Subject: [OPSAWG] WG LC for draft-ietf-opsawg-capwap-alt-tunnel-10 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, 20 Sep 2017 06:05:13 -0000 Dear OPSAWG, The following draft was sent to IESG, but received some critical comments.= =20 Alternate Tunnel Encapsulation for Data Frames in CAPWAP https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-10 Now the authors have addressed all the comments, and received confirmation = from the Security DIR reviewer. https://datatracker.ietf.org/doc/review-ietf-opsawg-capwap-alt-tunnel-09-se= cdir-early-meadows-2017-08-10/ This is a notice to start a two-week OPSAWG WG last call review for the doc= ument. Please read the above draft and send any issues, comments, or corrections t= o this mailing list. Please indicate your support or concerns by Wednesday Oct 4, 2017. Please note that the authors decided to change the document type to Experim= ental, as stated below: 1.3. History of the document This document was started to accommodate Service Provider's need of a more flexible deployment mode with alternative tunnels [RFC7494]. Experiments and tests have been done for this alt-tunnel network infrastructure. However important, the deployment of relevant technology is yet to complete. This experimental document is intended to serve as a historical reference for any future work as to the operational and deployment requirements. Thanks, Tianran, as co-chair From nobody Wed Sep 20 05:05:24 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 B753013309C for ; Wed, 20 Sep 2017 05:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 njIF-nY4Z-xB for ; Wed, 20 Sep 2017 05:05:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F05132D8A for ; Wed, 20 Sep 2017 05:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11326; q=dns/txt; s=iport; t=1505909119; x=1507118719; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=L42L8xSc+h0I/BSCyDQctvnBqRRChPepqmjcdfHZPYg=; b=M2re+9ikoKauisVTWN5WAveWKfFwFqOdEtevEXa032Mdsj/Z2DpSmv6k 1DTWl8OZfjrkacfKOJcDavdV5b5WTdNFNYcxxrGjMzxA5p+tWOLwwjshP njqjFKFie0jL9MFPbQiqxUJDJu1xCTRBLSsLRmCRDFkOdH/RUfbRGahGn M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQDWWMJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQSSuQaIU+ghIHAxgBCoRJTwKFJRYBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQMBASFLCxAJAhgnAwICJx8RBg0GAgEBii8QiiCdZoInJ4p0AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBDgoFgyuFYguCcoRlgymCQR8BBIoVjjCISoQ7giG?= =?us-ascii?q?Ne4QCh1WHJJU4gTkmCSiBDTIhCBwVSYRgORyBZgM+NokYAQEB?= X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="asc'?scan'208,217";a="654763741" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 12:05:16 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8KC5Gcr016776; Wed, 20 Sep 2017 12:05:16 GMT To: "M. Ranganathan" Cc: opsawg@ietf.org References: From: Eliot Lear Message-ID: <1c215882-9325-91ae-da02-7ed57a0a26a3@cisco.com> Date: Wed, 20 Sep 2017 14:05:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bl3wOa3iDbrSWgnrIErK9U8A2c9qv65XM" Archived-At: Subject: Re: [OPSAWG] Associating a MUD profile with a specific device 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, 20 Sep 2017 12:05:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Bl3wOa3iDbrSWgnrIErK9U8A2c9qv65XM Content-Type: multipart/mixed; boundary="J5oLQFWsdvlTrG9Tb0XJiL7jajPkHj1UW"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" Cc: opsawg@ietf.org Message-ID: <1c215882-9325-91ae-da02-7ed57a0a26a3@cisco.com> Subject: Re: [OPSAWG] Associating a MUD profile with a specific device References: In-Reply-To: --J5oLQFWsdvlTrG9Tb0XJiL7jajPkHj1UW Content-Type: multipart/alternative; boundary="------------8941C4FA5B01455CEBCFD35C" Content-Language: en-US This is a multi-part message in MIME format. --------------8941C4FA5B01455CEBCFD35C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ranga, I think this makes sense for a MUD controller YANG model, but doesn't do well in a MUD file itself.=C2=A0 We stop short of that in the document, f= or fear of boiling the ocean, but I would happily do some follow-up work with you that would include this, if you're interested.=C2=A0 The model *= is* structured so that you can "use" appropriate elements. Eliot On 9/20/17 4:22 AM, M. Ranganathan wrote: > Hi Eliot, > > Attached is a proposed YANG file that defines a device to MUD > association. May I suggest words to the following effect: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementations MAY choose to implement = a mapping between a MUD > URL and a device identifier. Such a mapping may be communicated to the > MUD controller, which can then install access control rules based on a > previously retrieved MUD file. The mapping must conform to the YANG > specification below. > > How does this sound? Thanks. > > > > On Tue, Sep 19, 2017 at 5:39 PM, Eliot Lear > wrote: > > Hi Ranga, > > The way we did the early code on github was just with FreeRadius > and leveraging sessions which are indexed precisely by MAC > address.=C2=A0 And so the MUD Controller functionality sits next to= > FreeRadius through callouts.=C2=A0 I don't think we want to get tha= t > specific in the draft, and there are others who don't want to > bother with Radius at all in their implementations but would just > assume use other control functions.=C2=A0 And that's fine.=C2=A0 In= fact, > you could build the functionality into a DHCP server, which I did > in my first implementation.=C2=A0 So I'm not quite sure what to wri= te.=C2=A0 > Suggestions welcome ;-) > > Eliot > > ps: thanks for kinking out the example.=C2=A0 Chairs, I'll submit a= n > updated draft with the example corrected. > > > On 9/19/17 10:10 PM, M. Ranganathan wrote: >> Hello! >> >> MUD profiles are globally identified by the MUD URL. Devices are >> identified by a global Identifier (e.g. MAC address). >> >> In implementing this, I need to associate a specific MUD profile >> with a specific device. >> >> Would the authors consider it within scope to provide some >> guidance on this (for example a simple YANG model that provides >> the structure of a JSON document that can give such a mapping) ? >> >> >> Thanks for reading. >> >> Ranga. >> >> >> --=20 >> M. Ranganathan >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > > > --=20 > M. Ranganathan --------------8941C4FA5B01455CEBCFD35C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ranga,

I think this makes sense for a MUD controller YANG model, but doesn't do well in a MUD file itself.=C2= =A0 We stop short of that in the document, for fear of boiling the ocean, but I would happily do some follow-up work with you that would include this, if you're interested.=C2=A0 The model *is* structured so that you can "use" appropriate elements.

Eliot

On 9/20/17 4:22 AM, M. Ranganathan wrote:
Hi Eliot,

Attached is a proposed YANG file that defines a device to MUD association. May I suggest words to the following effect:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementations MAY choose to im= plement a mapping between a MUD URL and a device identifier. Such a mapping may be communicated to the MUD controller, which can then install access control rules based on a previously retrieved MUD file. The mapping must conform to the YANG specification below.

How does this sound? Thanks.



On Tue, Sep 19, 2017 at 5:39 PM, Eliot= Lear <lear@cisco.com> wrote:

Hi Ranga,

The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.=C2=A0 And so the MUD Controller= functionality sits next to FreeRadius through callouts.=C2= =A0 I don't think we want to get that specific in the draft, and there are others who don't want to bother with Radius at all in their implementations but would just assume use other control functions.=C2=A0 And that's fine= =2E=C2=A0 In fact, you could build the functionality into a DHCP server, which I did in my first implementation.=C2=A0 So = I'm not quite sure what to write.=C2=A0 Suggestions welcome ;= -)

Eliot

ps: thanks for kinking out the example.=C2=A0 Chairs, I'= ll submit an updated draft with the example corrected.


On= 9/19/17 10:10 PM, M. Ranganathan wrote:
Hello!

MUD profiles are globally identified by the MUD URL. Devices are identified by a global Identifier (e.g. MAC address).

In implementing this, I need to associate a specific MUD profile with a specific device.

Would the authors consider it within scope to provide some guidance on this (for example a simple YANG model that provides the structure of a JSON document that can give such a mapping) ?


Thanks for reading.

Ranga.


--
M. Ranganathan


_______________________________________________=

OPSAWG mailing list
OPSAWG@ietf=
=2Eorg
https://www.ietf.org/mailman/listinfo/opsawg




--
M. Ranganathan

--------------8941C4FA5B01455CEBCFD35C-- --J5oLQFWsdvlTrG9Tb0XJiL7jajPkHj1UW-- --Bl3wOa3iDbrSWgnrIErK9U8A2c9qv65XM 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 iQEcBAEBCAAGBQJZwll9AAoJEIe2a0bZ0nozo+MH/3GveYCqtEiz/3HkNhnmoXSK xqMU9rzA7oh7bjLzLyu+nPRI6MM4Gz5itXp1xwE/arxZM0euvqGECu7YKv4NW85u h/A5WV3CKX3RqnXLv+wk+ObYte97JLXhZ1o8rA2CKwP9KMQKHjW1sYbzs8z5k3is An0w1QgvtiLzC4yhvhmJuG2N/+KIMeo+9q+OaOXYJWkSH0Bd+n7+jaA+ldcWz/U+ vZGVT4US46yn5cMQ7/57+0n8niqNHMuHL/o1WGX4tFDO0JRG/OhTTWHSBhuSU2fE 1lgB7QX3OdCWRWEqFaD4yoIPqXCZlJBGFGJNmL8wK2McGdHwt4WVltGJCxa3m1o= =en3T -----END PGP SIGNATURE----- --Bl3wOa3iDbrSWgnrIErK9U8A2c9qv65XM-- From nobody Wed Sep 20 05:09:02 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 EA178133208 for ; Wed, 20 Sep 2017 05:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 fnpg9-CvpOx3 for ; Wed, 20 Sep 2017 05:08:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E201C1330B0 for ; Wed, 20 Sep 2017 05:08:57 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8KC8p33008447; Wed, 20 Sep 2017 13:08:51 +0100 Received: from 950129200 (14.143.0.166.static-Bangalore.vsnl.net.in [14.143.0.166] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8KC8aRR008140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Sep 2017 13:08:38 +0100 Reply-To: From: "Adrian Farrel" To: "'Benoit Claise'" , "'Warren Kumari'" Cc: References: <57bf897c-e73d-9f80-a950-e4c4488afd34@cisco.com> In-Reply-To: <57bf897c-e73d-9f80-a950-e4c4488afd34@cisco.com> Date: Wed, 20 Sep 2017 13:08:33 +0100 Message-ID: <000001d33209$361ef7d0$a25ce770$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D33211.987F9FD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7Kyvs+tH/F4htDHmBhyx05xyzfwJusmlFAhTCjleiSR1YsA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23340.006 X-TM-AS-Result: No--15.860-10.0-31-10 X-imss-scan-details: No--15.860-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wvHkpkyUphL9lnrMq7Sriu2tj24Xqh0yXJxz 8+1dXyV4uGX5AZSrLM1Pa8UT3XZGDUV5O+xleW7dq32frrMnhEgxmbT6wQT2azDJ9a3KikGoqNz FwBkJ21IwAfScvvrUM0Lrnfjz6hmBaaqmAEPierlGJnE5XyPHNR5Jxf+4R9RQH1bhq4z+yfTppS idUMY3mna2VeE+ClDj1euLY6sGIA2+nJy1vifqQKMVgdN9w+TCUAjrAJWsTe/uctKrs61Fuh/XW BLkU7fuwzinqQws1AEfCkhL7SBG2yXXbtXiPajq2MZGQuKc8UjomXBvaBu6TrNcuCb8CAxuJVQ4 6Q8XiFszMPsAUlhzd0rMGhWWJAzLs/ej5mUo2GpKI+uDi8kwFxhcBBg0V+bsp2ulO+HtPqjySB7 JjVu4s91KwTDIkMiWunWDwMH4dH5I5I2GT1aZYVaOpp/sV5nVGWAN/II9wcTXTA80i6/KL36mo6 ehk50q8zkzqzURdOAchUcS8LzhCEFqCrEjrohVuBBnazCkvjnyoHHk1agFzVc/CedjlcvkMZCZ9 Of61QrTlc582adLpMFZ6pP5ZJgqMg7GGcwuYAFNI82n17+7U7w2HnQG+TrAHggJqAfWmvT21IT7 +uo2GHLPhc0tkM4WdDR/Dqv4Pzx9ZyRrPnV8FQIKV2KH2USqu25uKJ7B5a50PA/ki2kI7BxJEX0 k/k7OLiNvWfV40DeHMqVObyPMMsNYV73vYBFQjtK7dC6UBnkUqWKocoJo6esoDDE6CvPdp4Wcmy qBbFxC3bjvSDu959+suYAg9ZWJMxvA4OPLCf6eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyJXaDn6D hA2ArkblkrgCLv4sjvNV98mpPNezFOxtL4G4vxOVeazcBUdWd1DvS73AL+VzF8cyRTnP+OF+dz5 YU6YoGXE5dmfIfAZTbVsG/A7ZJqckQQekBKiJMj4NFfBevI= Archived-At: Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Wed, 20 Sep 2017 12:09:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D33211.987F9FD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Benoit, =20 Thanks for the review. =20 > Figure 3: Network configuration model is a brand new term that is only = mentioned > in the figure, and not explained. =20 OMG! That is a good catch. =20 > In the same figure, could the "Device Configuration Model" be renamed = to RFC 8199=20 > "Network Element YANG module" (this is what you did in figure 4 = anyway) =20 I believe we are separating the "device configuration model" that is = used to talk to an NE, and a "network configuration model" used to talk = to a controller that is responsible for a set of NEs. I think the = correct thing is to add exactly that statement (i.e., a definition of = the terms alongside figure 3). Then the mapping of these terms should = show up alongside Figure 4. =20 But, you know what? Looking at this made me go back to Figure 1 of RFC8199 again. And = finally I understood it. That is probably a bit sad. I had been misled (no blame associated) by the OSS/BSS box in the figure = because that is an entity not a module. That made me read the horizontal = lines as interfaces (over which the named module types are used) and the = boxes as functional units that consume the modules. Now, that is a *horrible* misreading, but there we go! And RFC8199 has = already been published, so adding clarification so that fools like me = are not confused is not possible. =20 I believe the intention is to only show modules and not things that = consume or use modules. So I wonder whether we should make some clarification in our Figure 4. = Possibly it should look like... =20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Operations Support and Business Support YANG Modules =20 +-----------------------+ +-----------------------+ | | | | | Customer Service | | Other | =20 | YANG Modules | | Operations Support | | | | and | | +------+ +------+ | | Business Support | | | | | | | | YANG Modules | | | L2SM | | L3SM | | | | | | | | | | | | | +------+ +------+ | | | | | | | +-----------------------+ +-----------------------+ =20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Network Service YANG Modules =20 +------------+ +-------------+ +-------------+ +-------------+ | | | | | | | | | - L2VPN | | - L2VPN | | EVPN | | L3VPN | | - VPWS | | - VPLS | | | | | | | | | | | | | +------------+ +-------------+ +-------------+ +-------------+ =20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Network Element YANG Modules =20 +------------+ +------------+ +-------------+ +------------+ | | | | | | | | | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | | | | | | | | | +------------+ +------------+ +-------------+ +------------+ =20 The text in that section becomes... =20 As previously noted, provides = a classification of YANG data modules. It introduces the term "Network = Service YANG Module" to identify the type of module used to "describe the = configuration, state data, operations and notifications of abstract representations of = services implemented on one or multiple network elements." These modules are used = to construct the=20 service delivery models as described in this document; that = is, they are the=20 modules used on the interface between the Service = Orchestrator or OSS/BSS and the Network Orchestrator as shown in . =20 Figure 1 of can be modified to = make this more clear and to add an additional example of a Network Service YANG = module as shown in . As can be seen, the highest = classification of modules collects those that are used to deliver operations support = and business support. These might be consumed by an Operations Support System (OSS) = or a Business Support System (BSS), and a Service Orchestrator may form part of an = OSS/BSS or may be a separate component. This highest layer in the figure is = divided into the Customer Service Modules that are used to describe services to a = customer as discussed in this document, and other modules that describe further = OSS/BSS function such as billing and SLAs. =20 > - section 6.2 "service delivery and network element model work" >=20 > Some > of these models are classified as service delivery models, while > others have details that are related to specific element > configuration and so are classed as network element models (also > called device models). >=20 > Next to each model description, that would help the audience to = clarify what the correct term is: > customer service model, service delivery model, network service YANG = modules [RFC8199] =20 I agree, but we have made a conscious decision to not do that = *in*this*document*. None of the models in 6.2 is a customer service = model (so that part is easy), but beyond that we could not get coherent = advice from the authors of the listed documents. Most were pretty = certain that their work was "mainly network element model" although some = thought that they were dealing with "network wide configuration" and a = few thought they were "delivering services". =20 While it would be good to get more clarity on this, it looks like we are = trying to retrofit an architecture on an organically evolved set of = modules and perhaps we shouldn't push too hard. What is important in = this document is to get the "Customer Service Model" piece more clearly = explained. =20 > In RFC 8199, we made a distinction between model and YANG modules. = This is why we defined > the terms "Network Service YANG modules" and "Network Element YANG = modules" and not models. > You should follow this convention. After all, from the abstract, this = document focuses on YANG. > Ex: should "model" be replaced by "YANG module"? =20 The definition imported from 7950 by 8199 looks like a reasonable = distinction and we will attempt to apply it here. I hope I am not = importing too much thought from SMI but isn't a "model" built from one = or modules? A model is used to "model" some larger entity or function, = while a module is used to describe a component of an entity or a = granular function. =20 Probably just some cleanup needed through this document. I'll have a go. =20 > - section 6.4 "The MEF architecture". > Do we want to mention that MEF currently focuses on the customer = service model? =20 We could do this, but... Not so happy to use "currently" in an archival document. Also not comfortable about asserting in an IETF document what another = body is doing. And not convince that the MANO architecture is focused in the way you = describe. =20 So I prefer no change for this. =20 > - I'm glad you cleverly avoided the term "intend" =20 That was intentional :-) =20 Thanks, Adrian ------=_NextPart_000_0001_01D33211.987F9FD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey = Benoit,

 

Thanks for the review.

 

> = Figure 3: Network configuration model is a brand new term that is only = mentioned

> in the figure, and = not explained.

 

OMG! = That is a good catch.

 

> = In the same figure, could the "Device Configuration Model" be = renamed to RFC 8199

> = "Network Element YANG module" (this is what you did in figure = 4 anyway)

 

I believe we are separating the "device = configuration model" that is used to talk to an NE, and a = "network configuration model" used to talk to a controller = that is responsible for a set of NEs. I think the correct thing is to = add exactly that statement (i.e., a definition of the terms alongside = figure 3).=C2=A0 Then the = mapping of these terms should show up alongside Figure = 4.

 

But, you know what?

Looking at this made me go back to Figure 1 of = RFC8199 again. And finally I understood it. That is probably a bit = sad.

I had been misled (no blame = associated) by the OSS/BSS box in the figure because that is an entity = not a module. That made me read the horizontal lines as interfaces (over = which the named module types are used) and the boxes as functional units = that consume the modules.

Now, = that=C2=A0 is a *horrible* = misreading, but there we go! And RFC8199 has already been published, so = adding clarification so that fools like me are not confused is not = possible.

 

I believe the intention is to =C2=A0only show modules and not things = that consume or use modules.

So I = wonder whether we should make some clarification in our Figure 4. = Possibly it should look like...

 

=C2=A0=C2=A0=C2=A0=C2=A0 - - - - - - - = - - - - - - - - - - - - - - - - - - - - - - - - = -

=C2=A0=C2=A0=C2=A0=C2=A0 Operations = Support and Business Support YANG Modules

 

=C2=A0=C2=A0=C2=A0=C2=A0 = +-----------------------+=C2=A0=C2=A0=C2=A0=C2=A0 = +-----------------------+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Customer = Service=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Other=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG = Modules=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0 Operations = Support=C2=A0=C2=A0 = |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 and=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +------+=C2=A0=C2=A0 +------+=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Business = Support=C2=A0=C2=A0 = |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG = Modules=C2=A0=C2=A0=C2=A0=C2=A0 = |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | L2SM |=C2=A0=C2=A0 | L3SM |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +------+=C2=A0=C2=A0 +------+=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 = +-----------------------+=C2=A0=C2=A0=C2=A0=C2=A0 = +-----------------------+

 

=C2=A0=C2=A0=C2=A0=C2=A0 - - - - - - - = - - - - - - - - - - - - - - - - - - - - - - - - = -

=C2=A0=C2=A0=C2=A0=C2=A0 Network = Service YANG Modules

 

=C2=A0=C2=A0=C2=A0 +------------+=C2=A0=C2=A0 +-------------+=C2=A0=C2=A0 +-------------+=C2=A0=C2=A0 = +-------------+

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0 - L2VPN=C2=A0=C2=A0 | =C2=A0=C2=A0|=C2=A0=C2=A0 - L2VPN=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 EVPN=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 L3VPN=C2=A0=C2=A0=C2=A0 = |

=C2=A0=C2=A0=C2=A0 |=C2=A0 - VPWS=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 - VPLS=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 +------------+=C2=A0=C2=A0 +-------------+=C2=A0=C2=A0 +-------------+=C2=A0 =C2=A0+-------------+=

 

=C2=A0=C2=A0=C2=A0=C2=A0 - - - - - - - = - - - - - - - - - - - - - - - - - - - - - - - - = -

=C2=A0=C2=A0=C2=A0=C2=A0 Network = Element YANG Modules

 

=C2=A0=C2=A0=C2=A0=C2=A0 = +------------+=C2=A0 = +------------+=C2=A0 = +-------------+=C2=A0 = +------------+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 MPLS=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0 BGP=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | IPv4 / IPv6 |=C2=A0 |=C2=A0 Ethernet=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 = +------------+=C2=A0 = +------------+=C2=A0 = +-------------+=C2=A0 = +------------+

 

The = text in that section becomes...

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <t>As previously noted, <xref = target=3D"RFC8199" /> provides a = classification

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 of YANG data modules.=C2=A0 It introduces the term = "Network Service YANG Module" to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 identify the type of module used to "describe = the configuration, state data,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 operations and notifications of abstract = representations of services implemented

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 on one or multiple network elements."=C2=A0 These modules are used to = construct the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0service delivery models as described in this = document; that is, they are the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0modules used on the interface between the = Service Orchestrator or OSS/BSS and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 the Network Orchestrator as shown in <xref = target=3D"svc_arch" />.</t>

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <t>Figure 1 of <xref = target=3D"RFC8199" /> can be modified to make this more = clear

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 and to add an additional example of a Network = Service YANG module as shown in

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <xref target=3D"modfig" />.=C2=A0 As can be seen, the highest = classification of modules

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 collects those that are used to deliver operations = support and business support.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 These might be consumed by an Operations Support = System (OSS) or a Business Support

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 System (BSS), and a Service Orchestrator may form = part of an OSS/BSS or may be a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 separate component.=C2=A0 This highest layer in the = figure is divided into the Customer

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Service Modules that are used to describe services = to a customer as discussed in

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 this document, and other modules that describe = further OSS/BSS function such as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 billing and SLAs.</t>

 

> - = section 6.2 "service delivery and network element model = work"

> 

>=C2=A0=C2=A0 = Some

>=C2=A0 of these models are classified = as service delivery models, while

>=C2=A0=C2=A0 = others have details that are related to specific = element

>=C2=A0=C2=A0 configuration and so are = classed as network element models (also

>=C2=A0=C2=A0 = called device models).

> 

> Next to each model description, that would = help the audience to clarify what the correct term is:

> customer service model, service delivery = model, network service YANG modules [RFC8199]

 

I = agree, but we have made a conscious decision to not do that = *in*this*document*. None of the models in 6.2 is a customer service = model (so that part is easy), but beyond that we could not get coherent = advice from the authors of the listed documents. Most were pretty = certain that their work was "mainly network element model" = although some thought that they were dealing with "network wide = configuration" and a few thought they were "delivering = services".

 

While = it would be good to get more clarity on this, it looks like we are = trying to retrofit an architecture on an organically evolved set of = modules and perhaps we shouldn't push too hard. What is important in = this document is to get the "Customer Service Model" piece = more clearly explained.

 

> = In RFC 8199, we made a distinction between model and YANG modules. This = is why we defined

> the terms = "Network Service YANG modules" and "Network Element YANG = modules" and not models.

> = You should follow this convention. After all, from the abstract, this = document focuses on YANG.

> Ex: = should "model" be replaced by "YANG = module"?

 

The = definition imported from 7950 by 8199 looks like a reasonable = distinction and we will attempt to apply it here. I hope I am not = importing too much thought from SMI but isn't a "model" built = from one or modules? A model is used to "model" some larger = entity or function, while a module is used to describe a component of an = entity or a granular function.

 

Probably just some cleanup needed through this = document. I'll have a go.

 

> - = section 6.4 "The MEF architecture".

> Do we want to mention that MEF currently = focuses on the customer service model?

 

We = could do this, but...

Not so happy = to use "currently" in an archival document.

Also not comfortable about asserting in an IETF = document what another body is doing.

And not convince that the MANO architecture is = focused in the way you describe.

 

So I = prefer no change for this.

 

> - = I'm glad you cleverly avoided the term = "intend"

 

That = was intentional :-)

 

Thanks,

Adrian

------=_NextPart_000_0001_01D33211.987F9FD0-- From nobody Wed Sep 20 07:11:37 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 B8ADD133053; Wed, 20 Sep 2017 07:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150591669570.29281.8322875631558200037@ietfa.amsl.com> Date: Wed, 20 Sep 2017 07:11:35 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-11.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:11:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-11.txt Pages : 54 Date : 2017-09-20 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-11 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-11 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 Sep 20 07:13: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 360A5133205; Wed, 20 Sep 2017 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Hksl_ar_0pwt; Wed, 20 Sep 2017 07:12:57 -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 C8274132F7D; Wed, 20 Sep 2017 07:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3578; q=dns/txt; s=iport; t=1505916777; x=1507126377; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=aZD3BhMBTGZT669/Mw6AhUQxoEpGrRpUyZ7bGXncqD8=; b=WIoUzbYTZq0qmPgE7dzZDJIZiDrKDkn3ZzgLAAW5vy67tD+Vxso9UBQ7 eVq3X2UqIh/dGWC6LVEg6M1si01WLHZTmybm3MFpBz+oIvOyIa6IDkYuj RjjWrAQhB3A7IZn6/YPdYs4d9mf1mKXgFzO91bdFSwXRSdE4OKq/GZb1n Y=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAABkdsJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1iiB0kEorliaCEgcDGAuESU8ChSMYAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEBAQMBASFLCxALEgYqAgInIg4HDAYCAQGKLxCoAYInixwBAQEBAQEEAQEBA?= =?us-ascii?q?QEBARIPgyuFYoJ9gymEZYJgBYoblnSEO4IhgQGMeoITW4UPg1qHJJU4gTkfOIE?= =?us-ascii?q?NMiEIHBUfKocePjaJGAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="asc'?scan'208";a="655789698" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 14:12:54 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8KECstA003225; Wed, 20 Sep 2017 14:12:54 GMT To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: opsawg@ietf.org References: <150591669570.29281.8322875631558200037@ietfa.amsl.com> From: Eliot Lear Message-ID: <321ab8e8-d43b-1edb-576e-e2eca17ae47c@cisco.com> Date: Wed, 20 Sep 2017 16:12:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150591669570.29281.8322875631558200037@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JR7sb6a8X1t0EcsAO0edjboSW1TCLfB2f" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-11.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:12:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JR7sb6a8X1t0EcsAO0edjboSW1TCLfB2f Content-Type: multipart/mixed; boundary="jJRIfPt53OVmSs9t45fJxtmNslDRIwQ32"; protected-headers="v1" From: Eliot Lear To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: opsawg@ietf.org Message-ID: <321ab8e8-d43b-1edb-576e-e2eca17ae47c@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-11.txt References: <150591669570.29281.8322875631558200037@ietfa.amsl.com> In-Reply-To: <150591669570.29281.8322875631558200037@ietfa.amsl.com> --jJRIfPt53OVmSs9t45fJxtmNslDRIwQ32 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US This one corrects the examples.=C2=A0 mudmaker.org has been updated as we= ll. Eliot On 9/20/17 4:11 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 WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-11.txt > Pages : 54 > Date : 2017-09-20 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL 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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-11 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-11 > > > 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 > --jJRIfPt53OVmSs9t45fJxtmNslDRIwQ32-- --JR7sb6a8X1t0EcsAO0edjboSW1TCLfB2f 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 iQEcBAEBCAAGBQJZwndoAAoJEIe2a0bZ0noziXEIALxkj/z+JuHbip7LUWRPGd0u hYhiUyJHBAxGk+5YPzIvQ3vcao/OVdyuvlXnbdw9e/mgKLprZRT7Ch2CaT1x2M0E 574of328Xsp1g2Y1OwnFMlpCilBhxnmacehZrhkcmWLfrwUHXKVx806Tk1m/7HMn uAC5mg4LfwdiarDXcYDLZYSoq97sIo1B7Ye9f7M9+UKa9dGH3FICUNSFRm8EMr7g xyZwUExjfYdXNU5gnRAaIHlGWwyhjhfWlTSOUjSqx+9oUEzSS3ZXUN/IUUvnPvii fPBXoROZlTLxXF1ZyPOKPafsbOj8/TuL0MHBB3HQF8EHQQ2LjHLpbGpAjx5HEMY= =Pe0p -----END PGP SIGNATURE----- --JR7sb6a8X1t0EcsAO0edjboSW1TCLfB2f-- From nobody Wed Sep 20 07:53:43 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 0F9D013219B for ; Wed, 20 Sep 2017 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 WimWhMbHzdDR for ; Wed, 20 Sep 2017 07:53:40 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7961413214D for ; Wed, 20 Sep 2017 07:53:39 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id r74so2379480wrb.13 for ; Wed, 20 Sep 2017 07:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=56/2z88pIr0I+62R68yl7dNGmYwBCCwyK/yHxggTFrg=; b=iKwgoJyOrQ4SHBckq5/JOOZXA2MWgy/egrT/6q9Bhrc/Zs2MLRlpzFIDKMDL+iWjTe +NJLA6xbVvIki5WDrloaAaXirxFN3eJjDCj/2/nB1lPjdFzot8v/Yifsg5Zzz44vDjGy 6/Cgg5tl7euzaCNTP1Vrps7QbPag3ItTuZA3uq4CvaNNwmuPIYilZ8uSI50WYI1JnHcg X2zlimvfJs+H5dSjI7NacR0fk4FC888c5fwGQUYLTOFBbGyaqXpzhzqn1CIRT4x8jZV3 lHlC/plUPpOiYjQDnoGGbhevDi2RJbLsdsBky15ftWGuxb0h2F2mnzUjMHV7Oh4gXjmM kRIQ== 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; bh=56/2z88pIr0I+62R68yl7dNGmYwBCCwyK/yHxggTFrg=; b=pOubdD8twFOXyeoRRhHomLiKt7+GJFJe+MgfWOfkS7od05VZQVV/LoHYitzIpFHW4J hgVQ7sZzHNh9WO/oR4hFQvZiWt3qRF31d3hrYBX+YN7txBZPdoZFhGyvCIM/F5vxF7LD RGUBMb9cPM5/gYY05K3Jnx4/vo9QAIm5zY5jV/QldkyVTqkpE/sDQQNdXmNYqkAbT2P4 Y3ok3729icLHKzgGOQohpy9KyyDPbCbj5iPSmJfv1vHV91Q+aOgrOU3OqibwiTh36Hyl U81thbrej7UJOBOrW9KeOvwaogLG9cx40lwg+jFsTpS0xz8KtLgVPzOP9MoR9vqbxFci fQlQ== X-Gm-Message-State: AHPjjUjuVkXF6NXNtMShuCeg3/htbALSbvJoW6Osf4B0r8ddMLLSE1F3 YkrB5A8dMuwjUJyn26nmLDQFozw1oQzDZspPSo8= X-Google-Smtp-Source: AOwi7QAZRnwsj98b6F9b0flxLVraegext3/Nx2b1vtF2IvfLJBDr64xYeL/eeKS9QmjapR6APMsOv1kELP2o9sA2WZo= X-Received: by 10.223.136.123 with SMTP id e56mr5098499wre.227.1505919217081; Wed, 20 Sep 2017 07:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.176.149 with HTTP; Wed, 20 Sep 2017 07:52:56 -0700 (PDT) In-Reply-To: <1c215882-9325-91ae-da02-7ed57a0a26a3@cisco.com> References: <1c215882-9325-91ae-da02-7ed57a0a26a3@cisco.com> From: "M. Ranganathan" Date: Wed, 20 Sep 2017 10:52:56 -0400 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a11498702fea3440559a02334" Archived-At: Subject: Re: [OPSAWG] Associating a MUD profile with a specific device 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, 20 Sep 2017 14:53:42 -0000 --001a11498702fea3440559a02334 Content-Type: text/plain; charset="UTF-8" Hi Eliot, I am definitely interested in a MUD controller RFC and would be glad to help in its defintion. It would be nice to see some clear definition on how to interact with a MUD controller - i.e. a YANG model such as this one would make sense to include. Another item to consider in such an RFC would be MUD controller discovery (maybe a DNS SRV record can be defined). Thanks, Ranga On Wed, Sep 20, 2017 at 8:05 AM, Eliot Lear wrote: > Hi Ranga, > I think this makes sense for a MUD controller YANG model, but doesn't do > well in a MUD file itself. We stop short of that in the document, for fear > of boiling the ocean, but I would happily do some follow-up work with you > that would include this, if you're interested. The model *is* structured > so that you can "use" appropriate elements. > > Eliot > > > On 9/20/17 4:22 AM, M. Ranganathan wrote: > > Hi Eliot, > > Attached is a proposed YANG file that defines a device to MUD association. > May I suggest words to the following effect: > > Implementations MAY choose to implement a mapping between a MUD URL > and a device identifier. Such a mapping may be communicated to the MUD > controller, which can then install access control rules based on a > previously retrieved MUD file. The mapping must conform to the YANG > specification below. > > How does this sound? Thanks. > > > > On Tue, Sep 19, 2017 at 5:39 PM, Eliot Lear wrote: > >> Hi Ranga, >> >> The way we did the early code on github was just with FreeRadius and >> leveraging sessions which are indexed precisely by MAC address. And so the >> MUD Controller functionality sits next to FreeRadius through callouts. I >> don't think we want to get that specific in the draft, and there are others >> who don't want to bother with Radius at all in their implementations but >> would just assume use other control functions. And that's fine. In fact, >> you could build the functionality into a DHCP server, which I did in my >> first implementation. So I'm not quite sure what to write. Suggestions >> welcome ;-) >> >> Eliot >> >> ps: thanks for kinking out the example. Chairs, I'll submit an updated >> draft with the example corrected. >> >> On 9/19/17 10:10 PM, M. Ranganathan wrote: >> >> Hello! >> >> MUD profiles are globally identified by the MUD URL. Devices are >> identified by a global Identifier (e.g. MAC address). >> >> In implementing this, I need to associate a specific MUD profile with a >> specific device. >> >> Would the authors consider it within scope to provide some guidance on >> this (for example a simple YANG model that provides the structure of a JSON >> document that can give such a mapping) ? >> >> >> Thanks for reading. >> >> Ranga. >> >> >> -- >> M. Ranganathan >> >> >> _______________________________________________ >> OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg >> >> >> > > > -- > M. Ranganathan > > > -- M. Ranganathan --001a11498702fea3440559a02334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

I am definitely inte= rested in a MUD controller RFC and would be glad to help in its defintion. = It would be nice to see some clear definition on how to interact with a MUD= controller - i.e. a YANG model such as this one would make sense to includ= e. Another item to consider in such an RFC would be MUD controller discover= y (maybe a DNS SRV record can be defined).

Thanks,

Ranga

= On Wed, Sep 20, 2017 at 8:05 AM, Eliot Lear <lear@cisco.com> = wrote:
=20 =20 =20

Hi Ranga,

I think this makes = sense for a MUD controller YANG model, but doesn't do well in a MUD file itself.= =C2=A0 We stop short of that in the document, for fear of boiling the ocean, but I would happily do some follow-up work with you that would include this, if you're interested.=C2=A0 The model *is* structured so that you can "use" appropriate elements.

Eliot


On 9/20/17 4:22 AM, M. Ranganathan wrote:
=20
Hi Eliot,

Attached is a proposed YANG file that defines a device to MUD association. May I suggest words to the following effect:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementations MAY choose to impl= ement a mapping between a MUD URL and a device identifier. Such a mapping may be communicated to the MUD controller, which can then install access control rules based on a previously retrieved MUD file. The mapping must conform to the YANG specification below.

How does this sound? Thanks.



On Tue, Sep 19, 2017 at 5:39 PM, Eliot Lear <lear@cisco.com> wrote:

Hi Ranga,

The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.=C2=A0 And so the MUD Controller functionality sits next to FreeRadius through callouts.=C2= =A0 I don't think we want to get that specific in the draft= , and there are others who don't want to bother with Radius at all in their implementations but would just assume use other control functions.=C2=A0 And that's fi= ne.=C2=A0 In fact, you could build the functionality into a DHCP server, which I did in my first implementation.=C2=A0 So I&= #39;m not quite sure what to write.=C2=A0 Suggestions welcome ;-)=

Eliot

ps: thanks for kinking out the example.=C2=A0 Chairs, I= 9;ll submit an updated draft with the example corrected.


On 9/19/17 10:10 PM, M. Ranganathan wrote:
Hello!

MUD profiles are globally identified by the MUD URL. Devices are identified by a global Identifier (e.g. MAC address).

In implementing this, I need to associate a specific MUD profile with a specific device.

Would the authors consider it within scope to provide some guidance on this (for example a simple YANG model that provides the structure of a JSON document that can give such a mapping) ?


Thanks for reading.

Ranga.


--
M. Ranganathan


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




--
M. Ranganathan




--
M. Ranganathan
--001a11498702fea3440559a02334-- From nobody Wed Sep 20 08:07:09 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 325011331C2; Wed, 20 Sep 2017 08:07:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: opsawg@ietf.org, ietf@ietf.org, draft-ietf-opsawg-service-model-explained.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150592002817.29335.8762036344417909160@ietfa.amsl.com> Date: Wed, 20 Sep 2017 08:07:08 -0700 Archived-At: Subject: [OPSAWG] Genart last call review of draft-ietf-opsawg-service-model-explained-03 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: Wed, 20 Sep 2017 15:07:08 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-opsawg-service-model-explained-03 Reviewer: Robert Sparks Review Date: 2017-09-20 IETF LC End Date: 2017-09-20 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as an Informational RFC This is well written. Hopefully it will help avoid, or at least shorten, rehash of arguments about choosing the right level of abstraction for service models. I don't have text to suggest, but please look at the first bullet of section 5. The explanation here was less helpful than the other bullets. Demonstrating the confusion due to the reuse of the word "service" doesn't help clarify the confusion. I wonder if there's more conversation that hasn't been captured that this paragraph is alluding to. (nit) I also suggest raising the level of abstraction in the security consideration section where it currently lists authorization, authentication, and encryption by speaking initially to what, and calling the how out as a detail. From nobody Wed Sep 20 17:15: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 B337613219C for ; Wed, 20 Sep 2017 17:15:22 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jNBcoYXov6pi for ; Wed, 20 Sep 2017 17:15:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E71A12ECEC for ; Wed, 20 Sep 2017 17:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=609; q=dns/txt; s=iport; t=1505952921; x=1507162521; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=TMJKQjKL4mRjQ6II5RDVN2Mko+COz2Is3ponMrA3T7U=; b=bmRbDGxYTr0ldwn8TxdfnDxnCq1i8gMYM/ayMWCY45IWt2twiOBwbSiP 0FLLgvByxiF531mCWWSF2G+YKO5kRYW2DtO64FbGrYekwglHE2ZhpkZlQ kf7qwlqF7T4PtmCpbfQizIlwI/IiNWan508np3xle8ec5U/A+4aIwULhr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAQA6BMNZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkboQcmhiBSQmWV4IECiOJf1cBAgEBAQEBAmsdC4VCgQsCJgJ?= =?us-ascii?q?fDQgBAYovEKcjgieKfwEBAQEGAQEBAR8FgQ6CHYICgVGBZCsLhzoBEgGDMoJgB?= =?us-ascii?q?aETh12MeoF7GIVqg1okhwCVOoE5V4ECC1MkFUmHOCSHJYIzAQEB?= X-IronPort-AV: E=Sophos;i="5.42,422,1500940800"; d="scan'208";a="6455498" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2017 00:15:20 +0000 Received: from [10.155.68.125] (dhcp-10-155-68-125.cisco.com [10.155.68.125]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v8L0FKRl010994 for ; Thu, 21 Sep 2017 00:15:20 GMT To: "opsawg@ietf.org" From: Joe Clarke Organization: Cisco Message-ID: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> Date: Wed, 20 Sep 2017 20:15:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 21 Sep 2017 00:15:23 -0000 While this draft was already put through WGLC in March, there have been a number of changes to it that should be reviewed. This document has had early reviews by SEC-DIR, IOT-DIR, and GEN. The chairs are particularly looking for a review of those items that have changed since the -05 review (these are documented in the draft's Appendix A. This email starts a two-week period for last call comments for https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ . Please read this draft and provide any comments or questions to the list on or before October 4, 2017. Joe for the opsawg chairs From nobody Thu Sep 21 15:18: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 BC5CF133224; Thu, 21 Sep 2017 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 BhTB7m163pOe; Thu, 21 Sep 2017 15:17:56 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 4ECFE1332D4; Thu, 21 Sep 2017 15:16:33 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id d8so4261925pgt.4; Thu, 21 Sep 2017 15:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QxEwYw8ek7yyp0USLJzuXXsCRuWe/FOY3l32TtZ2WSA=; b=C8wmzpxuaNC1D6c9ChPSeMadCmAC7Z3lQlrDX4Kb1F8NBTYNg6BY21kpDmooc6NlcJ 3KSJ+eLihIy+9EH694ABuQvZfrqFizJx8t9sNZ5WeUFtFVFToZq4W7glc60tYbYL3gnZ +/H8Lir7u0iLAkx4w7OnxWlP2jo43aS4mMOHQDQrQD1eeBQQoKuz1D3MAoiO4ZjaErtz xIPjckehs08V3KBPHV4LcupK8fhkpmN3bxkXxS8MTYzIbZPTMQNOgoAo1R0lstP7qLHU WnjaptEY0GRrhY8PA3vR5Uyw5hNX/Zb8HPyCeaSkOYubxGRARg0EydnQyJXWFPjVtyRx Bxlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QxEwYw8ek7yyp0USLJzuXXsCRuWe/FOY3l32TtZ2WSA=; b=dxWDEP41LS/tyIRYKu5UMyD/kDbRV4nrBosvN1q8+8sO+2maN0nSTbJ1jhzZ5dvLwG gRIL0UU5cqjGEIsxcUp8SOxKOe2GhMHKJttUiO8rWgWUQmw0Ofv7xHeK+xT7T3TApJjy oUvd2R2z01aU/nesnmAksvVFeaWbLVBtoM0FYA8upiO5KvPDL9u55GTp2nbB0FtJSB+l d31jR3M00Xd7luv2E1Xe1SY75feoYymU+YkdhFA/GlUerkyTPCKhSGh2N+CJ2JZvRbgy DsTBKGhu0CHEZFR2XSqhDznWg/M77j6ABWVvTirQKbjStz7LA+tbI8X+wTlJIge7E3XL nSaA== X-Gm-Message-State: AHPjjUgS39Elx5X78Az38N92DxnPV5intODeT2BEmAOgRU41+M+SqooN Kd98DgE/FzRTJs2+ceV1V7I= X-Google-Smtp-Source: AOwi7QAROYRW1YHpt7H23b3Qg8vFRoVmnSPMcmZYPSMq65H1FDaJqXP7L4O612PZE38foRCo6otV+A== X-Received: by 10.99.181.23 with SMTP id y23mr7168889pge.189.1506032192925; Thu, 21 Sep 2017 15:16:32 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1254:d0c:e1af:5a13:d5a5? ([2001:420:30d:1254:d0c:e1af:5a13:d5a5]) by smtp.gmail.com with ESMTPSA id d69sm3880687pfl.50.2017.09.21.15.16.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Sep 2017 15:16:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F5DF28F8-F99B-4040-B55F-AC9A40459C3B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <5eeb51f5-56c1-5f82-6c33-04d9cf15608e@cisco.com> Date: Thu, 21 Sep 2017 15:17:32 -0700 Cc: draft-ietf-opsawg-mud@ietf.org, draft-ietf-netmod-acl-model@ietf.org, "opsawg@ietf.org" , "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" , Sonal Agarwal Message-Id: <74A7C90D-6403-488A-827B-E2A4BED72166@gmail.com> References: <5eeb51f5-56c1-5f82-6c33-04d9cf15608e@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud: YANG validation 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, 21 Sep 2017 22:17:59 -0000 --Apple-Mail=_F5DF28F8-F99B-4040-B55F-AC9A40459C3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have fixed these warning. Eliot, I am including the updated ACL = models. Can you verify? These changes will be uploaded as part of the next update that Sonal is = planning to post on Oct. 2. > On Sep 13, 2017, at 2:15 AM, Benoit Claise wrote: >=20 > Dear draft-ietf-opsawg-mud authors, >=20 > A new version of the draft-ietf-netmod-acl-model has been posted, and = it now passes validation. It failed previously with: > /ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' = expression will fail: the node 'upper-port' from module = 'ietf-access-control-list' (in node 'operation' from = 'ietf-access-control-list') is not found > ./ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' = expression will fail: the node 'lower-port' from module = 'ietf-access-control-list' (in node 'operation' from = 'ietf-access-control-list') is not found > ... >=20 > As a consequence, this error is not reported any longer in the = draft-ietf-opsawg-mud YANG models. > However, there are still some errors: > warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type =3D= 'eth-acl'). > warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = =3D 'ipv4-acl'). > warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = =3D 'ipv6-acl'). > warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv4-acl'). > warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv6-acl'). > warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv4-ipv6-acl'). > warn: Value "any-acl" is not valid for the node "acl-type" (acl-type =3D= 'any-acl'). >=20 > warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type =3D= 'eth-acl'). > warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = =3D 'ipv4-acl'). > warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = =3D 'ipv6-acl'). > warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv4-acl'). > warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv6-acl'). > warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node = "acl-type" (acl-type =3D 'mixed-l2-l3-ipv4-ipv6-acl'). > warn: Value "any-acl" is not valid for the node "acl-type" (acl-type =3D= 'any-acl'). > See http://www.claise.be/IETFYANGPageCompilation.html = >=20 > Please correct those mistakes and post a new version. >=20 > Also, make sure both revisions match (for all your YANG modules in the = draft) and are up to date > file "ietf-acldns@2016-09-07.yang" = > module ietf-acldns { > yang-version 1.1; > namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; > prefix "ietf-acldns"; >=20 > revision "2016-07-20" { > description "Base version of dnsname extension of ACL model"; > reference "RFC XXXX: Manufacturer Usage Description > Specification"; > } >=20 > While this revision mismatch seems like a minor thing, this is a pain = from a tooling point of view (as we need to index YANG modules per name, = revision, organization) > We discovered that version 8 contains a newer revision than the = version 9. That confused our tooling. > version 8: > file "ietf-acldns@2016-07-20.yang" = >=20 > ... >=20 > revision "2017-07-03" { > description "Clone across IP ACL types."; > reference "RFC XXXX: Manufacturer Usage Description > Specification"; > } >=20 > =20 > version 9:=20 > file "ietf-acldns@2016-09-07.yang" = >=20 > ... >=20 > revision "2016-07-20" { > description "Base version of dnsname extension of ACL model"; > reference "RFC XXXX: Manufacturer Usage Description > Specification"; > } > All these metadata are important.=20 > We're working on: = https://www.yangcatalog.org/yang-search/module_details.php?module=3Dietf-a= cldns = > Also, is your YANG module NMDA compliant? It reports tree-type as = "unclassified".=20 >=20 > Regards, Benoit Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F5DF28F8-F99B-4040-B55F-AC9A40459C3B Content-Type: multipart/mixed; boundary="Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC" --Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I have fixed these warning. Eliot, I am including the updated ACL models. Can you verify?

These changes will be uploaded as part of the next update that Sonal is planning to post on Oct. 2.

--Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Disposition: attachment; filename="ietf-access-control-list@2017-09-21.yang" Content-Type: application/octet-stream; name="ietf-access-control-list@2017-09-21.yang" Content-Transfer-Encoding: 7bit module ietf-access-control-list { namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; prefix acl; yang-version 1.1; import ietf-yang-types { prefix yang; } import ietf-packet-fields { prefix packet-fields; } import ietf-interfaces { prefix if; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: http://tools.ietf.org/wg/netmod/ WG List: netmod@ietf.org Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Lisa Huang lyihuang16@gmail.com Editor: Sonal Agarwal agarwaso@cisco.com Editor: Dana Blair dblair@cisco.com"; description "This YANG module defines a component that describe the configuration of Access Control Lists (ACLs). Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2017-09-21 { description "Added feature and identity statements for different types of rule matches. Split the matching rules based on the feature statement and added a must statement within each container."; reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Identities */ identity acl-base { description "Base Access Control List type for all Access Control List type identifiers."; } identity ipv4-acl { base acl:acl-base; description "ACL that primarily matches on fields from the IPv4 header (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv4-acl does not contain matches on fields in the ethernet header or the IPv6 header."; } identity ipv6-acl { base acl:acl-base; description "ACL that primarily matches on fields from the IPv6 header (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv6-acl does not contain matches on fields in the ethernet header or the IPv4 header."; } identity eth-acl { base acl:acl-base; description "ACL that primarily matches on fields in the ethernet header, like 10/100/1000baseT or WiFi Access Control List. An acl of type eth-acl does not contain matches on fields in the IPv4 header, IPv6 header or layer 4 headers."; } identity mixed-l2-l3-ipv4-acl { base "acl:acl-base"; description "ACL that contains a mix of entries that primarily match on fields in ethernet headers, entries that primarily match on IPv4 headers. Matching on layer 4 header fields may also exist in the list."; } identity mixed-l2-l3-ipv6-acl { base "acl:acl-base"; description "ACL that contains a mix of entries that primarily match on fields in ethernet headers, entries that primarily match on fields in IPv6 headers. Matching on layer 4 header fields may also exist in the list."; } identity mixed-l2-l3-ipv4-ipv6-acl { base "acl:acl-base"; description "ACL that contains a mix of entries that primarily match on fields in ethernet headers, entries that primarily match on fields in IPv4 headers, and entries that primarily match on fields in IPv6 headers. Matching on layer 4 header fields may also exist in the list."; } identity any-acl { base "acl:acl-base"; description "ACL that can contain any pattern to match upon"; } /* * Features */ feature l2-acl { description "Layer 2 ACL supported"; } feature ipv4-acl { description "Layer 3 IPv4 ACL supported"; } feature ipv6-acl { description "Layer 3 IPv6 ACL supported"; } feature mixed-ipv4-acl { description "Layer 2 and Layer 3 IPv4 ACL supported"; } feature mixed-ipv6-acl { description "Layer 2 and Layer 3 IPv6 ACL supported"; } feature l2-l3-ipv4-ipv6-acl { description "Layer 2 and any Layer 3 ACL supported."; } feature tcp-acl { description "TCP header ACL supported."; } feature udp-acl { description "UDP header ACL supported."; } feature icmp-acl { description "ICMP header ACL supported."; } feature any-acl { description "ACL for any pattern."; } /* * Typedefs */ typedef acl-type { type identityref { base acl-base; } description "This type is used to refer to an Access Control List (ACL) type"; } typedef acl-ref { type leafref { path "/access-lists/acl/acl-name"; } description "This type is used by data models that need to reference an Access Control List"; } /* * Configuration data nodes */ container access-lists { description "This is a top level container for Access Control Lists. It can have one or more Access Control Lists."; list acl { key "acl-type acl-name"; description "An Access Control List(ACL) is an ordered list of Access List Entries (ACE). Each Access Control Entry has a list of match criteria and a list of actions. Since there are several kinds of Access Control Lists implemented with different attributes for different vendors, this model accommodates customizing Access Control Lists for each kind and for each vendor."; leaf acl-name { type string; description "The name of access-list. A device MAY restrict the length and value of this name, possibly space and special characters are not allowed."; } leaf acl-type { type acl-type; description "Type of access control list. Indicates the primary intended type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) used in the list instance."; } container acl-oper-data { config false; description "Overall Access Control List operational data"; } container aces { description "The access-list-entries container contains a list of access-list-entries(ACE)."; list ace { key "rule-name"; ordered-by user; description "List of access list entries(ACE)"; leaf rule-name { type string; description "A unique name identifying this Access List Entry(ACE)."; } container matches { description "The rules in this set determine what fields will be matched upon before any action is taken on them. The rules are selected based on the feature set defined by the server and the acl-type defined."; container l2-acl { if-feature l2-acl; must "derived-from(../../../../acl-type, 'acl:eth-acl')"; uses packet-fields:acl-eth-header-fields; description "Rule set for L2 ACL."; } container ipv4-acl { if-feature ipv4-acl; must "derived-from(../../../../acl-type, " + "'acl:ipv4-acl')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; description "Rule set that supports IPv4 headers."; } container ipv6-acl { if-feature ipv6-acl; must "derived-from(../../../../acl-type, " + "'acl:ipv6-acl')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields; description "Rule set that supports IPv6 headers."; } container l2-l3-ipv4-acl { if-feature mixed-ipv4-acl; must "derived-from(../../../../acl-type, " + "'acl:mixed-l2-l3-ipv4-acl')"; uses packet-fields:acl-eth-header-fields; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; description "Rule set that is a logical AND (&&) of l2 and ipv4 headers."; } container l2-l3-ipv6-acl { if-feature mixed-ipv6-acl; must "derived-from(../../../../acl-type, " + "'acl:mixed-l2-l3-ipv6-acl')"; uses packet-fields:acl-eth-header-fields; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields; description "Rule set that is a logical AND (&&) of L2 && IPv6 headers."; } container l2-l3-ipv4-ipv6-acl { if-feature l2-l3-ipv4-ipv6-acl; must "derived-from(../../../../acl-type, " + "'acl:mixed-l2-l3-ipv4-ipv6-acl')"; uses packet-fields:acl-eth-header-fields; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; uses packet-fields:acl-ipv6-header-fields; description "Rule set that is a logical AND (&&) of L2 && IPv4 && IPv6 headers."; } container tcp-acl { if-feature tcp-acl; uses packet-fields:acl-tcp-header-fields; description "Rule set that defines TCP headers."; } container udp-acl { if-feature udp-acl; uses packet-fields:acl-udp-header-fields; description "Rule set that defines UDP headers."; } container icmp-acl { if-feature icmp-acl; uses packet-fields:acl-icmp-header-fields; description "Rule set that defines ICMP headers."; } container any-acl { if-feature any-acl; must "derived-from(../../../../acl-type, 'acl:any-acl')"; presence "Matches any"; description "Rule set that allows for a any ACL."; } leaf interface { type if:interface-ref; description "Interface name that is specified to match upon."; } } container actions { description "Definitions of action criteria for this Access List Entry."; choice packet-handling { default "deny"; description "Packet handling action."; case deny { leaf deny { type empty; description "Deny action."; } } case permit { leaf permit { type empty; description "Permit action."; } } } leaf logging { type boolean; default "false"; description "Log the rule on which the match occurred. Setting the value to true enables logging, whereas setting the value to false disables it."; } } /* * Operational state data nodes */ container ace-oper-data { config false; description "Operational data for this Access List Entry."; leaf match-counter { type yang:counter64; description "Number of matches for this Access List Entry"; } } } } } } } --Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Disposition: attachment; filename="ietf-packet-fields@2017-09-21.yang" Content-Type: application/octet-stream; name="ietf-packet-fields@2017-09-21.yang" Content-Transfer-Encoding: 7bit module ietf-packet-fields { namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; prefix packet-fields; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } import ietf-ethertypes { prefix eth; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: http://tools.ietf.org/wg/netmod/ WG List: netmod@ietf.org Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Lisa Huang lyihuang16@gmail.com Editor: Sonal Agarwal agarwaso@cisco.com Editor: Dana Blair dblair@cisco.com"; description "This YANG module defines groupings that are used by ietf-access-control-list YANG module. Their usage is not limited to ietf-access-control-list and can be used anywhere as applicable. Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2017-09-21 { description "Added header fields for TCP, UDP, and ICMP."; reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Typedefs */ typedef operator { type enumeration { enum lt { description "Less than."; } enum gt { description "Greater than."; } enum eq { description "Equal to."; } enum neq { description "Not equal to."; } } description "The source and destination port range definitions can be further qualified using an operator. An operator is needed only if lower-port is specified and upper-port is not specified. The operator therefore further qualifies lower-port only."; } grouping acl-transport-header-fields { description "Transport header fields"; container source-port-range { presence "Enables setting source port range"; description "Inclusive range representing source ports to be used. When only lower-port is present, it represents a single port and eq operator is assumed to be default. When both lower-port and upper-port are specified, it implies a range inclusive of both values. If no port is specified, 'any' (wildcard) is assumed."; leaf lower-port { type inet:port-number; mandatory true; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must ". >= ../lower-port" { error-message "The upper-port must be greater than or equal to lower-port"; } description "Upper boundary for port. If it exists, the upper port must be greater or equal to lower-port."; } leaf operation { type operator; must "(../lower-port and not(../upper-port))" { error-message "If lower-port is specified, and an operator is also specified, then upper-port should not be specified."; description "If lower-port is specified, and an operator is also specified, then upper-port should not be specified."; } default eq; description "Operator to be applied on the lower-port."; } } container destination-port-range { presence "Enables setting destination port range"; description "Inclusive range representing destination ports to be used. When only lower-port is present, it represents a single port and eq operator is assumed to be default. When both lower-port and upper-port are specified, it implies a range inclusive of both values. If no port is specified, 'any' (wildcard) is assumed. "; leaf lower-port { type inet:port-number; mandatory true; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must ". >= ../lower-port" { error-message "The upper-port must be greater than or equal to lower-port"; } description "Upper boundary for port. If existing, the upper port must be greater or equal to lower-port"; } leaf operations { type operator; must "(../lower-port and not(../upper-port))" { error-message "If lower-port is specified, and an operator is also specified, then upper-port should not be specified."; description "If lower-port is specified, and an operator is also specified, then upper-port should not be specified."; } default eq; description "Operator to be applied on the lower-port."; } } } grouping acl-ip-header-fields { description "IP header fields common to ipv4 and ipv6"; reference "RFC 791."; leaf dscp { type inet:dscp; description "Differentiated Services Code Point."; reference "RFC 2474: Definition of Differentiated services field (DS field) in the IPv4 and IPv6 headers."; } leaf ecn { type uint8 { range 0..3; } description "Explicit Congestion Notification."; reference "RFC 3168."; } leaf length { type uint16; description "In IPv4 header field, this field is known as the Total Length. Total Length is the length of the datagram, measured in octets, including internet header and data. In IPv6 header field, this field is known as the Payload Length, the length of the IPv6 payload, i.e. the rest of the packet following the IPv6 header, in octets."; reference "RFC 719, RFC 2460"; } leaf ttl { type uint8; description "This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. In IPv6, this field is known as the Hop Limit."; reference "RFC 719, RFC 2460"; } leaf protocol { type uint8; description "Internet Protocol number."; } uses acl-transport-header-fields; } grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; leaf ihl { type uint8 { range "5..60"; } description "An IPv4 header field, the Internet Header Length (IHL) is the length of the internet header in 32 bit words, and thus points to the beginning of the data. Note that the minimum value for a correct header is 5."; } leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } leaf identification { type uint16; description "An identifying value assigned by the sender to aid in assembling the fragments of a datagram."; } leaf destination-ipv4-network { type inet:ipv4-prefix; description "Destination IPv4 address prefix."; } leaf source-ipv4-network { type inet:ipv4-prefix; description "Source IPv4 address prefix."; } } grouping acl-ipv6-header-fields { description "Fields in IPv6 header"; leaf next-header { type uint8; description "Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field."; reference "RFC 2460"; } leaf destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } leaf source-ipv6-network { type inet:ipv6-prefix; description "Source IPv6 address prefix."; } leaf flow-label { type inet:ipv6-flow-label; description "IPv6 Flow label."; } reference "RFC 4291: IP Version 6 Addressing Architecture RFC 4007: IPv6 Scoped Address Architecture RFC 5952: A Recommendation for IPv6 Address Text Representation"; } grouping acl-eth-header-fields { description "Fields in Ethernet header."; leaf destination-mac-address { type yang:mac-address; description "Destination IEEE 802 MAC address."; } leaf destination-mac-address-mask { type yang:mac-address; description "Destination IEEE 802 MAC address mask."; } leaf source-mac-address { type yang:mac-address; description "Source IEEE 802 MAC address."; } leaf source-mac-address-mask { type yang:mac-address; description "Source IEEE 802 MAC address mask."; } leaf ethertype { type eth:ethertype; description "The Ethernet Type (or Length) value represented in the canonical order defined by IEEE 802. The canonical representation uses lowercase characters."; reference "IEEE 802-2014 Clause 9.2"; } reference "IEEE 802: IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture."; } grouping acl-tcp-header-fields { description "Collection of TCP header fields that can be used to setup a match filter."; leaf sequence-number { type uint32; description "Sequence number that appears in the packet."; } leaf acknowledgement-number { type uint32; description "The acknowledgement number that appears in the packet."; } leaf data-offset { type uint8 { range "5..15"; } description "Specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header."; } leaf reserved { type uint8; description "Reserved for future use."; } leaf flags { type bits { bit ns { position 0; description "ECN-nonce concealment protection"; reference "RFC 3540)."; } bit cwr { position 1; description "Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism."; reference "RFC 3168"; } bit ece { position 2; description "ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates: If the SYN flag is set (1), that the TCP peer is ECN capable. If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender."; } bit urg { position 3; description "Indicates that the Urgent pointer field is significant."; } bit ack { position 4; description "Indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set."; } bit psh { position 5; description "Push function. Asks to push the buffered data to the receiving application."; } bit rst { position 6; description "Reset the connection."; } bit syn { position 7; description "Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags and fields change meaning based on this flag, and some are only valid for when it is set, and others when it is clear."; } bit fin { position 8; description "Last package from sender."; } } description "Also known as Control Bits. Contains 9 1-bit flags."; } leaf window-size { type uint16; description "The size of the receive window, which specifies the number of window size units (by default, bytes) (beyond the segment identified by the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive."; } leaf urgent-pointer { type uint16; description "This field is an offset from the sequence number indicating the last urgent data byte."; } leaf options { type uint32; description "The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable."; } } grouping acl-udp-header-fields { description "Collection of UDP header fields that can be used to setup a match filter."; leaf length { type uint16; description "A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes because that is the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. However the actual limit for the data length, which is imposed by the underlying IPv4 protocol, is 65,507 bytes (65,535 minus 8 byte UDP header minus 20 byte IP header). In IPv6 jumbograms it is possible to have UDP packets of size greater than 65,535 bytes. RFC 2675 specifies that the length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535."; } } grouping acl-icmp-header-fields { description "Collection of ICMP header fields that can be used to setup a match filter."; leaf type { type uint8; description "Also known as Control messages."; reference "RFC 792"; } leaf code { type uint8; description "ICMP subtype. Also known as Control messages."; } leaf rest-of-header { type uint32; description "Four-bytes field, contents vary based on the ICMP type and code."; } } } --Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Disposition: attachment; filename="ietf-ethertypes@2017-09-21.yang" Content-Type: application/octet-stream; name="ietf-ethertypes@2017-09-21.yang" Content-Transfer-Encoding: 7bit module ietf-ethertypes { namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; prefix ie; organization "IETF NETMOD (NETCONF Data Modeling Language)"; contact "WG Web: WG List: Editor: Mahesh Jethanandani "; description "This module contains the common definitions for the Ethertype used by different modules. It is a placeholder module, till such time that IEEE starts a project to define these Ethertypes and publishes a standard. At that time this module can be deprecated."; revision 2017-09-21 { description "Initial revision."; reference "RFC XXXX: IETF Ethertype YANG Data Module."; } typedef ethertype { type union { type uint16; type enumeration { enum ipv4 { value 2048; description "Internet Protocol version 4 (IPv4) with a hex value of 0x0800."; reference "RFC 791, Internet Protocol."; } enum arp { value 2054; description "Address Resolution Protocol (ARP) with a hex value of 0x0806."; reference "RFC 826 An Ethernet Address Resolution Protocol."; } enum wlan { value 2114; description "Wake-on-LAN. Hex value of 0x0842."; } enum trill { value 8947; description "Transparent Interconnection of Lots of Links. Hex value of 0x22F3."; reference "RFC 6325 Routing Bridges (RBridges): Base Protocol Specification."; } enum srp { value 8938; description "Stream Reservation Protocol. Hex value of 0x22EA."; reference "IEEE 801.1Q-2011."; } enum decnet { value 24579; description "DECnet Phase IV. Hex value of 0x6003."; } enum rarp { value 32821; description "Reverse Address Resolution Protocol. Hex value 0x8035."; reference "RFC 903. A Reverse Address Resolution Protocol."; } enum appletalk { value 32923; description "Appletalk (Ethertalk). Hex value 0x809B."; } enum aarp { value 33011; description "Appletalk Address Resolution Protocol. Hex value of 0x80F3."; } enum vlan { value 33024; description "VLAN-tagged frame (802.1Q) and Shortest Path Bridging IEEE 802.1aq with NNI compatibility. Hex value 0x8100."; reference "802.1Q."; } enum ipx { value 33079; description "Internetwork Packet Exchange (IPX). Hex value of 0x8137."; } enum qnx { value 33284; description "QNX Qnet. Hex value of 0x8204."; } enum ipv6 { value 34525; description "Internet Protocol Version 6 (IPv6). Hex value of 0x86DD."; reference "RFC 8200, 8201."; } enum efc { value 34824; description "Ethernet flow control using pause frames. Hex value of 0x8808"; reference "IEEE Std. 802.1Qbb."; } enum esp { value 34825; description "Ethernet Slow Protocol. Hex value of 0x8809."; reference "IEEE Std. 802.3-2015"; } enum cobranet { value 34841; description "CobraNet. Hex value of 0x"; } enum mpls-unicast { value 34887; description "MultiProtocol Label Switch (MPLS) unicast traffic. Hex value of 0x8847."; reference "RFC 3031."; } enum mpls-multicast { value 34888; description "MultiProtocol Label Switch (MPLS) multicast traffic. Hex value of 0x8848."; reference "RFC 3031."; } enum pppoe-discovery { value 34915; description "Point-to-Point Protocol over Ethernet. Used during the discovery process. Hex value of 0x8863."; reference "RFC 2516."; } enum pppoe-session { value 34916; description "Point-to-Point Protocol over Ethernet. Used during session stage. Hex value of 0x8864."; reference "RFC 2516."; } enum intel-ans { value 34925; description "Intel Advanced Networking Services. Hex value of 0x886D."; } enum jumbo-frames { value 34928; description "Jumbo frames or Ethernet frames with more than 1500 bytes of payload, upto 9000 bytes."; } enum homeplug { value 34939; description "Family name for the various power line communications. Hex value of 0x887B."; } enum eap { value 34958; description "Ethernet Access Protocol (EAP) over LAN. Hex value of 0x888E."; reference "IEEE 802.1X"; } enum profinet { value 34962; description "PROcess FIeld Net (PROFINET). Hex value of 0x8892."; } enum hyperscsi { value 34970; description "SCSI over Ethernet. Hex value of 0x889A"; } enum aoe { value 34978; description "Advanced Technology Advancement (ATA) over Ethernet. Hex value of 0x88A2."; } enum ethercat { value 34980; description "Ethernet for Control Automation Technology (EtherCAT). Hex value of 0x88A4."; } enum provider-bridging { value 34984; description "Provider Bridging (802.1ad) and Shortest Path Bridging (801.1aq). Hex value of 0x88A8."; reference "IEEE 802.1ad, IEEE 802.1aq)."; } enum ethernet-powerlink { value 34987; description "Ethernet Powerlink. Hex value of 0x88AB."; } enum goose { value 35000; description "Generic Object Oriented Substation Event (GOOSE). Hex value of 0x88B8."; reference "IEC/ISO 8802-2 and 8802-3."; } enum gse { value 35001; description "Generic Substation Events. Hex value of 88B9."; reference "IEC 61850."; } enum sv { value 35002; description "Sampled Value Transmission. Hex value of 0x88BA."; reference "IEC 61850."; } enum lldp { value 35020; description "Link Layer Discovery Protocol (LLDP). Hex value of 0x88CC."; reference "IEEE 802.1AB."; } enum sercos { value 35021; description "Sercos Interface. Hex value of 0x88CD."; } enum wsmp { value 35036; description "WAVE Short Message Protocl (WSMP). Hex value of 0x88DC."; } enum homeplug-av-mme { value 35041; description "HomePlug AV MME. Hex value of 88E1."; } enum mrp { value 35043; description "Media Redundancy Protocol (MRP). Hex value of 0x88E3."; reference "IEC62439-2."; } enum macsec { value 35045; description "MAC Security. Hex value of 0x88E5."; reference "IEEE 802.1AE."; } enum pbb { value 35047; description "Provider Backbone Bridges (PBB). Hex value of 0x88E7."; reference "IEEE 802.1ah."; } enum cfm { value 35074; description "Connectivity Fault Management (CFM). Hex value of 0x8902."; reference "IEEE 802.1ag."; } enum fcoe { value 35078; description "Fiber Channel over Ethernet (FCoE). Hex value of 0x8906."; reference "T11 FC-BB-5."; } enum fcoe-ip { value 35092; description "FCoE Initialization Protocol. Hex value of 0x8914."; } enum roce { value 35093; description "RDMA over Converged Ethernet (RoCE). Hex value of 0x8915."; } enum tte { value 35101; description "TTEthernet Protocol Control Frame (TTE). Hex value of 0x891D."; reference "SAE AS6802."; } enum hsr { value 35119; description "High-availability Seamless Redundancy (HSR). Hex value of 0x892F."; reference "IEC 62439-3:2016."; } enum ctp { value 36864; description "Ethernet Configuration Test Protocol (CTP). Hex value of 0x9000."; } enum vlan-double-tagged { value 37120; description "VLAN-tagged frame with double tagging. Hex value of 0x9100."; } } } description "The uint16 type placeholder type is defined to enable users to manage their own ethertypes not covered by the module. Otherwise the module contains enum definitions for the more commonly used ethertypes."; } } --Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii


On Sep 13, 2017, at 2:15 AM, Benoit Claise <bclaise@cisco.com> wrote:

Dear draft-ietf-opsawg-mud authors,

A new version of the draft-ietf-netmod-acl-model has been posted, and it now passes validation. It failed previously with:
    /ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'upper-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found
./ietf-packet-fields@2017-09-01.yang:118: warning: The 'must' expression will fail: the node 'lower-port' from module 'ietf-access-control-list' (in node 'operation' from 'ietf-access-control-list') is not found
    ...

As a consequence, this error is not reported any longer in the draft-ietf-opsawg-mud YANG models.
However, there are still some errors:
warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl').
warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl').
warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl').
warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl').
warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl').

warn: Value "eth-acl" is not valid for the node "acl-type" (acl-type = 'eth-acl').
warn: Value "ipv4-acl" is not valid for the node "acl-type" (acl-type = 'ipv4-acl').
warn: Value "ipv6-acl" is not valid for the node "acl-type" (acl-type = 'ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-acl').
warn: Value "mixed-l2-l3-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv6-acl').
warn: Value "mixed-l2-l3-ipv4-ipv6-acl" is not valid for the node "acl-type" (acl-type = 'mixed-l2-l3-ipv4-ipv6-acl').
warn: Value "any-acl" is not valid for the node "acl-type" (acl-type = 'any-acl').
See http://www.claise.be/IETFYANGPageCompilation.html

Please correct those mistakes and post a new version.

Also, make sure both revisions match (for all your YANG modules in the draft) and are up to date
   <CODE BEGINS>file "ietf-acldns@2016-09-07.yang"
   module ietf-acldns {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
     prefix "ietf-acldns";

    revision "2016-07-20" {
       description "Base version of dnsname extension of ACL model";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }

While this revision mismatch seems like a minor thing, this is a pain from a tooling point of view (as we need to index YANG modules per name, revision, organization)
We discovered that version 8 contains a newer revision than the version 9. That confused our tooling.
version 8:
   <CODE BEGINS>file "ietf-acldns@2016-07-20.yang"

   ...

     revision "2017-07-03" {
       description "Clone across IP ACL types.";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }

  
version 9: 
   <CODE BEGINS>file "ietf-acldns@2016-09-07.yang"

   ...

     revision "2016-07-20" {
       description "Base version of dnsname extension of ACL model";
       reference "RFC XXXX: Manufacturer Usage Description
                  Specification";
     }
All these metadata are important.
We're working on: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-acldns
Also, is your YANG module NMDA compliant? It reports tree-type as "unclassified".

Regards, Benoit

Mahesh Jethanandani



--Apple-Mail=_26091870-53E9-405C-8511-E381FFC1FEAC-- --Apple-Mail=_F5DF28F8-F99B-4040-B55F-AC9A40459C3B-- From nobody Sun Sep 24 07:10: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 B8569133087 for ; Sun, 24 Sep 2017 07:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 QntLmbW-AMhc for ; Sun, 24 Sep 2017 07:10:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3C0132055 for ; Sun, 24 Sep 2017 07:10:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8OEAWjX012328; Sun, 24 Sep 2017 15:10:32 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8OEAUxe012313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Sep 2017 15:10:31 +0100 Reply-To: From: "Adrian Farrel" To: "'Benoit Claise'" , "'Warren Kumari'" Cc: Date: Sun, 24 Sep 2017 15:10:28 +0100 Message-ID: <00f601d3353e$e0dfbc80$a29f3580$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdM1PtUUZ+EI2b6ORQKJJjHol9l7Nw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23348.007 X-TM-AS-Result: No--10.434-10.0-31-10 X-imss-scan-details: No--10.434-10.0-31-10 X-TMASE-MatchedRID: 9d2LtCNB3NI4HKI/yaqRm49hRjNfZeOXecvjbu/xDjowplGJ7NxS02yy OlEFJ1wqp5ZCr0eYbovDXZxSoUCC/kFqCrEjrohVoMfp2vHck9Wljvk1idOVaY/B4LpfuBH7+Hm BPyReSgxRe0Jfec/LhG1mWJ6X+wtl157rKJCujesER9Ta+6BEXQeye3S7QzYAH1bhq4z+yfRDRS Qugtjx5j/y4WcsW1yzBfMhJK77jaIwJ6xbTjBa5laA5UKX+E3VQa2sDHLkQ06rzPs85fwUk7flA x/++QmTt3k37C+ZcandSqCvNgMZiIQpiSyKJyYZQpxiLlDD9FVQCOsAlaxN7xxUkJPe1WBqYTcA ZhVQbAu6ecZKJU0gn+p3+5Q2Si5uaOnXEpS1nv90BEBFOTiHn8BZPOJYZoM8hOKxyaUqiJlp/mZ JcqsQBC+on0Lg4mrP9r8gyKf+VS6FvS1gUVltvCjQ4osdfamB0nXvwjW2mSUY0A95tjAn+wOR3t ZA0vji585VzGMOFzA9wJeM2pSaRSAHAopEd76vbzs1W+7RhWnXh5UdD4KUDmmtAg8qwL1fufCii 6bZrScteIUD9zQmpg== Archived-At: Subject: Re: [OPSAWG] AD Review of draft-ietf-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: Sun, 24 Sep 2017 14:10:41 -0000 Hi Benoit, >> In RFC 8199, we made a distinction between model and YANG modules. >> This is why we defined the terms "Network Service YANG modules" and >> "Network Element YANG modules" and not models. You should follow = this >> convention. After all, from the abstract, this document focuses on = YANG. >> Ex: should "model" be replaced by "YANG module"? > > The definition imported from 7950 by 8199 looks like a reasonable = distinction > and we will attempt to apply it here. I hope I am not importing too = much=20 > thought from SMI but isn't a "model" built from one or modules? A = model is > used to "model" some larger entity or function, while a module is used = to > describe a component of an entity or a granular function. > > Probably just some cleanup needed through this document. I'll have a = go. Well, now I'm struggling and I wonder if you can help. What I see from 7950 is that a "YANG module" is a compilable blob of = YANG that may include other modules or specific constructs from another = module. That is clear enough. What is less clear is what a "data model" is or is not. I think that if, = for example, I wanted to model a router, I would construct a data model = from one or mode YANG modules that encode various aspects of the router. = You could, I suppose, present that construct as a module its own right.=20 And that leads me to ask you when it is appropriate to use term "data = model". 8199 doesn't offer me a lot of clarity. For example, section 1 says: For example, a Layer 2 Virtual Private Network (L2VPN) YANG module might be a Network Service YANG Module, ready to be used as a service model by a network operator. Later (in 2.1) it says that a module "describes an abstract model" And (in 2.2) that a module "provides a coherent data model = representation" All this means (I think) that modules are documentation, but models are = used. It's all a bit esoteric for me and I can't find a way forward :-( What I want to do is observe that: - Modules a constructed from YANG and may include other whole YANG modules or specific elements from other YANG modules - Modules describe may define pieces of modelling that are only useful when applied in a context. For example, a module might define a YANG construct for a timestamp or an interface, but those constructs would = only be useful when included in another module that gave context to the timestamp or interface. - Modules may also describe data models for components or sub-components of a managed system (often by including YANG from other modules). - Not all modules provide data models that are independently useful, but some do. And one example is that when we want to model something like a service, we use a service model that is presented in a single = YANG module. Thus, it is perfectly reasonable that 7223 is called "A YANG = Data Model for Interface Management" and 8049 is a "YANG Data Model for L3VPN Service Delivery". =20 So, my inclination is to include pointers to the 7950 definitions, and = to carefully re-read the text in our draft, but not to make a wholesale = change of terms. Any clues? Thanks, Adrian From nobody Mon Sep 25 17:57:21 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 F376F132D41 for ; Mon, 25 Sep 2017 17:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 nhpAobslXPjy for ; Mon, 25 Sep 2017 17:57:18 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4009132992 for ; Mon, 25 Sep 2017 17:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fT2Z5sRpeS3R8/pjvW1VUEJpRffLp5Yk+tsraos4/Ow=; b=HWlsbxTI4D0set9+BcdEX9NO8nAB+DyYOB8euQPaA1UUpO20JaBL0vahd6eMs2CLBPYKG8oxgwSDzIE/h2zz49F96XVLUfmSbnOYTkwc41bn83EQHW5LNbZISkgcOp/8KfZXZQz9DHTVGIFeqIg1B+OHH4sR57jREBVCE13qRhA= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 26 Sep 2017 00:57:15 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 26 Sep 2017 00:57:15 +0000 From: Kent Watsen To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 Thread-Index: AQHTMm66/v4743IIqkCfKQplTRrUO6LGHN6A Date: Tue, 26 Sep 2017 00:57:15 +0000 Message-ID: References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> In-Reply-To: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:RyN+Knz/NMdf/zsJpSSEXNFG/cB4qczRMCM4uc4yeD98WakJw+aUSz8WQhulpF/q+EzgCU9mgNW3bkeC2Z6d/CpPd/UyOZRUKtaXQaDiYW0RdW2mqjL6VqJzrP5VXeG5Q8Kkyyow8C89OHPRsxohk0lxj3vc+F/Dd3vPUIH85dIc2clkSDZTz5Fwzcb67z6vyt6CQ4BiscQ5P0aBk78rZBaPFI7PmdsOyDz+oOPKBszJyPFRjmNduPljFUPM2ACMGwFR/460XC8C2njLM00LaHr/dJ79561dQxTAQuB2lZ73WgAamYdXjjMzpNyMjFXZc6bfjASecDXAliJwwD0raw==; 5:djsGtIfrVxfsjbOOhGApzViCxZIDfWviINWiHhyGCxFUhBEHSFE7CcLAqSf/mY5LZirVlLj/UacTYfai/LrxmhwCIFBGeI0fdeHhUyogXy+DozLS1QDneKqA59cG5Y0JyXOnVMPGi35KWAOC3uKuPg==; 24:DmgIswmEZoc7qGWBQRjbaq5RLGiU6DAyyGjQxpcFv1pXMhWoYhbq2xq5CUYeVz67SkSjlaQXG+62w3gYuQuo4jVNGqXqB2pCw+JSSUmKg68=; 7:K0JELq8rJ3xP9vX4WkSMInRguIBK86KHtnFD+M5/BpN0uu1IucVQmCaRZ3ZB2B9RJv1V1R1xSytpCGlKUt2OsCHtJI1bijtEWvJNG1ooVlHWlITMN/qzxM/CQpgNnTOS7mdiF8oBbeD4gCvNf5KSeKUdNHZfeC2oJHt/v1yWXCxEk2yMsaL8cjzmK852W1XqWIhY/eaO/USwL4xdBZSvyAgvbjs5AbWa28pwBsYEAIU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 271e20f1-588a-456c-3e77-08d5047987c3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089)(266576461109395); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(101416001)(478600001)(6436002)(86362001)(8676002)(81166006)(229853002)(81156014)(2501003)(25786009)(66066001)(5640700003)(33656002)(3660700001)(230783001)(305945005)(7736002)(1730700003)(6916009)(3280700002)(5660300001)(97736004)(316002)(83716003)(6116002)(82746002)(2900100001)(6246003)(3846002)(76176999)(8936002)(6506006)(83506001)(102836003)(99286003)(2351001)(6486002)(6512007)(54356999)(189998001)(58126008)(77096006)(106356001)(14454004)(53936002)(105586002)(2906002)(50986999)(68736007)(36756003)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7F0A7428144F9D43A60C1CEF9A858556@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 00:57:15.7129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275 Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 00:57:20 -0000 SGkgRWxsaW90LA0KDQpJbiBteSBwcmV2aW91cyByZXZpZXcsIEkgaGFkIGFza2VkIGFib3V0IGhv dyBNVUQgaW50ZXJzZWN0cyB3aXRoIG15IHplcm90b3VjaCBkcmFmdCwgd2hpY2ggaGFzIHRoZSBk ZXZpY2UgcmVhY2hpbmcgb3V0IHRvIGVpdGhlciBhIHdlbGwta25vd24gSW50ZXJuZXQtYmFzZWQg b3IgZGVwbG95bWVudC1zcGVjaWZpYyBIVFRQUyByZXNvdXJjZS4gIEJ1dCB0aGUgbmVlZCB0byBy ZWFjaCBvdXQgdG8gdGhlc2UgSFRUUFMgcmVzb3VyY2VzIHNob3VsZCBvbmx5IGJlIGR1cmluZyB0 aGUgZGV2aWNlJ3MgaW5pdGlhbCBib290c3RyYXAgcHJvY2Vzcy4gIFlvdSBzYWlkIGJlZm9yZSBz b21ldGhpbmcgYWJvdXQgYW4gaW5pdGlhbCBwb2xpY3kgZm9sbG93ZWQgYnkgYW4gb24tZ29pbmcg cG9saWN5LCBidXQgSSBkb24ndCBzZWUgdGhhdCBoZXJlLiAgRGlkIEkgbWlzcyBpdD8NCg0KV2hh dCBpcyB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgc3dpdGNoLCB3aGVuIG5vIE1VRCBmaWxl IGlzIGF2YWlsYWJsZS4gIFNlY3Rpb24gNCBzYXlzICJBbnl0aGluZyBub3QgZXhwbGljaXRseSBw ZXJtaXR0ZWQgaXMgZGVuaWVkIiwgYnV0IHRoYXQgc2VjdGlvbiBkaXNjdXNzZXMgdGhlIHByb2Nl c3Npbmcgb2YgYSBNVUQgZmlsZSwgbm90IHdoZW4gdGhlcmUgaXMgbm8gTVVEIGZpbGUuICBJJ20g YXNzdW1pbmcgdGhlIGdvYWwgaXMgZm9yIHRoZSBzd2l0Y2ggdG8gZGVueSB0cmFmZmljIChmYWls IGNsb3NlKSB3aGVuIG5vIE1VRCBmaWxlIGNhbiBiZSBmb3VuZCwgYnV0IEkgd29ycnkgdGhhdCB0 aGlzIG1heSBsZWFkIHRvIHVuaGFwcHkgb3BlcmF0b3JzIGFzIG5ldyBwcm9kdWN0IGRlcGxveW1l bnRzIChub3QgaGF2aW5nIE1VRCBzdXBwb3J0KSBhcmUgY29uc3RhbnRseSBibG9ja2VkIGJ5IHRo ZSBzd2l0Y2hlcy4uLiAgDQoNCkJ1aWxkaW5nIHVwb24gdGhlIGFib3ZlIHR3byBjb21tZW50cywg SSdtIGFzc3VtaW5nIHRoYXQgdGhlIHN3aXRjaCBjb3VsZCBiZSBjb25maWd1cmVkIHRvICphbHdh eXMqIGFsbG93IGFjY2VzcyB0byBzb21lIHJlc291cmNlcywgZXZlbiB3aGVuIG5vIE1VRCBmaWxl IGlzIGZvdW5kLiAgSXMgdGhpcyB3aGF0IHlvdSBoYWQgaW4gbWluZD8NCg0KDQpOaXRzOg0KDQpz MS4zOiAiVGhpbmciIGhlcmUgaXMgZGlzdHJhY3RpbmcuICBDYW4geW91IGNoYW5nZSB0byAiZGV2 aWNlIj8gDQpzMS40OiByZXBsYWNlICJPdXIgd29yayIgd2l0aCBzb21ldGhpbmcgbGlrZSAiVGhl IHNvbHV0aW9uIj8NCnMxLjU6IGluY29uc2lzdGVudCBjYXBpdGFsaXphdGlvbiBpbiBtYW51ZmFj dHVyZXIgY2xhc3MgbmFtZXMNCnMxLjY6IEkgc2VlIFRoaW5nIGhlcmUgdG9vLiAgSXMgdGhpcyBu ZWNlc3Nhcnk/ICBJc24ndCB0aGUgc29sdXRpb24gZm9yIG5vbi1Jb1QgZGV2aWNlcyB0b28/DQpz MS42OiB5b3UgbWlnaHQgd2FudCB0byBpbmNsdWRlIGEgcmVmIHRvIFJGQyA4MTc0LCBwZXIgUkZD IDgxNzQuDQpzMS43OiB0aGUgdGV4dCB0YWxrcyBhYm91dCBOTVNzIGFuZCB3ZWJzaXRlcywgYnV0 IEkgdGhpbmsgeW91IG1lYW4gY29udHJvbGxlciBhbmQgbXVkIHNlcnZlciwgcmlnaHQ/DQpzMS44 OiAjNywgaG93IGlzICJkaXNjb25uZWN0IiBkZWZpbmVkPw0KDQo8c2tpbW1lZCBhIGJ1bmNoIGhl cmU+DQoNCnJlZ2FyZGluZyBzMy40IGFuZCBzMy43LCBpcyBpdCBwb3NzaWJsZSB0byByb2xsICdt YXNhLXNlcnZlcicgaW50byBhbiBleHRlbnNpb24/ICBBbHNvLCBub3RlIHRoYXQgdGhlIGJyc2tp LTA3IGRyYWZ0IHNheXMgbm90aGluZyBhYm91dCB0aGlzIGRyYWZ0LCBzbyB0aGUgcmVsYXRpb25z aGlwIGJldHdlZW4gdGhlIHR3byBpcyB1bmNsZWFyLiAgSSdkIGxpa2UgdG8gc2VlIHJlZmVyZW5j ZXMgdG8gYnJza2kgcmVtb3ZlZCBmcm9tIHRoaXMgZHJhZnQgaWYgcG9zc2libGUsIHdpdGggYSBw cmVmZXJlbmNlIGZvciB0aGUgYnJza2kgZHJhZnQgdG8gZGVmaW5lIGl0cyBvd24gImV4dGVuc2lv biIgaXMgZGVzaXJlZC4NCg0KPHNraW1tZWQgYSBidW5jaCBtb3JlIGhlcmU+DQoNCnMxNzogcy9X YXRzb24vV2F0c2VuLyAgICAtIGFuIGFsbCB0b28gY29tbW9uIHR5cG8gaW4gbXkgbGlmZSEgIDsp DQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0K From nobody Mon Sep 25 23:37: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 EEDC7132198 for ; Mon, 25 Sep 2017 23:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Pgmb-L-eAbxa for ; Mon, 25 Sep 2017 23:37:39 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EDF1321D8 for ; Mon, 25 Sep 2017 23:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4974; q=dns/txt; s=iport; t=1506407858; x=1507617458; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=4sGAE+OND62X9lT4NDRmKyYozFL2zg/A+NpSiHuUKZY=; b=X8K9jR1Y9gWC7zePseekw38R7g1WyAS7ZmtduU8409KlarOASOC7FX7x eVvhgWCMjcRkqV9yu7YDZ9DuvHtCcwZykZe2Jxg0BQy0xkQeEqqRxMfjB LAA7rvEBrKMjkTy2TDPOJwZBdvA3yqMF80X3o7xq8UxWzU0ULLgT/AXy2 w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQBO9MlZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhB2LE5BTK5Y4ggQHA4U7AoR/FAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEjTwwLCQIOCioCAlcGAQwIAQEVAooQCIpEnWaCJ4shAQEBAQEBBAEBAQEBA?= =?us-ascii?q?QESD4MrhTorgn2EawKDKYJgBYoIFokFhROIaYQ7giGOAItcgU+FW5VGgTk2IYE?= =?us-ascii?q?OMiEIHRWFYxyBaT6JHgEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,439,1500940800"; d="asc'?scan'208";a="654987055" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 06:37:34 +0000 Received: from [10.61.234.198] ([10.61.234.198]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8Q6bYbL003619; Tue, 26 Sep 2017 06:37:34 GMT To: Kent Watsen , "opsawg@ietf.org" References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> From: Eliot Lear Message-ID: <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> Date: Tue, 26 Sep 2017 08:37:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HFag2t6cfBBn42TDom7cdJ0nQpoMMGfTE" Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 06:37:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HFag2t6cfBBn42TDom7cdJ0nQpoMMGfTE Content-Type: multipart/mixed; boundary="ukUADKcIImRfkqU1vn0GDKl8M1E1iGaLC"; protected-headers="v1" From: Eliot Lear To: Kent Watsen , "opsawg@ietf.org" Message-ID: <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> In-Reply-To: --ukUADKcIImRfkqU1vn0GDKl8M1E1iGaLC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Kent, I'll respond in two messages (I need to get more info in one case). On 9/26/17 2:57 AM, Kent Watsen wrote: > Hi Elliot, > > In my previous review, I had asked about how MUD intersects with my zer= otouch draft, which has the device reaching out to either a well-known In= ternet-based or deployment-specific HTTPS resource. But the need to reac= h out to these HTTPS resources should only be during the device's initial= bootstrap process. You said before something about an initial policy fo= llowed by an on-going policy, but I don't see that here. Did I miss it? I think so.=C2=A0 There is the notion of=C2=A0 =E2=80=9Ccache-validity=E2= =80=9D with the idea being that one can change the policy from time to time.=C2=A0 The policy = does not itself expire, but the idea with =E2=80=9Ccache-validity=E2=80=9D is = that mud controllers shouldn't pester the mud file server any sooner than that period. > What is the default behavior of the switch, when no MUD file is availab= le. Section 4 says "Anything not explicitly permitted is denied", but th= at section discusses the processing of a MUD file, not when there is no M= UD file. I'm assuming the goal is for the switch to deny traffic (fail c= lose) when no MUD file can be found, but I worry that this may lead to un= happy operators as new product deployments (not having MUD support) are c= onstantly blocked by the switches...=20 Fair question.=C2=A0 If no MUD file is available, it's a deployment decis= ion as to how to proceed (much as it is today).=C2=A0 The intent of Section 4= is that one should assume that the end of an ACL is the JSON equivalent of "deny any".=C2=A0 Should I clarify this? > =20 > > Building upon the above two comments, I'm assuming that the switch coul= d be configured to *always* allow access to some resources, even when no = MUD file is found. Is this what you had in mind? Yes.=C2=A0 I can clarify this as well. > > > Nits: I'll check each of these, but the term "Thing" is intended to be used consistently, and changes made were in response to Robert Sparks' review.=C2=A0 I'll make sure that each is as intended. > s1.3: "Thing" here is distracting. Can you change to "device"?=20 > s1.4: replace "Our work" with something like "The solution"? > s1.5: inconsistent capitalization in manufacturer class names > s1.6: I see Thing here too. Is this necessary? Isn't the solution for= non-IoT devices too? > s1.6: you might want to include a ref to RFC 8174, per RFC 8174. > s1.7: the text talks about NMSs and websites, but I think you mean cont= roller and mud server, right? > s1.8: #7, how is "disconnect" defined? > > > > regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an e= xtension? Also, note that the brski-07 draft says nothing about this dra= ft, so the relationship between the two is unclear. I'd like to see refe= rences to brski removed from this draft if possible, with a preference fo= r the brski draft to define its own "extension" is desired. I am tempted to agree.=C2=A0 This is the one that may need just a day or = two to consider, perhaps with a conversation with Max and the ANIMA folk. > > > > s17: s/Watson/Watsen/ - an all too common typo in my life! ;) > Deepest apologies.=C2=A0 I know how you feel. Eliot --ukUADKcIImRfkqU1vn0GDKl8M1E1iGaLC-- --HFag2t6cfBBn42TDom7cdJ0nQpoMMGfTE 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 iQEcBAEBCAAGBQJZyfWvAAoJEIe2a0bZ0nozkWEH/AkQmFm+AmhqNFj/CL/DMgFp GqSGobJLo0q8Vi3haw0Gjbb+RgKz1M/7whmDNPP5JmnThKhv5YyF2kVnk0j5sPUF u2G2ZyP9w5FTN/5g/+BaZ7ndjiF1gGlunxrSXVx3cX7Auc+8fODA6zJ3/bTxLcOt nAo6dcIzr9IpwE/U4jbngrvAldgZBJ8a826Xrshyjb03nv92UAsADiB2/KNcC8rF 1za6fRgHR2Q5AzX6Xm6aTOZWSXQ5bD+X9+JaqGTdwX0jP+xFTvArSDUHnvo4NnPL 3/2poq4w5AJdTZbnF2qKEaGCybmHkJqC7EuzMbfMeCdu7WwlNoBwuJ2zNuItqzs= =V8eG -----END PGP SIGNATURE----- --HFag2t6cfBBn42TDom7cdJ0nQpoMMGfTE-- From nobody Tue Sep 26 07:06:37 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 D0C31134237 for ; Tue, 26 Sep 2017 07:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WKNP40eUbgLZ for ; Tue, 26 Sep 2017 07:06:33 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE14132992 for ; Tue, 26 Sep 2017 07:06:31 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 3350F1806A9; Tue, 26 Sep 2017 16:06:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 129C11A008A; Tue, 26 Sep 2017 16:06:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0361.001; Tue, 26 Sep 2017 16:06:29 +0200 From: To: "opsawg@ietf.org" CC: "Poscic, Kristian (Nokia - US) (kristian.poscic@nokia.com)" Thread-Topic: Request to review draft-ietf-opsawg-nat-yang-01 Thread-Index: AdMbQXlvGlQjaXSWRdm5PuWt6eiZewHmZwwAAn0HPaABRY4Y8AESwLvgACdsCAA= Date: Tue, 26 Sep 2017 14:06:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A04961A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A02DF87@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05F3CAD8-36D4-48B0-8989-82F1B965D0A2@nokia.com> <787AE7BB302AE849A7480A190F8B93300A04606F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01 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, 26 Sep 2017 14:06:36 -0000 RGVhciBPUFNBV0csDQoNCkkgaGF2ZSByZXF1ZXN0ZWQgYW4gZXh0ZXJuYWwgcmV2aWV3IG9mIHRo ZSBkcmFmdCBmcm9tIGEgdmVuZG9yIHdobyBpcyBub3QgYSBjby1hdXRob3Igb2YgdGhlIGRyYWZ0 LiANCg0KS3JpcyAoY2NlZCkgaGFzIGtpbmRseSBzaGFyZWQgaGlzIGNvbW1lbnRzIGFib3V0IHRo ZSBjdXJyZW50IHN0cnVjdHVyZSBvZiB0aGUgbW9kdWxlIGFuZCB2b2ljZWQgZm9yIHNvbWUgZmVh dHVyZXMgKG1haW5seSB0byBhbGxvdyBmb3IgZGlzdGluY3QgcG9vbHM7IGVhY2ggd2l0aCBpdHMg c3BlY2lmaWMgcGFyYW1ldGVycykuIEknbSBmb3J3YXJkaW5nIHRoZSBsYXRlc3QgZXhjaGFuZ2Uu DQoNCkFzIHlvdSBjYW4gcmVhZCBpbiB0aGUgZXhjaGFuZ2UgYmVsb3csIHRoZSBjdXJyZW50IHZl cnNpb24gb2YgdGhlIGRyYWZ0IGFsbG93cyB0byBhY2hpZXZlIHRoZSBzYW1lIG9iamVjdGl2ZSBi eSBkZWZpbmluZyBtdWx0aXBsZSBOQVQgaW5zdGFuY2VzLiBFYWNoIG9mIHRoZXNlIGluc3RhbmNl cyBtYXkgaGF2ZSBpdHMgb3duIHBhcmFtZXRlcnMgYW5kIHBvbGljaWVzLiBGdXJ0aGVyLCB0aGUg ZHJhZnQgYWxsb3dzIHRvIGRlZmluZSBtdWx0aXBsZSBwb29scyB3aXRoaW4gdGhlIHNhbWUgaW5z dGFuY2UsIGJ1dCBpdCBpcyBzaWxlbnQgYWJvdXQgaG93IHRvIGJpbmQgc3BlY2lmaWMgZmxvd3Mg dG8gYSBnaXZlbiBwb29sLiBUaGUgaW5pdGlhbCByZWFzb24gd2FzIHRoYXQgd2Ugd2FudGVkIHRv IGZvY3VzIG9uIHRoZSBOQVQgZnVuY3Rpb24gcmF0aGVyIHRoYW4gb3ZlcmxvYWRpbmcgdGhlIG1v ZHVsZSB3aXRoIGFkdmFuY2VkIGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9ucyAodGhhdCBhcmUgbm90 IHNwZWNpZmljIHRvIE5BVCkuIA0KDQpPZiBjb3Vyc2UsIHdlIHdpbGwgY29udGludWUgdGhlIGRp c2N1c3Npb24gd2l0aCBLcmlzIHRvIGZpZ3VyZSBvdXQgd2hpY2ggY2hhbmdlcyBhcmUgdG8gYmUg aW1wbGVtZW50ZWQuIEluIHRoZSBtZWFudGltZSwgaW5wdXRzIGZyb20gdGhlIHdvcmtpbmcgZ3Jv dXAgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLiAgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBQb3NjaWMsIEtyaXN0aWFuIChOb2tpYSAtIFVT KSBbbWFpbHRvOmtyaXN0aWFuLnBvc2NpY0Bub2tpYS5jb21dDQo+IEVudm95w6nCoDogbWFyZGkg MjYgc2VwdGVtYnJlIDIwMTcgMDA6MzENCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M Tg0KPiBDY8KgOiBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZ0BpZXRmLm9yZw0KPiBPYmpldMKg OiBSRTogUmVxdWVzdCB0byByZXZpZXcgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDENCj4g DQo+IEhpIE1lZCwNCj4gU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LCB0aGlzIHRpbWUgZnJvbSBt eSBzaWRlLg0KPiBXZSBjYW4gY29udGludWUgaW4gd2hpY2hldmVyIHdheSBpcyB0aGUgbW9zdCBl ZmZpY2llbnQgaW4geW91ciBvcGluaW9uLg0KPiBJJ20gT0sgZWl0aGVyIHdheS4NCj4gDQo+IEkg cmVwbGllZCB0byB5b3VyIGNvbW1lbnRzIGlubGluZS4NCj4gQnV0IG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdGhhdCB0aGlzIChOQVQgWUFORyBtb2RlbCkgaXMgYSBtb3JlIG1vZHVsYXIsDQo+IGku ZS4gaGF2ZSBidWlsZGluZyBibG9ja3MuDQo+IEN1cnJlbnQgbW9kZWwgaXMgYSBiaXQgdG9vIG1v bm9saXRoaWMgYW5kIG1heWJlIGV2ZW4gQ0UgY2VudHJpYy4NCj4gDQo+IFdlIChOb2tpYSkgd2ls bCBiZSBhYmxlIHRvIGNvbnNvbGlkYXRlIHNvbWUgY29uZmlndXJhdGlvbiBkYXRhIGFuZCBtYXli ZQ0KPiBldmVuIG1ha2UgaXQgd2l0aGluIGEgc2luZ2xlIGNvbmZpZ3VyYXRpb24gaW5zdGFuY2Uu DQo+IEZvciBleGFtcGxlLCBmb3IgaW5zaWRlIG1ha2UgaXQgYSAnY2hvaWNlJyBiZXR3ZWVuIGlu dGVyZmFjZSBhbmQgZW50aXJlDQo+ICd2cmYnIChub3Qgc3VyZSBob3cgeW91IHdhbnQgdG8gY2Fs bCB0aGlzIGlmIG5vdCByb3V0aW5nIGNvbnRleHQpOyBzYW1lDQo+IGZvciBvdXRzaWRlLg0KPiBU aGlzIHdheSB3ZSBjYW4gc2F5IHRoZSB3aG9sZSBWUkYgaXMgdGhlIGluc2lkZSBhbmQgYW5vdGhl ciAob3IgdGhlIHNhbWUpDQo+IHdob2xlIFZSRiBpcyBvdXRzaWRlLCB3aGljaCBtZWFucyB0aGF0 IHJvdXRpbmcgaXMgdXNlZCB0byBkZXRlcm1pbmUgd2hlcmUNCj4gdGhlIHRyYW5zbGF0ZWQgcGFj a2V0IG5lZWRzIHRvIGdvIG91dCAodGhpcyBpcyBob3cgd2UgZG8gaXQsIHRoZXJlIG5vDQo+IGlu dGVyZmFjZXMgaW4gb3VyIE5BVCBmb3IgdGhlIHJlYXNvbiBJIHNwZWNpZmllZCBiZWxvdyAtIHRy YW5zcG9ydA0KPiBpbmRlcGVuZGVudCkuDQo+IA0KPiBCdXQgaW4gZ2VuZXJhbCwgbXkgaWRlYSB3 b3VsZCBiZToNCj4gDQo+IC0geW91ciBOQVQgaW5zdGFuY2Uga2luZHMgb2YgZGVmaW5lcyB3aGF0 IGdldHMgbWFwcGVkIHdoZXJlDQo+IA0KPiBCdXQgdGhlbiBvdXRzaWRlIG9mIHRoZSBuYXQtaW5z dGFuY2UgeW91IGhhdmUgYSBidW5jaCBvZiBvdGhlcg0KPiBjb25maWd1cmF0aW9uIHRoYXQgY2Fu IGJlIHJlZmVyZW5jZWQgZnJvbSBpbnNpZGUgdGhpcyBuYXQtaW5zdGFuY2UNCj4gKGNsYXNzaWZp ZXJzIGFuZCBkaWZmZXJlbnQgcG9saWNpZXMpLg0KPiBGb3IgZXhhbXBsZSwgd2hlbiBjZXJ0YWlu IHRyYWZmaWMgaXMgbWFwcGVkIHRvIGEgcG9vbCwgdGhlbiB0aGlzIHRyYWZmaWMNCj4gbWF5IGhh dmUgZGlmZmVyZW50IE5BVCBwYXJhbWV0ZXJzIChBTEdzLCBUQ1AvVURQIHRpbWVycywgZXRjKSB0 aGFuIHNvbWUNCj4gb3RoZXIgdHJhZmZpYyB0aGF0IGlzIG1hcHBlZCB0byBhIGRpZmZlcmVudCBw b29sIHdpdGhpbiB0aGUgc2FtZSBOQVQNCj4gaW5zdGFuY2UuIFRoaXMga2luZCBvZiBmbGV4aWJp bGl0eSBzaG91bGQgZXhpc3QuIFRoYW5rcy4NCj4gS3Jpcw0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBbbWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt YmVyIDIwLCAyMDE3IDM6NTEgQU0NCj4gVG86IFBvc2NpYywgS3Jpc3RpYW4gKE5va2lhIC0gVVMp IDxrcmlzdGlhbi5wb3NjaWNAbm9raWEuY29tPg0KPiBDYzogZHJhZnQtaWV0Zi1vcHNhd2ctbmF0 LXlhbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJlcXVlc3QgdG8gcmV2aWV3IGRyYWZ0LWll dGYtb3BzYXdnLW5hdC15YW5nLTAxDQo+IA0KPiBIaSBLcmlzLA0KPiANCj4gKGNjaW5nIG15IGNv LWF1dGhvcnMpDQo+IA0KPiBBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSB0byBhbnN3ZXIuIEkgd2Fz IG91dCBvZiBvZmZpY2UuDQo+IA0KPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBzaGFyaW5nIHRo ZSBjb21tZW50cy4gTXVjaCBhcHByZWNpYXRlZCENCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0K PiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4gRGXCoDogUG9zY2ljLCBLcmlzdGlhbiAoTm9raWEgLSBVUykgW21haWx0bzprcmlzdGlh bi5wb3NjaWNAbm9raWEuY29tXQ0KPiA+IEVudm95w6nCoDogbWVyY3JlZGkgMTMgc2VwdGVtYnJl IDIwMTcgMjM6MDEgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4gPiBJTVQvT0xOIE9iamV0wqA6 IFJFOiBSZXF1ZXN0IHRvIHJldmlldyBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMQ0KPiA+ DQo+ID4gSGkgTWVkLA0KPiA+DQo+ID4gV2ltIGFza2VkIG1lIHRvIHJldmlldyB0aGlzIGRyYWZ0 IGFuZCBJIGhlcmUgSSBwcm92aWRlIG15IGZlZWRiYWNrLg0KPiANCj4gW01lZF0gVGhhbmsgeW91 Lg0KPiANCj4gPiBVbmZvcnR1bmF0ZWx5IGl0IGRvZXMgbm90IGxpbmUtdXAgd2l0aCBvdXIgaW1w bGVtZW50YXRpb24uIEl0IHNlZW1zDQo+ID4gdGhhdCB0aGlzIG1vZGVsIGNvbmZpZ3VyZXMgZXZl cnl0aGluZyB1bmRlciB0aGUgc2FtZSBuYXQgaW5zdGFuY2UNCj4gPiAocHJpdmF0ZSBzaWRlLCBw dWJsaWMgc2lkZSBhbmQgYWxsIHRoZSBvdGhlciBjb25maWcgb3B0aW9ucykuDQo+IA0KPiBbTWVk XSBBcyBhIHJlbWluZGVyLCB0aGUgbW9kdWxlIGNvdmVycyBib3RoICJzaW1wbGUgTkFUIiAodGhh dCB5b3UgY2FuDQo+IGZpbmQgaW4gYSBDUEUpIGFuZCBtb3JlIGFkdmFuY2VkIG9uZXMgbGlrZSB5 b3VyIGltcGxlbWVudGF0aW9uLiBBcyBzdWNoDQo+IHRoZSBtb2R1bGUgYWxsb3dzOg0KPiAtIGFu IGltcGxlbWVudGF0aW9uIHRvIGRldGVybWluZSBpdHMgaW50ZXJuYWwvZXh0ZXJuYWwgaW50ZXJm YWNlcyBpbiBpdHMNCj4gb3duLiBUaGlzIGlzIHR5cGljYWxseSB0aGUgcmVzaWRlbnRpYWwgZ2F0 ZXdheSBjYXNlLg0KPiAtIGluc3RydWN0IGFuIGltcGxlbWVudGF0aW9uIGFib3V0IHRoZSBleHRl cm5hbCBpbnRlcmZhY2UocykgdG8gd2hpY2ggdG8NCj4gYmluZCB0aGUgTkFUIHdpdGggb3Igd2l0 aG91dCBmaWx0ZXIgb24gdGhlIGludGVybmFsIGludGVyZmFjZShzKS4NCj4gDQo+IA0KPiBbS3Jp c10gT2ssIHRoYW5rcyBmb3IgbWVudGlvbmluZyB0aGlzLCBJJ2xsIHRhbGsgZnJvbSB0aGUgQ0dO IHBlcnNwZWN0aXZlLA0KPiBzY2FsYWJsZSB2ZXJzaW9uIG9mIE5BVCBkZXBsb3llZCBpbiBTUCBu ZXR3b3JrcyAobm90IHRoZSBDRSkuDQo+IEknbSBub3Qgc3VyZSB0aGF0IHRoZSBpbnRlcmZhY2Ug aXMgdGhlIHJpZ2h0IHdheSB0byBnby4gSSB0aGluayB0aGlzDQo+IHNob3VsZCBiZSBiYXNlZCBv biB0aGUgcm91dGVzLiBTbyB5b3UgdHJhbnNsYXRlIHRoZSBwYWNrZXQgYW5kIHRoZW4gbGV0DQo+ IHRoZSByb3V0aW5nIGRlY2lkZXMgd2hlcmUgdG8gZ28uIERpZmZlcmVudCB0cmFuc3BvcnRzIG15 IGVuY2Fwc3VsYXRlIHRoaXMNCj4gcGFja2V0IGRpZmZlcmVudGx5IG9uIGVncmVzcyAoTVBMUy9H UkUsIGV0Yy4pIGFuZCB0aGlzIGlzIGludGVyZmFjZQ0KPiBpbmRlcGVuZGVudC4NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IElmIG5vIGluZGljYXRpb24gaXMgcHJvdmlkZWQsIGFsbCB0aGUg dHJhZmZpYyB0aGF0IGlzIHNlbmQvcmVjZWl2ZWQgb24gYW4NCj4gZXh0ZXJuYWwgaW50ZXJmYWNl IGlzIE5BVGVkLg0KPiBJZiBzdWJzY3JpYmVyLW1hdGNoIGlzIHByb3ZpZGVkLCB0aGUgTkFUIHdp bGwgYmUgYXBwbGllZCBvbmx5IGlmIHRoYXQNCj4gZmlsdGVyIG1hdGNoZXMuDQo+IA0KPiBbS3Jp c10gIEluIHRoaXMgY2FzZSB0aGlzIGlzIGJhc2VkIG9ubHkgb24gZGVzdCBwcmVmaXguIEJ1dCBz b21ldGltZXMgaXQNCj4gc2hvdWxkIGJlIGJhc2VkIG9uIGZpbHRlcnMgd2hpY2ggYXJlIG1vcmUg ZmxleGlibGUgaW4gaWRlbnRpZnlpbmcgd2hhdA0KPiBzaG91bGQgYmUgdHJhbnNsYXRlZCAoZm9y IGV4YW1wbGUgdHJhbnNsYXRlIG9ubHkgdHJhZmZpYyBjb21pbmcgZnJvbSB0aGVzZQ0KPiBzb3Vy Y2UgSVAgYWRkcmVzc2VzLCBvciBvbmx5IGdvaW5nIHRvIHRob3NlIGRlc3RpbmF0aW9uIHBvcnRz LCBlY3QpLg0KPiBTbyBJJ20gdGFsa2luZyBhYm91dCByZWFsIElQIGZpbHRlcnMgKG9yIGFjY2Vz cy1saXN0cywgaG93ZXZlciB5b3UgY2FsbA0KPiB0aGVtKSB0aGF0IGFyZSBhcHBsaWVkIHRvIGlu dGVyZmFjZXMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gSWYgbmF0LXBhc3MtdGhyb3VnaCBpcyBwcm92aWRlZCwgYWxsIHRoZSB0cmFmZmljIHdpbGwg YmUgTkFUZWQgZXhjZXB0IHRoZQ0KPiBvbmUgdGhhdCBtYXRjaGVzIHRoZSBuYXQtcGFzcy10aHJv dWdoIGZpbHRlcihzKS4NCj4gDQo+IFRoZSBjdXJyZW50IHZlcnNpb24gYWxsb3dzIHRvIGRlZmlu ZSBtdWx0aXBsZSBwb29sczsgZWFjaCBpZGVudGlmaWVkIGJ5IGFuDQo+IGlkLiBUaGlzIGlkIGNh biBiZSBjYWxsZWQgdHlwaWNhbGx5IGZvciBhZHZhbmNlZCBmaWx0ZXJpbmcgb3BlcmF0aW9ucy4N Cj4gU3VjaCBmaWx0ZXJzIGFyZSBub3Qgc3VwcG9ydGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24u IEknbSBvcGVuIHRvIGRpc2N1c3MNCj4gdGhvc2Ugd2l0aCB5b3UuDQo+IA0KPiANCj4gW0tyaXNd IHllcywgdGhpcyBpcyBpbXBvcnRhbnQuIFdoYXQgaXMgbmVlZGVkIGlzIGEgc29ydCBvZiBjbGFz c2lmaWNhdGlvbg0KPiBibG9jaywgd2hlcmUgeW91IHNheSAndGhpcyB0cmFmZmljJyBpcyBtYXBw ZWQgdG8gdGhpcyAncG9vbCcuDQo+IFRoaXMgc2hvdWxkIGJlIGRvbmUgdmlhIGlwLWZpbHRlcnMg dGhhdCBhcmUgYXBwbGllZCB0byBpbnRlcmZhY2VzLCBhbmQNCj4gdGh1cyBhbGwgdG9nZXRoZXIg b3V0c2lkZSBvZiBOQVQgaW5zdGFuY2UsIG9yIG9uIGEgY29hcnNlciBsZXZlbCB2aWENCj4gc3Vi c2NyaWJlci1tYXRjaCB0aGF0IGlzIGEgbGlzdCB3aXRoIGEgIGxlYWYgdGhhdCBhY2NlcHRzIG5v dCBvbmx5IGlwLQ0KPiBwcmVmaXggYnV0IGEgcG9vbCBpZCAobGVhZnJlZikgYXMgd2VsbC4NCj4g DQo+IFRhbGtpbmcgYWJvdXQgbXVsdGlwbGUgcG9vbHMsIGl0IGlzIHBvc3NpYmxlIHRoYXQgcG9v bHMgaGF2ZSBkaWZmZXJlbnQNCj4gc2V0dGluZ3MgKG1heCBudW1iZXIgb2Ygc3VicyBwZXIgb3V0 c2lkZSBJUCBhZGRyZXNzLCBldGMpLiBTbyBwb29sIGNvbmZpZw0KPiBzaG91bGQgaGF2ZSBhZGRp dGlvbmFsIHBhcmFtZXRlcnMgKHBvb2wgc2hvdWxkIGJlIGEgbGlzdCB3aXRoIG11bHRpcGxlDQo+ IGxlYWZzKS4gU28gd2UgYWxsb3cgdGhpcyB0b2RheSwgYSB2ZXJ5IGZsZXhpYmxlIGNvbmZpZyB0 aGF0IG1heSBub3cgZ2V0DQo+IHJlc3RyaWN0ZWQgYmVjYXVzZSBvZiBjb25maWd1cmF0aW9uIGNv bnN0cmFpbnRzLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGUgcmVhc29uIHdoeSBzdWNo IGFkdmFuY2VkIGZpbHRlcnMgYXJlIG5vdCBpbmNsdWRlZCBpcyB0aGF0IHRoZSBzYW1lDQo+IG9i amVjdGl2ZSBjYW4gYmUgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgbXVsdGlwbGUgTkFUIGluc3RhbmNl czsgZWFjaCB3aXRoDQo+IGRlZGljYXRlZCBwb29scyBhbmQgcG9ydCBhc3NpZ25tZW50IHBvbGlj aWVzIC4NCj4gDQo+IA0KPiBbS3Jpc10gVHJ1ZSwgYnV0IEkgd2FzIGhvcGluZyB0aGF0IGEgbW9y ZSBlbGVnYW50IHNvbHV0aW9uIGNhbiBiZSBmb3VuZC4NCj4gT3RoZXJ3aXNlIGEgbmV3IE5BVCBp bnN0YW5jZSB3b3VsZCBiZSByZXF1aXJlZCBwZXIgcG9vbC4gTkFUIGluc3RhbmNlIGV2ZW4NCj4g aW4geW91ciBwcm9wb3NhbCBzdXBwb3J0cyBtdWx0aXBsZSBwb29scywgaXQgd291bGQgYmUgbmlj ZSB0byBmaW5kIGEgd2F5DQo+IHRvIHNlbGVjdGl2ZWx5IG1hcCB0cmFmZmljIHRvIHRob3NlIHBv b2xzIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIE5BVA0KPiBpbnN0YW5jZS4NCj4gDQo+IFBsZWFz ZSBub3RlIHRoYXQgYSBzaW1pbGFyIGZlYXR1cmUgaXMgc3VwcG9ydGVkIGZvciBOQVQ2NDogdGhl IE5BVDY0DQo+IHByZWZpeCBjYW4gYmUgc2VsZWN0ZWQgYXMgYSBmdW5jdGlvbiBvZiB0aGUgZGVz dGluYXRpb24gcHJlZml4Lg0KPiANCj4gICAgICAgICAgICAgICstLXJ3IG5hdDY0LXByZWZpeGVz KiBbbmF0NjQtcHJlZml4XQ0KPiAgICAgICAgICAgICAgfCAgKy0tcncgbmF0NjQtcHJlZml4ICAg ICAgICAgICAgICAgaW5ldDppcHY2LXByZWZpeA0KPiAgICAgICAgICAgICAgfCAgKy0tcncgZGVz dGluYXRpb24taXB2NC1wcmVmaXgqIFtpcHY0LXByZWZpeF0NCj4gICAgICAgICAgICAgIHwgICAg ICstLXJ3IGlwdjQtcHJlZml4ICAgIGluZXQ6aXB2NC1wcmVmaXgNCj4gDQo+IE9uZSBtaW5vciBj b21tZW50OiBmcm9tIGFuIElFVEYgc3RhbmRwb2ludCwgInJvdXRpbmcgY29udGV4dCIgbWF5IGJl DQo+IGNvbmZ1c2luZyBmb3IgcGVvcGxlIGFzIE5BVCBpcyBub3QgYSByb3V0aW5nIGZ1bmN0aW9u Lg0KPiANCj4gPg0KPiA+IFdlIGhhdmUgYSBkaWZmZXJlbnQgYXBwcm9hY2gsIHdpdGggdGhyZWUg bWFpbiBidWlsZGluZyBibG9ja3M6DQo+ID4NCj4gPiAxKSAgaW4gaW5zaWRlIChwcml2YXRlKSBy b3V0aW5nIGNvbnRleHQgd2UgZGVmaW5lIHBhcmFtZXRlcnMgdGhhdCBhcmUNCj4gPiByZWxhdGVk IHRvIGluc2lkZS4gRm9yIGV4YW1wbGUgZGVzdGluYXRpb24tcHJlZml4ICh3aGF0IHdpbGwgZ2V0 IHNlbnQNCj4gPiB0byBOQVQgZm9yIHRyYW5zbGF0aW9uKSBpbiBOQVQ0NCwgdGhlbiBOQVQ2NCBw cmVmaXgsIGRldGVybWluaXN0aWMgbmF0DQo+ID4gcGFyYW1ldGVycywgRFMtbGl0ZSBBRlRSIGFk ZHJlc3MgKEkga25vdyB0aGF0IGRzLWxpdGUgaXMgY292ZXJlZCBpbg0KPiA+IGRpZmZlcmVudCBk cmFmdCksIHNvbWUgb3RoZXIgTDItQXdhcmUgTkFUIHBhcmFtZXRlcnMsIGV0Yy4NCj4gDQo+IFtN ZWRdIFB1dHRpbmcgYXNpZGUgdGhhdCB3ZSBtYXJrIGV4cGxpY2l0bHkgdGhvc2UgcGFyYW1ldGVy cyBhcyAiaW5zaWRlIiwNCj4gbW9zdCBvZiB0aG9zZSBwYXJhbWV0ZXJzIGFyZSBzdXBwb3J0ZWQg aW4gdGhpcyB2ZXJzaW9uIChhbmQgdGhlIERTLUxpdGUNCj4gWUFORykuDQo+IA0KPiA+IDIpIHRo ZW4gd2UgZ28gdG8gb3V0c2lkZSByb3V0aW5nIGNvbnRleHRTLiBUaGVyZSB3ZSBkZWZpbmUgcG9v bCBhbmQNCj4gPiBwb29sIHJlbGF0ZWQgcGFyYW1ldGVyczogb3V0c2lkZS1hZGRyZXNzIHJhbmdl LCBwb29sIHdhdGVybWFya3MsIHNpemUNCj4gPiBvZiB0aGUgcG9ydC1ibG9ja3MgaW4gdGhlIHBv b2wsIHBvcnQtZm9yd2FyZGluZyByYW5nZXMgaW4gdGhlIHBvb2wsDQo+ID4gbnVtYmVyIG9mIHN1 YnNjcmliZXJzIHBlciBvdXRzaWRlIElQLCBldGMuDQo+IA0KPiBbTWVkXSBHcmVhdC4gUHV0dGlu ZyBhc2lkZSB0aGF0IHdlIG1hcmsgZXhwbGljaXRseSB0aG9zZSBwYXJhbWV0ZXJzIGFzDQo+ICJv dXRzaWRlIiwgdGhvc2UgcGFyYW1ldGVycyBhcmUgc3VwcG9ydGVkIGluIHRoaXMgdmVyc2lvbi4N Cj4gDQo+ID4gMykgdGhlbiB3ZSBoYXZlIGEgbmF0LXBvbGljeSB0aGF0IHNlcnZlcyBhcyBhIGds dWUgdGhhdCBjb25uZWN0cyB0aGUNCj4gPiBpbnNpZGUgcm91dGluZyBjb250ZXh0IGFuZCB0aGUg b3V0c2lkZSByb3V0aW5nIGNvbnRleHRzIChjYW4gYmUgbW9yZQ0KPiA+IG9mDQo+ID4gdGhlbSkg YW5kIHRoZSBwb29scy4NCj4gPiBJbiBuYXQtcG9saWN5ICBkZWZpbml0aW9uIHdlIHJlZmVyZW5j ZSBhIHBvb2wsIGVuYWJsZSBBTEdzLCBzZXQgdGhlDQo+ID4gc2Vzc2lvbiBsaW1pdCBwZXIgc3Vi c2NyaWJlciwgbnVtYmVyIG9mIHBvcnQtYmxvY2tzIHBlciBzdWJzY3JpYmVyLA0KPiA+IGZpbHRl cmluZyBtb2RlLCBwcmlvcml0eSBzZXNzaW9ucyAoYmFzZWQgb24gZm9yd2FyZGluZy1jbGFzcyks IHRpbW91dHMNCj4gPiAodHBjLCB1ZHAsIGljbXApLCBldGMuDQo+ID4gVGhpcyBwb2xpY3kgaXMg dGhlbiByZWZlcmVuY2VkIGluIHRoZSBpbnNpZGUgcm91dGluZyBjb250ZXh0LiBBdCB0aGF0DQo+ ID4gcG9pbnQgd2hlbiB0aGUgcGFja2V0IGlzIHJlY2VpdmVkIGluIHRoZSBpbnNpZGUsIGl0IGtu b3dzIHdoaWNoIHBvb2wNCj4gPiAoYW5kIG91dHNpZGUgcm91dGluZyBjb250ZXh0KSBpdCBuZWVk cyB0byBnbyB0byAtIGJhc2VkIG9uIHRoZQ0KPiA+IGNsYXNzaWZpY2F0aW9uIGluIHRoZSBpcC1m aWx0ZXIgd2l0aCBhY3Rpb24gTkFUIChhcHBsaWVkIHRvIGFuDQo+ID4gaW50ZXJmYWNlKSBvciBi YXNlZCBvbiB0aGUgZGVzdGluYXRpb24tcHJlZml4IChhcyBjb25maWd1cmVkIGluIHRoZQ0KPiBp bnNpZGUgcm91dGluZyBjb250ZXh0KS4NCj4gPg0KPiA+IFRoZSBrZXkgaXMgdGhhdCB3ZSBhbGxv dyBmb3JraW5nIHRvIG11bHRpcGxlIHBvb2xzIGZyb20gdGhlIHNhbWUNCj4gPiBpbnNpZGUgcm91 dGluZyBjb250ZXh0LiBGb3IgZXhhbXBsZToNCj4gPiBEZXN0aW5hdGlvbi1wcmVmaXggICAxMC4x MC4xMC4wLzI0IG5hdC1wb2xpY3kgIm5hdC1wb2wtbmFtZS0xIiAgICA9PT4NCj4gbmF0LQ0KPiA+ IHBvbC1uYW1lLTEgcmVmZXJlbmNlcyBhIHBvb2wgYW5kIHRoZSBvdXRzaWRlIHJvdXRpbmcgY29u dGV4dA0KPiA+IERlc3RpbmF0aW9uLXByZWZpeCAxMC4yMC4yMC4wLzI0IG5hdCBwb2xpY3kgIm5h dC1wb2wtbmFtZS0yIiAgPT0+DQo+ID4gbmF0LXBvbC0NCj4gPiBuYW1lLTIgcmVmZXJlbmNlIGEg ZGlmZmVyZW50IHBvb2wgaW4gdGhlIHNhbWUgb3V0c2lkZSByb3V0aW5nIGNvbnRleHQNCj4gPiBh cyBhYm92ZSBvciBhIGRpZmZlcmVudCBvbmUNCj4gPg0KPiA+IChzYW1lIGNhbiBiZSBhY2hpZXZl ZCB3aXRoIGZpbHRlcnMgdGhhdCBhcmUgYXBwbGllZCB0byBpbnRlcmZhY2VzIC0NCj4gPiB3aXRo IGZpbHRlcnMgd2UgaGF2ZSBhIG11Y2ggd2lkZXIgcmFuZ2Ugb2YgY2xhc3NpZmljYXRpb24gb3B0 aW9ucyAtDQo+ID4gd2hhdCBnZXRzIGRpdmVydGVkIHRvIE5BVCkuDQo+IA0KPiBbTWVkXSBBZ3Jl ZS4gVGhvc2UgYXJlIG91dCBvZiB0aGUgc2NvcGUuDQo+IA0KPiA+DQo+ID4gVGhlbiBvbiBhIHNp ZGUsIHdlIGhhdmUgbmF0LWNsYXNzaWZpZXJzIHRoYXQgZGVhbCB3aXRoIGRlc3RpbmF0aW9uLW5h dC4NCj4gPiBUaGVyZSB3ZSBpZGVudGlmeSB0cmFmZmljIHRoYXQgbmVlZHMgdG8gYmUgZE5UQWVk IGFuZCB3ZSBzcGVjaWZ5IHRoZQ0KPiA+IGRlc3QtIGlwIGFkZHJlc3MgaW4gdGhlIHNhbWUgY2xh c3NpZmllci4gVGhpcyBjbGFzc2lmaWVyIGlzIHRoZW4NCj4gPiBhcHBsaWVkIGluIG5hdC0gcG9s aWN5IGFzIHdlbGwuDQo+ID4NCj4gPiBUaGVyZSBhcmUgYSBmZXcgb3RoZXIgcGllY2VzIHRoYXQg ZGVhbCB3aXRoIGxvZ2dpbmcsIHBjcCBldGMgZnVuY3Rpb25zDQo+ID4gdGhhdCBhcmUgc2NhdHRl cmVkIGFyb3VuZCwgYnV0IHRoaXMgY2FuIGJlIGNvbnNvbGlkYXRlZC4gQnV0IEknbQ0KPiA+IGFm cmFpZCB0aGF0IHRoaXMgMyBwcm9uZyBzdHJ1Y3R1cmUgKGluc2lkZSwgb3V0c2lkZSwgbmF0LXBv bGljeSkgd291bGQNCj4gPiBiZSBoYXJkZXIgdG8gY29uc29saWRhdGUuDQo+ID4NCj4gPg0KPiA+ IEZyb20geW91ciBwcm9wb3NhbCBpbiB0aGUgZHJhZnQsIEknbSBub3QgY2xlYXIgaG93IGRvIHlv dSBlbnN1cmUNCj4gPiBzZXBhcmF0aW9uIG9mIHJvdXRpbmcgY29udGV4dCBhbmQgc2VsZWN0aW9u IG9mIGRpZmZlcmVudCBwb29scy4NCj4gDQo+IFtNZWRdIEFzIG1lbnRpb25lZCBhYm92ZSwgdGhl IGN1cnJlbnQgbW9kZWwgZG9lcyBzdXBwb3J0IHRoaXMgYnkgZGVmaW5pbmcNCj4gbXVsdGlwbGUg TkFUIGluc3RhbmNlcy4NCj4gDQo+ICBJIHNlZSB0aGF0DQo+ID4gaW5zaWRlIGludGVyZmFjZXMg YW5kIG91dHNpZGUgaW50ZXJmYWNlcyBhcmUgcmVmZXJlbmNlZCBpbiB0aGUgbmF0LQ0KPiA+IGlu c3RhbmNlLCBidXQgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiByb3V0aW5nIGNvbnRleHQgKGFsdGhv dWdoIHRoaXMNCj4gPiBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBpbnRlcmZhY2UgbmFtZSwgYXNz dW1pbmcgdGhhdCBpbnRmIG5hbWUgYXJlDQo+ID4gdW5pcXVlIGNoYXNzaXMgd2lkZSkuIE1vcmVv dmVyIEkgY2FuJ3Qgc2VlIGhvdyBkbyB5b3UgZW5zdXJlIHNlbGVjdGlvbg0KPiA+IG9mIGEgcG9v bCBiYXNlZCBvbiBzb21lIGNsYXNzaWZpY2F0aW9uIG9uIGluZ3Jlc3MgKHNheQ0KPiA+IGRlc3Rp bmF0aW9uLXByZWZpeCBBIGdvIHRvIHBvb2wgMSwgZGVzdGluYXRpb24tcHJlZml4IEIgdG8gcG9v bCAyKS4NCj4gDQo+IFtNZWRdIFRoaXMgaXMgbm90IHN1cHBvcnRlZCB3aXRoaW4gdGhlIHNhbWUg TkFUIGluc3RhbmNlLiBJJ20gb3BlbiB0bw0KPiBkaXNjdXNzIGlmL2hvdyB0byB1cGRhdGUgdGhl IG1vZHVsZSB0byBpbmNsdWRlIHRoaXMgZmVhdHVyZS4NCj4gDQo+ID4NCj4gPg0KPiA+IFdlIGRl ZmluaXRlbHkgd2FudCB0byBiZSBwYXJ0IG9mIHRoaXMgZGlzY3Vzc2lvbg0KPiANCj4gW01lZF0g R3JlYXQhDQo+IA0KPiAsIGJ1dCBhdCB0aGlzIHBvaW50IEknbQ0KPiA+IG5vdCBzdXJlIGhvdyB0 byBwcm9jZWVkLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgY2FuIGFkdmlzZS4gVGhhbmtzLg0K PiANCj4gW01lZF0gSSBzZWUgdGhlIGZvbGxvd2luZyBvcHRpb25zOg0KPiAoMSkgQ29udGludWUg dGhlIGRpc2N1c3Npb24gaW4gcHJpdmF0ZSB0byBmaWd1cmUgb3V0IHdoYXQgbW9kaWZpY2F0aW9u cw0KPiBjYW4gYmUgaW1wbGVtZW50ZWQgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzLg0KPiAoMikg Rm9yd2FyZCB0aGlzIG1haWwgdG8gdGhlIE9QU0FXRyBtYWlsaW5nIGxpc3QgYW5kIHRha2UgaXQg Zm9yIHRoZXJlLg0KPiANCj4gUHJvY2VlZGluZyB3aXRoIGJvdGggaXMgYWxzbyBhbiBvcHRpb24u IEZvciBleGFtcGxlLCBJIGNhbiBzdGFydCBieQ0KPiBzaGFyaW5nIHlvdXIgY29uY2VybiB3aXRo IHRoZSBXRyBhbmQgdGhlbiBkaXNjdXNzIGluIHByaXZhdGUgaG93IHRvDQo+IGFkZHJlc3MgaXQu DQo+IA0KPiBQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBwcmVmZXJlbmNlLg0KPiANCj4gPiBLcmlz DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IEhlbmRlcmlja3gsIFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJw KQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzEsIDIwMTcgMTE6MzEgUE0NCj4gPiBUbzog UG9zY2ljLCBLcmlzdGlhbiAoTm9raWEgLSBVUykgPGtyaXN0aWFuLnBvc2NpY0Bub2tpYS5jb20+ DQo+ID4gU3ViamVjdDogRlc6IFJlcXVlc3QgdG8gcmV2aWV3IGRyYWZ0LWlldGYtb3BzYXdnLW5h dC15YW5nLTAxDQo+ID4NCj4gPiBDYW4geW91IGNvbW1lbnRzIG9uIHRoaXM/DQo+ID4NCj4gPiBP biAyMi8wOC8yMDE3LCAxNDoyMywgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iDQo+ID4g PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gICAgIEhpIFdp bSwNCj4gPg0KPiA+ICAgICBJIGhvcGUgeW91IGFyZSBkb2luZyB3ZWxsIQ0KPiA+DQo+ID4gICAg IENhbiB5b3UgcGxlYXNlIHJldmlldyB0aGlzIG1vZGVsPyBJJ20gcGFydGljdWxhcmx5IGludGVy ZXN0ZWQgdG8NCj4gPiBzZWUgaWYgdGhlIG1vZGVsIGlzIGFsaWduZWQgd2l0aCB5b3VyIDc3NTAg TkFUNDQvTkFUNjQgaW1wbGVtZW50YXRpb24uDQo+ID4NCj4gPiAgICAgVGhhbmsgeW91Lg0KPiA+ DQo+ID4gICAgIENoZWVycywNCj4gPiAgICAgTWVkDQo+ID4NCj4gPiAgICAgPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gPiAgICAgPiBEZSA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiAgICAgPiBFbnZvecOpIDog bHVuZGkgMjEgYW/Du3QgMjAxNyAxMToxMA0KPiA+ICAgICA+IMOAIDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTjsgU2VudGhpbCBTaXZha3VtYXI7IEpBQ1FVRU5FVA0KPiA+IENocmlzdGlhbg0K PiA+ICAgICA+IElNVC9PTE47IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IFFpbiBXdQ0KPiA+ICAg ICA+IE9iamV0IDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW9wc2F3 Zy1uYXQteWFuZy0NCj4gPiAwMS50eHQNCj4gPiAgICAgPg0KPiA+ICAgICA+DQo+ID4gICAgID4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTAxLnR4dA0K PiA+ICAgICA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3Vj YWRhaXIgYW5kIHBvc3RlZA0KPiA+IHRvIHRoZQ0KPiA+ICAgICA+IElFVEYgcmVwb3NpdG9yeS4N Cj4gPiAgICAgPg0KPiA+ICAgICA+IE5hbWU6CQlkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZw0K PiA+ICAgICA+IFJldmlzaW9uOgkwMQ0KPiA+ICAgICA+IFRpdGxlOgkJQSBZQU5HIERhdGEgTW9k ZWwgZm9yIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbg0KPiA+IChOQVQpDQo+ID4gICAgID4g YW5kIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFQpDQo+ID4gICAgID4gRG9jdW1lbnQg ZGF0ZToJMjAxNy0wOC0yMQ0KPiA+ICAgICA+IEdyb3VwOgkJb3BzYXdnDQo+ID4gICAgID4gUGFn ZXM6CQk3Mw0KPiA+ICAgICA+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi0NCj4gPiBvcHNhd2ctDQo+ID4gICAgID4gbmF0LXlh bmctMDEudHh0DQo+ID4gICAgID4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtDQo+IG9wc2F3Zy0NCj4gPiBuYXQtDQo+ID4gICAgID4g eWFuZy8NCj4gPiAgICAgPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4gPiB5YW5nLTAxDQo+ID4gICAgID4gSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi0NCj4gPiBvcHNhd2ctDQo+ID4gICAgID4gbmF0LXlhbmctMDENCj4gPiAgICAgPiBEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtDQo+ IG9wc2F3Zy0NCj4gPiBuYXQtDQo+ID4gICAgID4geWFuZy0wMQ0KPiA+ICAgICA+DQo+ID4gICAg ID4gQWJzdHJhY3Q6DQo+ID4gICAgID4gICAgRm9yIHRoZSBzYWtlIG9mIG5ldHdvcmsgYXV0b21h dGlvbiBhbmQgdGhlIG5lZWQgZm9yIHByb2dyYW1taW5nDQo+ID4gICAgID4gICAgTmV0d29yayBB ZGRyZXNzIFRyYW5zbGF0aW9uIChOQVQpIGZ1bmN0aW9uIGluIHBhcnRpY3VsYXIsIGENCj4gZGF0 YQ0KPiA+ICAgICA+ICAgIG1vZGVsIGZvciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcgdGhlIE5B VCBpcyBlc3NlbnRpYWwuICBUaGlzDQo+ID4gICAgID4gICAgZG9jdW1lbnQgZGVmaW5lcyBhIFlB TkcgZGF0YSBtb2RlbCBmb3IgdGhlIE5BVCBmdW5jdGlvbi4NCj4gPiAgICAgPg0KPiA+ICAgICA+ ICAgIE5BVDQ0LCBOZXR3b3JrIEFkZHJlc3MgYW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20g SVB2Ng0KPiBDbGllbnRzDQo+ID4gdG8NCj4gPiAgICAgPiAgICBJUHY0IFNlcnZlcnMgKE5BVDY0 KSwgQ3VzdG9tZXItc2lkZSB0cmFuc0xBVG9yIChDTEFUKSwgRXhwbGljaXQNCj4gPiAgICAgPiAg ICBBZGRyZXNzIE1hcHBpbmdzIGZvciBTdGF0ZWxlc3MgSVAvSUNNUCBUcmFuc2xhdGlvbiAoU0lJ VCBFSU0pLA0KPiA+IGFuZA0KPiA+ICAgICA+ICAgIElQdjYgTmV0d29yayBQcmVmaXggVHJhbnNs YXRpb24gKE5QVHY2KSBhcmUgY292ZXJlZCBpbiB0aGlzDQo+ID4gZG9jdW1lbnQuDQo+ID4gICAg ID4NCj4gPiAgICAgPg0KPiA+ICAgICA+DQo+ID4gICAgID4NCj4gPiAgICAgPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0K PiA+ICAgICA+IHN1Ym1pc3Npb24NCj4gPiAgICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiA+ICAgICA+ DQo+ID4gICAgID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+DQoNCg== From nobody Tue Sep 26 11:25:31 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 687341342DD for ; Tue, 26 Sep 2017 11:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yCByu-zKT0KT for ; Tue, 26 Sep 2017 11:25:27 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B6E1342FD for ; Tue, 26 Sep 2017 11:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7156; q=dns/txt; s=iport; t=1506450327; x=1507659927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hv9FdzJZYdl5Xqu6Dm6VumR7Vxl/nC+hUoSBreh1QTA=; b=jUoyICUCSi6S5xGlfhy0SxKepwFO2f4WOa2bcIYGmMVs1NFKvlNLgl6c 3kvz47zUYDfWZq1S1NRyinrUzN+3xAiveGXM4ga+AH4DFwnBTkq3eBNJt WjgqZhoXdmbzyBoJJ1rxgaKlGZIAjh7PGrxy1cnffQjVIkftfbIwxEmn6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQBAm8pZ/4YNJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNbZG4UEweDb5obgVQieZU/ggQKI4UYAhqENVcBAgEBAQEBAms?= =?us-ascii?q?ohRgBAQEBAgEjET4HBQsCAQgYAgImAgICMBUQAgQOBRkCig8IEKgxgieLHAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ6CHYICgzsrC4I9NYRaAw8CFoMTL4IxBYo?= =?us-ascii?q?IFokFhROIagKHXIx/jSuFW5UaAhEZAYE4AVeBDngVWwGFBxyBZ3YBiDiBMoEQA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="scan'208";a="8984760" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2017 18:25:26 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8QIPQi9010997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 18:25:26 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 13:25:25 -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.1320.000; Tue, 26 Sep 2017 13:25:25 -0500 From: "Max Pritikin (pritikin)" To: Eliot Lear CC: Kent Watsen , "opsawg@ietf.org" Thread-Topic: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 Thread-Index: AQHTNvTSDWItj0h5hUeSQEbjimMLTg== Date: Tue, 26 Sep 2017 18:25:25 +0000 Message-ID: <8500A252-4867-41E3-806D-DD700953A777@cisco.com> References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> In-Reply-To: <587377b8-02d5-d209-dc1d-2279be332f2a@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: <67E23B116FDAD049B6600504A69B0EA6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 18:25:29 -0000 DQpNeSBjb21tZW50cyBpbmxpbmUsDQoNCg0KPiBPbiBTZXAgMjYsIDIwMTcsIGF0IDEyOjM3IEFN LCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBLZW50LA0KPiAN Cj4gSSdsbCByZXNwb25kIGluIHR3byBtZXNzYWdlcyAoSSBuZWVkIHRvIGdldCBtb3JlIGluZm8g aW4gb25lIGNhc2UpLg0KPiANCj4gDQo+IE9uIDkvMjYvMTcgMjo1NyBBTSwgS2VudCBXYXRzZW4g d3JvdGU6DQo+PiBIaSBFbGxpb3QsDQo+PiANCj4+IEluIG15IHByZXZpb3VzIHJldmlldywgSSBo YWQgYXNrZWQgYWJvdXQgaG93IE1VRCBpbnRlcnNlY3RzIHdpdGggbXkgemVyb3RvdWNoIGRyYWZ0 LCB3aGljaCBoYXMgdGhlIGRldmljZSByZWFjaGluZyBvdXQgdG8gZWl0aGVyIGEgd2VsbC1rbm93 biBJbnRlcm5ldC1iYXNlZCBvciBkZXBsb3ltZW50LXNwZWNpZmljIEhUVFBTIHJlc291cmNlLiAg QnV0IHRoZSBuZWVkIHRvIHJlYWNoIG91dCB0byB0aGVzZSBIVFRQUyByZXNvdXJjZXMgc2hvdWxk IG9ubHkgYmUgZHVyaW5nIHRoZSBkZXZpY2UncyBpbml0aWFsIGJvb3RzdHJhcCBwcm9jZXNzLiAg WW91IHNhaWQgYmVmb3JlIHNvbWV0aGluZyBhYm91dCBhbiBpbml0aWFsIHBvbGljeSBmb2xsb3dl ZCBieSBhbiBvbi1nb2luZyBwb2xpY3ksIGJ1dCBJIGRvbid0IHNlZSB0aGF0IGhlcmUuICBEaWQg SSBtaXNzIGl0Pw0KPiANCj4gSSB0aGluayBzby4gIFRoZXJlIGlzIHRoZSBub3Rpb24gb2YgIOKA nGNhY2hlLXZhbGlkaXR54oCdIHdpdGggdGhlIGlkZWENCj4gYmVpbmcgdGhhdCBvbmUgY2FuIGNo YW5nZSB0aGUgcG9saWN5IGZyb20gdGltZSB0byB0aW1lLiAgVGhlIHBvbGljeSBkb2VzDQo+IG5v dCBpdHNlbGYgZXhwaXJlLCBidXQgdGhlIGlkZWEgd2l0aCDigJxjYWNoZS12YWxpZGl0eeKAnSBp cyB0aGF0IG11ZA0KPiBjb250cm9sbGVycyBzaG91bGRuJ3QgcGVzdGVyIHRoZSBtdWQgZmlsZSBz ZXJ2ZXIgYW55IHNvb25lciB0aGFuIHRoYXQNCj4gcGVyaW9kLg0KDQpUaGUgcmVsZXZhbnQgaW50 ZXJzZWN0aW9uIHdvdWxkIGJlIGlmL2hvdy93aGVuIE1VRCBkZW554oCZcyBvciBhbGxvd3MgYSBj b25uZWN0aW9uIHRvIHRoZSBuZXRjb25mIHplcm90b3VjaCBib290c3RyYXAgc2VydmljZSBhcyBk ZXNjcmliZWQgaW46DQoJaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0 Y29uZi16ZXJvdG91Y2gtMTcjc2VjdGlvbi00LjQgDQo/DQoNCkkgdGhpbmsgdGhlIE1VRCANCg0K SSB0aGluayB0aGUgTVVEIOKAmGNvbnRyb2xsZXLigJkgb3Ig4oCYbXktY29udHJvbGxlcuKAmSBt ZWNoYW5pc20gd291bGQgYmUgdXNlZCB0byBlbnN1cmUgZGV2aWNlcyBvZiB0aGlzIGNsYXNzIGNh biBhY2Nlc3MgdGhlIGluZGljYXRlZCDigJxpbnRlcm5ldC1iYXNlZOKAnSBvciDigJxkZXBsb3lt ZW50LXNwZWNpZmljIEhUVFBTIHJlc291cmNl4oCdIGJvb3RzdHJhcC1zZXJ2ZXI/DQoNClNpbWls YXJseSBmb3IgYW5pbWEgZGV2aWNlcyBtaWdodCBiZSBsaW1pdGVkIHRvIG9ubHkgY29udGFjdGlu ZyB0aGVpciBsb2NhbCBCUlNLSSByZWdpc3RyYXIgdmlhIOKAmG15LWNvbnRyb2xsZXInPw0KDQpB c3N1bWluZyBteSBpbnRlcnByZXRhdGlvbiBpcyBjb3JyZWN0IEkgZG9u4oCZdCBzZWUgYW55IGNo YW5nZSBuZWVkZWQgaW4gdGhlIHRleHQgYWJvdXQgdGhpcy4gDQoNCj4+IFdoYXQgaXMgdGhlIGRl ZmF1bHQgYmVoYXZpb3Igb2YgdGhlIHN3aXRjaCwgd2hlbiBubyBNVUQgZmlsZSBpcyBhdmFpbGFi bGUuICBTZWN0aW9uIDQgc2F5cyAiQW55dGhpbmcgbm90IGV4cGxpY2l0bHkgcGVybWl0dGVkIGlz IGRlbmllZCIsIGJ1dCB0aGF0IHNlY3Rpb24gZGlzY3Vzc2VzIHRoZSBwcm9jZXNzaW5nIG9mIGEg TVVEIGZpbGUsIG5vdCB3aGVuIHRoZXJlIGlzIG5vIE1VRCBmaWxlLiAgSSdtIGFzc3VtaW5nIHRo ZSBnb2FsIGlzIGZvciB0aGUgc3dpdGNoIHRvIGRlbnkgdHJhZmZpYyAoZmFpbCBjbG9zZSkgd2hl biBubyBNVUQgZmlsZSBjYW4gYmUgZm91bmQsIGJ1dCBJIHdvcnJ5IHRoYXQgdGhpcyBtYXkgbGVh ZCB0byB1bmhhcHB5IG9wZXJhdG9ycyBhcyBuZXcgcHJvZHVjdCBkZXBsb3ltZW50cyAobm90IGhh dmluZyBNVUQgc3VwcG9ydCkgYXJlIGNvbnN0YW50bHkgYmxvY2tlZCBieSB0aGUgc3dpdGNoZXMu Li4gDQo+IA0KPiBGYWlyIHF1ZXN0aW9uLiAgSWYgbm8gTVVEIGZpbGUgaXMgYXZhaWxhYmxlLCBp dCdzIGEgZGVwbG95bWVudCBkZWNpc2lvbg0KPiBhcyB0byBob3cgdG8gcHJvY2VlZCAobXVjaCBh cyBpdCBpcyB0b2RheSkuICBUaGUgaW50ZW50IG9mIFNlY3Rpb24gNCBpcw0KPiB0aGF0IG9uZSBz aG91bGQgYXNzdW1lIHRoYXQgdGhlIGVuZCBvZiBhbiBBQ0wgaXMgdGhlIEpTT04gZXF1aXZhbGVu dCBvZg0KPiAiZGVueSBhbnkiLiAgU2hvdWxkIEkgY2xhcmlmeSB0aGlzPw0KPiANCj4gDQo+PiAN Cj4+IA0KPj4gQnVpbGRpbmcgdXBvbiB0aGUgYWJvdmUgdHdvIGNvbW1lbnRzLCBJJ20gYXNzdW1p bmcgdGhhdCB0aGUgc3dpdGNoIGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8gKmFsd2F5cyogYWxsb3cg YWNjZXNzIHRvIHNvbWUgcmVzb3VyY2VzLCBldmVuIHdoZW4gbm8gTVVEIGZpbGUgaXMgZm91bmQu ICBJcyB0aGlzIHdoYXQgeW91IGhhZCBpbiBtaW5kPw0KPiANCj4gWWVzLiAgSSBjYW4gY2xhcmlm eSB0aGlzIGFzIHdlbGwuDQo+IA0KPj4gDQo+PiANCj4+IE5pdHM6DQo+IEknbGwgY2hlY2sgZWFj aCBvZiB0aGVzZSwgYnV0IHRoZSB0ZXJtICJUaGluZyIgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZA0K PiBjb25zaXN0ZW50bHksIGFuZCBjaGFuZ2VzIG1hZGUgd2VyZSBpbiByZXNwb25zZSB0byBSb2Jl cnQgU3BhcmtzJw0KPiByZXZpZXcuICBJJ2xsIG1ha2Ugc3VyZSB0aGF0IGVhY2ggaXMgYXMgaW50 ZW5kZWQuDQo+PiBzMS4zOiAiVGhpbmciIGhlcmUgaXMgZGlzdHJhY3RpbmcuICBDYW4geW91IGNo YW5nZSB0byAiZGV2aWNlIj8gDQo+PiBzMS40OiByZXBsYWNlICJPdXIgd29yayIgd2l0aCBzb21l dGhpbmcgbGlrZSAiVGhlIHNvbHV0aW9uIj8NCj4+IHMxLjU6IGluY29uc2lzdGVudCBjYXBpdGFs aXphdGlvbiBpbiBtYW51ZmFjdHVyZXIgY2xhc3MgbmFtZXMNCj4+IHMxLjY6IEkgc2VlIFRoaW5n IGhlcmUgdG9vLiAgSXMgdGhpcyBuZWNlc3Nhcnk/ICBJc24ndCB0aGUgc29sdXRpb24gZm9yIG5v bi1Jb1QgZGV2aWNlcyB0b28/DQo+PiBzMS42OiB5b3UgbWlnaHQgd2FudCB0byBpbmNsdWRlIGEg cmVmIHRvIFJGQyA4MTc0LCBwZXIgUkZDIDgxNzQuDQo+PiBzMS43OiB0aGUgdGV4dCB0YWxrcyBh Ym91dCBOTVNzIGFuZCB3ZWJzaXRlcywgYnV0IEkgdGhpbmsgeW91IG1lYW4gY29udHJvbGxlciBh bmQgbXVkIHNlcnZlciwgcmlnaHQ/DQo+PiBzMS44OiAjNywgaG93IGlzICJkaXNjb25uZWN0IiBk ZWZpbmVkPw0KPj4gDQo+PiA8c2tpbW1lZCBhIGJ1bmNoIGhlcmU+DQo+PiANCj4+IHJlZ2FyZGlu ZyBzMy40IGFuZCBzMy43LCBpcyBpdCBwb3NzaWJsZSB0byByb2xsICdtYXNhLXNlcnZlcicgaW50 byBhbiBleHRlbnNpb24/ICBBbHNvLCBub3RlIHRoYXQgdGhlIGJyc2tpLTA3IGRyYWZ0IHNheXMg bm90aGluZyBhYm91dCB0aGlzIGRyYWZ0LCBzbyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl IHR3byBpcyB1bmNsZWFyLiAgSSdkIGxpa2UgdG8gc2VlIHJlZmVyZW5jZXMgdG8gYnJza2kgcmVt b3ZlZCBmcm9tIHRoaXMgZHJhZnQgaWYgcG9zc2libGUsIHdpdGggYSBwcmVmZXJlbmNlIGZvciB0 aGUgYnJza2kgZHJhZnQgdG8gZGVmaW5lIGl0cyBvd24gImV4dGVuc2lvbiIgaXMgZGVzaXJlZC4N Cj4gDQo+IEkgYW0gdGVtcHRlZCB0byBhZ3JlZS4gIFRoaXMgaXMgdGhlIG9uZSB0aGF0IG1heSBu ZWVkIGp1c3QgYSBkYXkgb3IgdHdvDQo+IHRvIGNvbnNpZGVyLCBwZXJoYXBzIHdpdGggYSBjb252 ZXJzYXRpb24gd2l0aCBNYXggYW5kIHRoZSBBTklNQSBmb2xrLg0KDQpJIHRoaW5rIHRoZSBjdXJy ZW50IHRleHQgaXMgdmFsaWQgYW5kIGNvcnJlY3QuIEkgdm90ZSBhZ2FpbnN0IGFueSBjaGFuZ2Vz IGluIHRoaXMgYXJlYTogDQoNCkRpc3RyaWJ1dGlvbiBvZiB0aGUgTUFTQSBzZXJ2ZXIgVVJMIGlz IGluZm9ybWF0aXZlIHRvIHRoZSBsb2NhbCBuZXR3b3JrIGluZnJhc3RydWN0dXJlLiBTdXBwb3J0 IGZvciB0aGlzIG1lY2hhbmlzbXMgYWxsb3dzIGEgbG9jYWwgbmV0d29yayBpbmZyYXN0cnVjdHVy ZSB0byBrbm93IHdoaWNoIE1BU0Egc2VydmljZSB0byBjb250YWN0IGZvciB0aGlzIGRldmljZS4g QWxsb3dpbmcgdGhpcyB3aXRoaW4gTVVEIHByb3ZpZGVzIGFuIG9wdGltaXphdGlvbiBvcHBvcnR1 bml0eSBmb3IgdmVuZG9ycyB0aGF0IGFyZSBhbmltYSBCUlNLSSBjb21wYXRpYmxlLiBUaGV5IGNh biBlaXRoZXIgaW1wbGVtZW50IHRoZSBNQVNBIGV4dGVuc2lvbiBVUkwsIGFuZCBhbnkgb3RoZXIg dXJscywgd2l0aGluIHRoZWlyIGluaXRpYWwgZGV2aWNlIGlkZW50aXR5IC1vci0gdGhleSBjYW4g aW1wbGVtZW50IG9ubHkgdGhlIE1VRCBVUkwgZXh0ZW5zaW9uLiBTcGFjZSBhbmQgY2hhbmdlcyB0 byB0aGUgZGV2aWNlIGlkZW50aXR5IGNlcnRpZmljYXRlIGFyZSBsaW1pdGVkIGFuZCBkaWZmaWN1 bHQgc28gYW4gaW5kaXJlY3Rpb24gdGhyb3VnaCB0aGUgTVVEIHNlcnZpY2UgaXMgYSB2YWx1YWJs ZSBhcHByb2FjaC4NCg0KVG8gbWFrZSB0aGlzIGV4dGVuc2libGUgZWl0aGVyIEJSU0tJIChldCBh bGwgKSBuZWVkcyB0byBleHRlbmQgdGhlIHlhbmcgbW9kZWxzIG11Y2ggdGhlIHdheSBpdCBkb2Vz IHdpdGggdGhlIHZvdWNoZXIgZG9jdW1lbnQgb3IgdGhlcmUgbmVlZHMgdG8gYmUgYSBNVUQgc3Bl Y2lmaWMgZXh0ZW5zaW9uIG1ldGhvZCAoaWFuYSBuYW1lc3BhY2UgZGVjbGFyZWQgd2l0aGluIE1V RD8pIG9yIHNvbWV0aGluZy4gSSBkb27igJl0IHNlZSBob3cgdGhhdCBmaXRzIHRvZ2V0aGVyIGNs ZWFubHkgYW5kIGRvbuKAmXQgc2VlIHNvbHZpbmcgdGhvc2UgcXVlc3Rpb25zIGFzIG5lY2Vzc2Fy eSBhdCB0aGlzIHRpbWUuDQoNCi0gbWF4DQoNCj4gDQo+PiANCj4+IDxza2ltbWVkIGEgYnVuY2gg bW9yZSBoZXJlPg0KPj4gDQo+PiBzMTc6IHMvV2F0c29uL1dhdHNlbi8gICAgLSBhbiBhbGwgdG9v IGNvbW1vbiB0eXBvIGluIG15IGxpZmUhICA7KQ0KPj4gDQo+IERlZXBlc3QgYXBvbG9naWVzLiAg SSBrbm93IGhvdyB5b3UgZmVlbC4NCj4gDQo+IEVsaW90DQo+IA0KDQo= From nobody Tue Sep 26 11:54:37 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 C03AC134216 for ; Tue, 26 Sep 2017 11:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 P_qDFIUJ9GcY for ; Tue, 26 Sep 2017 11:54:35 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0135.outbound.protection.outlook.com [104.47.41.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BF3132930 for ; Tue, 26 Sep 2017 11:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0MuulncC5CiCLuujquyOX//I4fsl2kdM7e4yhJ4sw/4=; b=OVxoaqcKXsFzBgwsYsYcd2IDIh5awFUGA7Xzel0CunP7pG2vDwd1OfOuKvHHR34Pz2zzC5C5hvq/jekzvVocUV1tSfSTCwUxPxBqEYv76E8sKWmYYv9DNUU3z4MGhLTS/MDjYZefKqGMDI76eBXyQyoHNvnTZWHEB5MnDqmRQi4= Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB278.namprd05.prod.outlook.com (10.141.64.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 26 Sep 2017 18:54:33 +0000 Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::1c83:de31:8f02:be]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::1c83:de31:8f02:be%17]) with mapi id 15.20.0035.009; Tue, 26 Sep 2017 18:54:33 +0000 From: Kent Watsen To: Eliot Lear , "opsawg@ietf.org" Thread-Topic: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 Thread-Index: AQHTMm66/v4743IIqkCfKQplTRrUO6LGHN6AgACiJICAAIragA== Date: Tue, 26 Sep 2017 18:54:33 +0000 Message-ID: References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> In-Reply-To: <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN1PR05MB278; 6:kXfTqgEbfomDEb1NVnxpiWBXt7UmA4gdK87k6EHeGF/chje9NwCr+THDXkjHzv69PckQ6SoTR/YI6xMdN3icM8I8hVSJItp+TZaTcEdde0XSh5i4Z/pIz7iAYiwy5Y+PqDFQRaRQaABHIGuI/IpDihJyKlEfTopBHOCu/aldtULV5EDBftQpDzLXbb3XWW/iBdrka++4jEBSEq+v7gEtfGUs25cCImoCb/lLhGTwuQ8YQ7cYP+D10vu5brWzadbFLz82iCQGGdv71g3DsFPpwUwyOwefHZlLO5OjXKQ/mYZ1g4D5AoxULHws/djhTS1k3bN/LobSxA7NVSG700Zvig==; 5:fKfj3f6+OutQtnwt0njKHaE3fZGlX+tk8n426k4IwavuNZs6XBxIt9JAnGKRNfInOG5H21RlqpYT6ZQfUeSUjHV2fz8PDLPcOkjE3Cwc88VyYu4wux5GzWJ/gcV+AWCg+/R5P0UIeGJ0/4laUTDtPw==; 24:B7KqKmBWM94D58U7HrZDLuTulWTcWvYXIKPQ8DZCkWVkNWqE9shQmTohyOdTg4vkVgl0rzHHk+IeEOM7Wa+Q8qBDKq2DqVpu+w9HI9hAbXk=; 7:ZyIsbQI11yfwmYlO8bVtPBwvURnZsZHV0BmjmnJoCYkSz+UHZQoZUEU2qZYsYbLhTsSjJ7AyvwEh8c3dk7tplbpQh6717FEkIF1BWk18y7y96M/TV9BCKQIhJLwpEapwT6k1T/hYLJ5MnpIOPLfeXAvDjv1NN/9CXGW6a0jIsrG0pAl1PhS87MAcQ5C4ubUjQlhEjQhKae9bytBBHOXSGC48e9chgCM3Om2VKjILz50= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0b58ab01-be80-47b7-a64e-08d5051006bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB278; x-ms-traffictypediagnostic: BN1PR05MB278: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(788757137089)(266576461109395); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB278; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(83506001)(5250100002)(97736004)(68736007)(8936002)(2906002)(66066001)(6116002)(3846002)(230783001)(82746002)(81156014)(316002)(106356001)(478600001)(6506006)(102836003)(36756003)(3660700001)(99286003)(53936002)(3280700002)(83716003)(5660300001)(6486002)(229853002)(86362001)(101416001)(58126008)(33656002)(2900100001)(2501003)(6512007)(6246003)(54356999)(76176999)(305945005)(189998001)(6436002)(81166006)(7736002)(25786009)(14454004)(50986999)(110136005)(8676002)(105586002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB278; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <898A086FAA645E4F9B9D0345E3F5D3AA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 18:54:33.2719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB278 Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 18:54:37 -0000 DQpIaXlhIGFnYWluLA0KDQo+PiBJbiBteSBwcmV2aW91cyByZXZpZXcsIEkgaGFkIGFza2VkIGFi b3V0IGhvdyBNVUQgaW50ZXJzZWN0cyB3aXRoIG15IHplcm90b3VjaCBkcmFmdCwgd2hpY2ggaGFz IHRoZSBkZXZpY2UgcmVhY2hpbmcgb3V0IHRvIGVpdGhlciBhIHdlbGwta25vd24gSW50ZXJuZXQt YmFzZWQgb3IgZGVwbG95bWVudC1zcGVjaWZpYyBIVFRQUyByZXNvdXJjZS4gIEJ1dCB0aGUgbmVl ZCB0byByZWFjaCBvdXQgdG8gdGhlc2UgSFRUUFMgcmVzb3VyY2VzIHNob3VsZCBvbmx5IGJlIGR1 cmluZyB0aGUgZGV2aWNlJ3MgaW5pdGlhbCBib290c3RyYXAgcHJvY2Vzcy4gIFlvdSBzYWlkIGJl Zm9yZSBzb21ldGhpbmcgYWJvdXQgYW4gaW5pdGlhbCBwb2xpY3kgZm9sbG93ZWQgYnkgYW4gb24t Z29pbmcgcG9saWN5LCBidXQgSSBkb24ndCBzZWUgdGhhdCBoZXJlLiAgRGlkIEkgbWlzcyBpdD8N Cg0KPiBJIHRoaW5rIHNvLiAgVGhlcmUgaXMgdGhlIG5vdGlvbiBvZiAg4oCcY2FjaGUtdmFsaWRp dHnigJ0gd2l0aCB0aGUgaWRlYSBiZWluZyB0aGF0IG9uZSBjYW4gY2hhbmdlIHRoZSBwb2xpY3kg ZnJvbSB0aW1lIHRvIHRpbWUuICBUaGUgcG9saWN5IGRvZXMgbm90IGl0c2VsZiBleHBpcmUsIGJ1 dCB0aGUgaWRlYSB3aXRoIOKAnGNhY2hlLXZhbGlkaXR54oCdIGlzIHRoYXQgbXVkIGNvbnRyb2xs ZXJzIHNob3VsZG4ndCBwZXN0ZXIgdGhlIG11ZCBmaWxlIHNlcnZlciBhbnkgc29vbmVyIHRoYW4g dGhhdCBwZXJpb2QuDQoNCklJVVlDLCB5b3UncmUgdGhpbmtpbmcgdGhhdCB0aGUgc3dpdGNoIHdv dWxkIHJlY2VpdmUgdXBkYXRlZCBjb25maWd1cmF0aW9uIG92ZXIgdGltZTsgYW4gaW5pdGlhbCBj b25maWd1cmF0aW9uIHdvdWxkIGFsbG93IHRoZSBUaGluZyAodG8gdXNlIHRoZSB3b3JkIGluIHRo ZSBkcmFmdCwgbm90IG15IHByZWZlcmVuY2UpIHRvIGFsbG93IHRoZSBib290c3RyYXBwaW5nIGZs b3dzIGFuZCwgdGhlbiBsYXRlciwgYSBzZWNvbmQgY29uZmlndXJhdGlvbiB0aGF0IHdvdWxkIHJl ZmxlY3Qgbm9ybWFsIG9wZXJhdGlvbi4gIFRoaXMgaXMgbm90IChJTU8pIGEgTVVELWZpbGUgdGhp bmcsIHNvIG11Y2ggYXMgYSBjb250cm9sbGVyLXRoaW5nLCBhcyB0aGUgTWFudWZhY3R1cmVyIHdv dWxkIGhhdmUgbm8gYXdhcmVuZXNzIG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgZGV2 aWNlcyBvciBiZSBhYmxlIHRvIHNlcXVlbmNlIHRoZSByZWxlYXNlIG9mIE1VRCBmaWxlcyBhY2Nv cmRpbmdseS4gIEZvciB0aGlzIHRvIHdvcmssIEkgdGhpbmsgdGhlIE1VRCBmaWxlIHdvdWxkIG5l ZWQgdG8gaGF2ZSBib3RoIHN0YXRlcyBidWlsdCBpbnRvIGl0LCBzbyB0aGVuIHRoZSBjb250cm9s bGVyIGNhbiBpbml0aWFsbHkgc2VsZWN0IHRoZSBmaXJzdCBzdGF0ZSBhbmQgdGhlbiBsYXRlciwg cGVyaGFwcyBiYXNlZCBvbiBjcml0ZXJpYSBvdGhlciB0aGFuIGEgdGltZW91dCwgc2VsZWN0cyB0 aGUgc2Vjb25kIHN0YXRlLiAgTm90ZSwgYnkgInNlbGVjdCIgSSBtZWFuICJzZWxlY3QgYW5kIHB1 c2ggdXBkYXRlZCBjb25maWcgdG8gc3dpdGNoIGJhc2VkIG9uIi4uLg0KDQoNCg0KPj4gV2hhdCBp cyB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgc3dpdGNoLCB3aGVuIG5vIE1VRCBmaWxlIGlz IGF2YWlsYWJsZS4gIFNlY3Rpb24gNCBzYXlzICJBbnl0aGluZyBub3QgZXhwbGljaXRseSBwZXJt aXR0ZWQgaXMgZGVuaWVkIiwgYnV0IHRoYXQgc2VjdGlvbiBkaXNjdXNzZXMgdGhlIHByb2Nlc3Np bmcgb2YgYSBNVUQgZmlsZSwgbm90IHdoZW4gdGhlcmUgaXMgbm8gTVVEIGZpbGUuICBJJ20gYXNz dW1pbmcgdGhlIGdvYWwgaXMgZm9yIHRoZSBzd2l0Y2ggdG8gZGVueSB0cmFmZmljIChmYWlsIGNs b3NlKSB3aGVuIG5vIE1VRCBmaWxlIGNhbiBiZSBmb3VuZCwgYnV0IEkgd29ycnkgdGhhdCB0aGlz IG1heSBsZWFkIHRvIHVuaGFwcHkgb3BlcmF0b3JzIGFzIG5ldyBwcm9kdWN0IGRlcGxveW1lbnRz IChub3QgaGF2aW5nIE1VRCBzdXBwb3J0KSBhcmUgY29uc3RhbnRseSBibG9ja2VkIGJ5IHRoZSBz d2l0Y2hlcy4uLiANCg0KPiBGYWlyIHF1ZXN0aW9uLiAgSWYgbm8gTVVEIGZpbGUgaXMgYXZhaWxh YmxlLCBpdCdzIGEgZGVwbG95bWVudCBkZWNpc2lvbiBhcyB0byBob3cgdG8gcHJvY2VlZCAobXVj aCBhcyBpdCBpcyB0b2RheSkuICBUaGUgaW50ZW50IG9mIFNlY3Rpb24gNCBpcyB0aGF0IG9uZSBz aG91bGQgYXNzdW1lIHRoYXQgdGhlIGVuZCBvZiBhbiBBQ0wgaXMgdGhlIEpTT04gZXF1aXZhbGVu dCBvZiAiZGVueSBhbnkiLiAgU2hvdWxkIEkgY2xhcmlmeSB0aGlzPw0KDQpSaWdodCwgdGhlIEFD TCBpcyBkZWZhdWx0IGRlbnkgYWxsLCBidXQgdGhhdCBpcyB0aGUgQUNMIHdpdGhpbiB0aGUgTVVE IGZpbGUgdGhhdCB0aGUgY29udHJvbGxlciAobm90IHRoZSBzd2l0Y2gpIHByb2Nlc3Nlcy4gTG9v a2luZyB0byBzZWN0aW9uIDEuOCwgaXQgc3RhcnRzIG9mZiB3aXRoICJUaGluZyBlbWl0cyBVUkwi LiAgSW4gdGhpcyBjYXNlLCBpdCBkb2Vzbid0IGhhcHBlbiwgdGhlIFRoaW5nIGRvZXNuJ3QgaW1w bGVtZW50IHRoZSBSRkMuICBJbiBvcmRlciBmb3Igc29sdXRpb25zIHRvIGNsYWltIGNvbmZvcm1h bmNlLCBJIHRoaW5rIHRoZSBzd2l0Y2ggd291bGQgaGF2ZSB0byBoYXZlIGEgIm11ZC1tb2RlIiB3 aGVyZWJ5IGl0IHJlZnVzZWQgcGFzcyB0cmFmZmljIG9uIGEgcG9ydCB1bmxlc3MgYSBtdWQtY29u dHJvbGxlciBnYXZlIGl0IHRoZSBjb25maWcgdG8gZG8gc28uICBJZiB0aGlzIGlzIGluZGVlZCB0 aGUgaW50ZW50LCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xlYXIgYWJvdXQgaXQuDQoN Cg0KDQo+PiBCdWlsZGluZyB1cG9uIHRoZSBhYm92ZSB0d28gY29tbWVudHMsIEknbSBhc3N1bWlu ZyB0aGF0IHRoZSBzd2l0Y2ggY291bGQgYmUgY29uZmlndXJlZCB0byAqYWx3YXlzKiBhbGxvdyBh Y2Nlc3MgdG8gc29tZSByZXNvdXJjZXMsIGV2ZW4gd2hlbiBubyBNVUQgZmlsZSBpcyBmb3VuZC4g IElzIHRoaXMgd2hhdCB5b3UgaGFkIGluIG1pbmQ/DQoNCj4gWWVzLiAgSSBjYW4gY2xhcmlmeSB0 aGlzIGFzIHdlbGwuDQoNCk9rYXksIGJ1dCB0aGVuIHRoaXMgc2VlbXMgdG8gYmUgYXQgb2RkcyB3 aXRoIHRoZSBwcmV2aW91cyBjb25jbHVzaW9uLCB3aGljaCBJIG1heSBoYXZlIGdvdHRlbiB3cm9u Zy4gIFRvIG1lLCBpdCBzZWVtcyB0aGF0IGVpdGhlciB0aGUgc3dpdGNoIGZhaWxzLWNsb3NlZCAo bXVkIG1vZGUpIG9yIG5vdCAobm9ybWFsIG1vZGUpLCBpcyB0aGVyZSByb29tIGZvciBhbnl0aGlu ZyBlbHNlPw0KDQoNCg0KDQoNCj4+IE5pdHM6DQoNCj5JJ2xsIGNoZWNrIGVhY2ggb2YgdGhlc2Us IGJ1dCB0aGUgdGVybSAiVGhpbmciIGlzIGludGVuZGVkIHRvIGJlIHVzZWQNCmNvbnNpc3RlbnRs eSwgYW5kIGNoYW5nZXMgbWFkZSB3ZXJlIGluIHJlc3BvbnNlIHRvIFJvYmVydCBTcGFya3MnDQpy ZXZpZXcuICBJJ2xsIG1ha2Ugc3VyZSB0aGF0IGVhY2ggaXMgYXMgaW50ZW5kZWQuDQoNCk9rYXks IGJ1dCBJIHRoaW5rIGl0IHB1dHMgb2ZmIHRoZSB3cm9uZyBzaWduYWxzIGFuZCBtYXJnaW5hbGl6 ZXMgdGhlIHNvbHV0aW9uIGFzIGEgd2hvbGUuICBCdXQsIGlmIHlvdSBpbnNpc3QsIGF0IGxlYXN0 IGJlIHN1cmUgdG8gZGVmaW5lICJUaGluZyIgYmVmb3JlIGZpcnN0IHVzZSBpbiB0aGUgZG9jdW1l bnQgKHRoaXMgaXMgbm90IHRoZSBjYXNlIGN1cnJlbnRseSkgYW5kIGdpdmUgaXQgYSBkZWZpbml0 aW9uIHRoYXQgY2xlYXJseSBpbmRpY2F0ZXMgdGhhdCBpdCBhcHBsaWVzIHRvIGFsbCBuZXR3b3Jr IGVsZW1lbnRzLCBub3QganVzdCBsaWdodGJ1bGJzLCBldGMuDQoNCg0KDQoNCj4+IHMxLjM6ICJU aGluZyIgaGVyZSBpcyBkaXN0cmFjdGluZy4gIENhbiB5b3UgY2hhbmdlIHRvICJkZXZpY2UiPyAN Cj4+IHMxLjQ6IHJlcGxhY2UgIk91ciB3b3JrIiB3aXRoIHNvbWV0aGluZyBsaWtlICJUaGUgc29s dXRpb24iPw0KPj4gczEuNTogaW5jb25zaXN0ZW50IGNhcGl0YWxpemF0aW9uIGluIG1hbnVmYWN0 dXJlciBjbGFzcyBuYW1lcw0KPj4gczEuNjogSSBzZWUgVGhpbmcgaGVyZSB0b28uICBJcyB0aGlz IG5lY2Vzc2FyeT8gIElzbid0IHRoZSBzb2x1dGlvbiBmb3Igbm9uLUlvVCBkZXZpY2VzIHRvbz8N Cj4+IHMxLjY6IHlvdSBtaWdodCB3YW50IHRvIGluY2x1ZGUgYSByZWYgdG8gUkZDIDgxNzQsIHBl ciBSRkMgODE3NC4NCj4+IHMxLjc6IHRoZSB0ZXh0IHRhbGtzIGFib3V0IE5NU3MgYW5kIHdlYnNp dGVzLCBidXQgSSB0aGluayB5b3UgbWVhbiBjb250cm9sbGVyIGFuZCBtdWQgc2VydmVyLCByaWdo dD8NCj4+IHMxLjg6ICM3LCBob3cgaXMgImRpc2Nvbm5lY3QiIGRlZmluZWQ/DQo+Pg0KPj4gPHNr aW1tZWQgYSBidW5jaCBoZXJlPg0KPj4NCj4+IHJlZ2FyZGluZyBzMy40IGFuZCBzMy43LCBpcyBp dCBwb3NzaWJsZSB0byByb2xsICdtYXNhLXNlcnZlcicgaW50byBhbiBleHRlbnNpb24/ICBBbHNv LCBub3RlIHRoYXQgdGhlIGJyc2tpLTA3IGRyYWZ0IHNheXMgbm90aGluZyBhYm91dCB0aGlzIGRy YWZ0LCBzbyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHR3byBpcyB1bmNsZWFyLiAgSSdk IGxpa2UgdG8gc2VlIHJlZmVyZW5jZXMgdG8gYnJza2kgcmVtb3ZlZCBmcm9tIHRoaXMgZHJhZnQg aWYgcG9zc2libGUsIHdpdGggYSBwcmVmZXJlbmNlIGZvciB0aGUgYnJza2kgZHJhZnQgdG8gZGVm aW5lIGl0cyBvd24gImV4dGVuc2lvbiIgaWYgZGVzaXJlZC4NCg0KPiBJIGFtIHRlbXB0ZWQgdG8g YWdyZWUuICBUaGlzIGlzIHRoZSBvbmUgdGhhdCBtYXkgbmVlZCBqdXN0IGEgZGF5IG9yIHR3byB0 byBjb25zaWRlciwgcGVyaGFwcyB3aXRoIGEgY29udmVyc2F0aW9uIHdpdGggTWF4IGFuZCB0aGUg QU5JTUEgZm9say4NCg0KQWNrLg0KDQoNCg0KPj4gPHNraW1tZWQgYSBidW5jaCBtb3JlIGhlcmU+ DQo+Pg0KPj4gczE3OiBzL1dhdHNvbi9XYXRzZW4vICAgIC0gYW4gYWxsIHRvbyBjb21tb24gdHlw byBpbiBteSBsaWZlISAgOykNCj4+DQo+IERlZXBlc3QgYXBvbG9naWVzLiAgSSBrbm93IGhvdyB5 b3UgZmVlbC4NCj4NCj4gRWxpb3QNCg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCg== From nobody Tue Sep 26 13:18: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 C67EE134457 for ; Tue, 26 Sep 2017 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 xVTrwQ6uu9gf for ; Tue, 26 Sep 2017 13:18:02 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29859134454 for ; Tue, 26 Sep 2017 13:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H9HG++nxKr2E+22ujNXgU4C7EMBEuPmaOsUDDJ4UvDQ=; b=H+PO7MLzZQkthuWxHz5XYIe/fX1eMbGPwdEjwZLnKjXppjsFTTAe2hkWLRW/8xxdyIroDrGrW12qFCWXnUq8WH/Ce8KUpsiiUKBS4EERxidIDc56wHVnL/4JQBgN3+z7oR6LHORhkmMAKx5I8xqiiz2S50R12LxKmkJCiz3v1II= Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB277.namprd05.prod.outlook.com (10.141.64.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 26 Sep 2017 20:17:54 +0000 Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::1c83:de31:8f02:be]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::1c83:de31:8f02:be%17]) with mapi id 15.20.0035.009; Tue, 26 Sep 2017 20:17:54 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" , Eliot Lear CC: "opsawg@ietf.org" Thread-Topic: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 Thread-Index: AQHTMm66/v4743IIqkCfKQplTRrUO6LGHN6AgACiJICAAMXEgP//3F+A Date: Tue, 26 Sep 2017 20:17:54 +0000 Message-ID: <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net> References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> <8500A252-4867-41E3-806D-DD700953A777@cisco.com> In-Reply-To: <8500A252-4867-41E3-806D-DD700953A777@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN1PR05MB277; 6:T4ITEIg42PR0oAuqBPjiJOWELPBC3wKz2ADogTy5AbhVh0j54x9lHBxO4BDM0LGjfasHNKaSlxXJqN4NsWeBKG9A0NG+G0cvv/4oUDTbGUmXDg+19a2kiqv4HF+5ki6jaYVFTvtv0QodJCnRtyDSzNNu2fl8bz5OlTMv3y2xTfX+WO1dcpjR5fvGIU5ePLp1ww0onBPNfdZ6annpUfSVB/oke84zC4HmJJtMfviirgBGfi795vlPUKl806+Pba4Z3WY6a8P2H1gcPk681xkzEYihW/ITPRV9HX/OYhi1A4EffzeoZnl+60g6xo/1VQ6Kyx+U3W56wePHB1fEtuX4Pw==; 5:FPXvsk9OB/AU9zhCaOQzJfLymeA7KtPAfXtSJZf+8KXwabke7xRoDPQs4eHosCnz6GtzCSOTJOu9hjRnD4t5eq4FP/t4UHDPLz7ICOaLZ/RdypO2mE8I7Qp299Na08xRGmq67FCb+xxA7WPiZJnCMA==; 24:3BUcZ1dJFAMxP0tx9rfxCkM0EmQyEC4VmLBOyq9YbhQlquOMBWQeisg61H+24VEHnzN70gmAyYPcOLftqPP5aN/q9iRK8r6Fpu1h4RQRVNI=; 7:AJ5TKA743v6IUoV00Pht0Ccf4eFKPohxZz8BKAJxX6TLEXAz44jQ+O8febAbewn84ikgEgqOaWjv2u9HWnStZyVsA7fmhQ8dnL3vrV0CNVd/EywspoTvDY1v04EpTnd6IK+XOKzMtQ2SlH37SalfGLSvY6fPSs2XzSXxuHjMwyMDH0GWAIUY4UxytkcVIwRNUk+IoNBiyEx1C8hbhsXxcer8OjjVExAaQCvLtp2GhrM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9e4480d1-3f40-424a-870d-08d5051babb9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB277; x-ms-traffictypediagnostic: BN1PR05MB277: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB277; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(51444003)(189002)(199003)(8936002)(81156014)(189998001)(966005)(83506001)(68736007)(83716003)(66066001)(3280700002)(316002)(33656002)(6306002)(2900100001)(478600001)(230783001)(2906002)(6506006)(102836003)(86362001)(110136005)(14454004)(6512007)(99286003)(229853002)(575784001)(3846002)(82746002)(5250100002)(76176999)(25786009)(50986999)(93886005)(81166006)(97736004)(58126008)(6246003)(4326008)(6116002)(5660300001)(105586002)(36756003)(101416001)(6436002)(6486002)(3660700001)(54356999)(8676002)(2950100002)(53936002)(7736002)(106356001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB277; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <486B3E4D56BF184D82012551956710DC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 20:17:54.5330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB277 Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 20:18:05 -0000 DQpIaSBNYXgsDQoNCg0KPiBUaGUgcmVsZXZhbnQgaW50ZXJzZWN0aW9uIHdvdWxkIGJlIGlmL2hv dy93aGVuIE1VRCBkZW554oCZcyBvciBhbGxvd3MgYSBjb25uZWN0aW9uIHRvIHRoZSBuZXRjb25m IHplcm90b3VjaCBib290c3RyYXAgc2VydmljZSBhcyBkZXNjcmliZWQgaW46IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf aHRtbF9kcmFmdC0yRGlldGYtMkRuZXRjb25mLTJEemVyb3RvdWNoLTJEMTctMjNzZWN0aW9uLTJE NC40JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9D SSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT16UkpOQnhX Zko4VVdLbE5mQllFMi11azgwcXBsRl8wM21ZWVRzVFVLMk1jJnM9VW00a0FMSjQ1Vkx6TDRSWUFa aW1qRTBpMHZzUERuOGZqZGJOYnhwT3V4RSZlPSAgPw0KDQoNClllcyBhbmQgbm8uICBZZXMsIGlu IHRoYXQgaW5kZWVkIHRoZSB6ZXJvdG91Y2ggYm9vdHN0cmFwIHNlcnZlciBtYXkgYmUgZWl0aGVy IGEgd2VsbC1rbm93biBJbnRlcm5ldC1iYXNlZCByZXNvdXJjZSAoZS5nLiwgZGV2aWNlcyBhcmUg aGFyZGNvZGVkIHdpdGggaXRzIGxvY2F0aW9uIGFuZCB0cnVzdCBjcmVkZW50aWFscykgb3IgYSBk ZXBsb3ltZW50LXNwZWNpZmljIHJlc291cmNlIChlLmcuLCBkZXZpY2VzIGxlYXJuIGFib3V0IGl0 cyBsb2NhdGlvbiBhbmQgdHJ1c3QgY3JlZGVudGlhbHMgZHluYW1pY2FsbHkpLiAgTm8sIGluIHRo YXQgdGhlIHplcm90b3VjaCBzb2x1dGlvbiBjYW4gYWxzbyBsZXZlcmFnZSBESENQLCBETlMsIGFu ZCBwb3RlbnRpYWxseSBvdGhlciBUQkQgcmVzb3VyY2VzIGFzIHdlbGwuICBJJ20gbm90IHNwZWNp ZmljYWxseSBjYWxsaW5nIG91dCBESENQIGFuZCBETlMgaGVyZSB0aG91Z2ggYmVjYXVzZSB0aGUg TVVEIGRyYWZ0IGFscmVhZHkgaW1wbGljaXRseSBhbGxvd3MgYWNjZXNzIHRvIHRob3NlIHR3byBy ZXNvdXJjZXMuICBNeSBpbnRlbnQgd2FzIHRvIGp1c3QgdXNlIHplcm90b3VjaCBhcyBhbiBleGFt cGxlIGhlcmUsIG90aGVyIG1lY2hhbmlzbXMgKHBvdGVudGlhbGx5IG5vdCByZWxhdGVkIHRvIGJv b3RzdHJhcHBpbmcpIG1heSBoYXZlIHNpbWlsYXIgY29uY2VybnMuDQoNCg0KPiBJIHRoaW5rIHRo ZSBNVUQg4oCYY29udHJvbGxlcuKAmSBvciDigJhteS1jb250cm9sbGVy4oCZIG1lY2hhbmlzbSB3 b3VsZCBiZSB1c2VkIHRvIGVuc3VyZSBkZXZpY2VzIG9mIHRoaXMgY2xhc3MgY2FuIGFjY2VzcyB0 aGUgaW5kaWNhdGVkIOKAnGludGVybmV0LWJhc2Vk4oCdIG9yIOKAnGRlcGxveW1lbnQtc3BlY2lm aWMgSFRUUFMgcmVzb3VyY2XigJ0gYm9vdHN0cmFwLXNlcnZlcj8NCg0KTWF5YmU/IFRvIGJlIGhv bmVzdCwgdGhlIHVzZSBvZiB0aGUgJ2NvbnRyb2xsZXInIGFuZCAnbXktY29udHJvbGxlcicgY2xh c3NlcyBhcmVuJ3QgdmVyeSBjbGVhciB0byBtZS4gIFRoZXkncmUgbm90IHBhcnQgb2YgdGhlIE1V RCBmaWxlIGV4YW1wbGUgaW4gc2VjdGlvbiA4LiAgQXJlIHlvdSB0aGlua2luZyB0aGF0IHRoZSBN YW51ZmFjdHVyZXIgd291bGQgcHJlcG9wdWxhdGUgJ2NvbnRyb2xsZXInIHdpdGggaXRzIEludGVy bmV0LWJhc2VkIHJlc291cmNlIGFuZCB0aGF0IGRlcGxveW1lbnRzIHdvdWxkIHBvcHVsYXRlIHRo ZSAnbXktY29udHJvbGxlcicgd2l0aCB0aGVpciBkZXBsb3ltZW50LXNwZWNpZmljIHJlc291cmNl cz8NCg0KDQo+IFNpbWlsYXJseSBmb3IgYW5pbWEgZGV2aWNlcyBtaWdodCBiZSBsaW1pdGVkIHRv IG9ubHkgY29udGFjdGluZyB0aGVpciBsb2NhbCBCUlNLSSByZWdpc3RyYXIgdmlhIOKAmG15LWNv bnRyb2xsZXInPw0KDQpJIGd1ZXNzLCBiYXNlZCBvbiB0aGUgYWJvdmUsIGJ1dCB0aGlzIGlzIHdo YXQgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kLg0KDQoNCj4gQXNzdW1pbmcgbXkgaW50ZXJwcmV0 YXRpb24gaXMgY29ycmVjdCBJIGRvbuKAmXQgc2VlIGFueSBjaGFuZ2UgbmVlZGVkIGluIHRoZSB0 ZXh0IGFib3V0IHRoaXMuIA0KDQpXZWxsLCBhdCBhIG1pbmltdW0gaXQgd291bGQgbmVlZCB0byBi ZSBtb3JlIGNsZWFybHkgZXhwbGFpbmVkLiAgQWxzbywgSSB0aGluayB0aGF0IHRoZSBicnNraSBk cmFmdCBuZWVkcyB0byBleHBsYWluIGhvdyB0aGlzIGZpZWxkIGlzIGludGVuZGVkIHRvIGJlIHVz ZWQgYmVmb3JlIHRoaXMgZmllbGQncyBleGlzdGVuY2UgY2FuIGJlIGZ1bGx5IGp1c3RpZmllZC4g IA0KDQpBcyBhbiBhc2lkZSwgd2h5IGFyZSB0aGVzZSBmaWVsZHMgY2FsbGVkICJbbXktXWNvbnRy b2xsZXIiPyAtIG1heWJlIHNvbWV0aGluZyBsaWtlICJyZXNvdXJjZSIgd291bGQgYmUgbW9yZSBn ZW5lcmFsbHkgYXBwbGljYWJsZSwgYXMgbm90IGV2ZXJ5dGhpbmcgaXMgYSBjb250cm9sbGVyPw0K DQoNCg0KPiBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaXMgdmFsaWQgYW5kIGNvcnJlY3QuIEkg dm90ZSBhZ2FpbnN0IGFueSBjaGFuZ2VzIGluIHRoaXMgYXJlYTogDQo+DQo+IERpc3RyaWJ1dGlv biBvZiB0aGUgTUFTQSBzZXJ2ZXIgVVJMIGlzIGluZm9ybWF0aXZlIHRvIHRoZSBsb2NhbCBuZXR3 b3JrIGluZnJhc3RydWN0dXJlLiBTdXBwb3J0IGZvciB0aGlzIG1lY2hhbmlzbXMgYWxsb3dzIGEg bG9jYWwgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB0byBrbm93IHdoaWNoIE1BU0Egc2VydmljZSB0 byBjb250YWN0IGZvciB0aGlzIGRldmljZS4gQWxsb3dpbmcgdGhpcyB3aXRoaW4gTVVEIHByb3Zp ZGVzIGFuIG9wdGltaXphdGlvbiBvcHBvcnR1bml0eSBmb3IgdmVuZG9ycyB0aGF0IGFyZSBhbmlt YSBCUlNLSSBjb21wYXRpYmxlLiBUaGV5IGNhbiBlaXRoZXIgaW1wbGVtZW50IHRoZSBNQVNBIGV4 dGVuc2lvbiBVUkwsIGFuZCBhbnkgb3RoZXIgdXJscywgd2l0aGluIHRoZWlyIGluaXRpYWwgZGV2 aWNlIGlkZW50aXR5IC1vci0gdGhleSBjYW4gaW1wbGVtZW50IG9ubHkgdGhlIE1VRCBVUkwgZXh0 ZW5zaW9uLiBTcGFjZSBhbmQgY2hhbmdlcyB0byB0aGUgZGV2aWNlIGlkZW50aXR5IGNlcnRpZmlj YXRlIGFyZSBsaW1pdGVkIGFuZCBkaWZmaWN1bHQgc28gYW4gaW5kaXJlY3Rpb24gdGhyb3VnaCB0 aGUgTVVEIHNlcnZpY2UgaXMgYSB2YWx1YWJsZSBhcHByb2FjaC4NCg0KSSdtIG5vdCBkaXNwdXRp bmcgdGhlIHZhbHVlIG9mIGJlaW5nIGFibGUgdG8gcmVsYXkgc3VjaCBpbmZvcm1hdGlvbiAodGhv dWdoIGl0J3MgbWlzc2luZyBpbiB0aGUgYnJza2kgZHJhZnQpLCBJJ20ganVzdCB0aGlua2luZyB0 aGF0IHJhdGhlciB0aGFuIGhhcmRjb2RlIHNvbWV0aGluZyBpbnRvIHRoZSBiYXNlIE1VRCBmaWxl IGRlc2NyaXB0aW9uLCB0aGF0IHRoZSBzYW1lIGNhbiBiZSBkb25lIHVzaW5nIHRoZSBleHRlbnNp b24gbWVjaGFuaXNtIHRoYXQgdGhpcyBkcmFmdCBpcyBkZWZpbmluZyBpbnN0ZWFkLiAgU2FtZSBk YXRhLCBqdXN0IGRlY2xhcmVkIGRpZmZlcmVudGx5LiAgSWYgdGhlcmUgaXMgYSBjbGFpbSB0aGF0 IGl0IGlzIHRvbyBoYXJkLCB0aGVuIEknZCByZWNvbW1lbmQgc3BlbmRpbmcgbW9yZSB0aW1lIGV4 YW1pbmluZyB0aGUgZXh0ZW5zaW9uIG1lY2hhbmlzbSBub3cgcmF0aGVyIHRoYW4gYWZ0ZXIgdGhp cyBiZWNvbWVzIGFuIFJGQy4NCg0KVGhhdCBzYWlkLCBtYXliZSB3ZSBzaG91bGQgY2hhbGxlbmdl IHRoZSBuZWNlc3NpdHkgb2YgdGhpcyBmaWVsZCwgb3IgYXQgbGVhc3QgZXhhbWluZSB0byB3aGF0 IGVuZCB0aGlzIGlkZWEgaXMgdmFsaWQuICBGaXJzdCwganVzdCB0byB0aHJvdyBpdCBvdXQgdGhl cmUsIHdoeSBub3QgYWxzbyBhZGQgYSAiemVyb3RvdWNoLXNlcnZlciIgZmllbGQ/ICBJJ20gZ3Vl c3NpbmcgdGhhdCB0aGlzIGZpZWxkIGVuYWJsZXMgbGF6eS1iaW5kaW5nIHNvLCByYXRoZXIgdGhh biBhIGRldmljZSBoYXJkY29kaW5nIHN1Y2ggaW5mbywgaXQgYmUgZGV0ZXJtaW5lZCBvcGVyYXRp b25hbGx5LiAgT3RoZXIgcmVzb3VyY2VzIGFwcGx5IHRvbywgcmlnaHQ/ICBTb21ldGltZXMgZGV2 aWNlcyBuZWVkIHRvIHJlYWNoIG91dCB0byB3ZWxsLWtub3duIHJlc291cmNlcyBmb3IgZS5nLiwg YW50aS14IHNpZ25hdHVyZSBwYWNrcy4gIFdvdWxkIHRoZSBsb2NhdGlvbiBmb3IgdGhlc2UgcmVz b3VyY2VzIGFsc28gYmUgbWFwLWFibGUgdmlhIGEgTVVEIGZpbGU/ICBOb3RlIHRoYXQgSSdtIG5v dCBhY3R1YWxseSBhZHZvY2F0aW5nIGZvciBhbnkgb2YgdGhpcyBhdCB0aGUgbW9tZW50LCBqdXN0 IHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQncyBpbnRlbmRlZCBoZXJlLg0KDQoNCg0KPiBUbyBt YWtlIHRoaXMgZXh0ZW5zaWJsZSBlaXRoZXIgQlJTS0kgKGV0IGFsbCApIG5lZWRzIHRvIGV4dGVu ZCB0aGUgeWFuZyBtb2RlbHMgbXVjaCB0aGUgd2F5IGl0IGRvZXMgd2l0aCB0aGUgdm91Y2hlciBk b2N1bWVudCBvciB0aGVyZSBuZWVkcyB0byBiZSBhIE1VRCBzcGVjaWZpYyBleHRlbnNpb24gbWV0 aG9kIChpYW5hIG5hbWVzcGFjZSBkZWNsYXJlZCB3aXRoaW4gTVVEPykgb3Igc29tZXRoaW5nLiBJ IGRvbuKAmXQgc2VlIGhvdyB0aGF0IGZpdHMgdG9nZXRoZXIgY2xlYW5seSBhbmQgZG9u4oCZdCBz ZWUgc29sdmluZyB0aG9zZSBxdWVzdGlvbnMgYXMgbmVjZXNzYXJ5IGF0IHRoaXMgdGltZS4NCg0K WWVwLCB0aGlzIGlzIHdoYXQgSSB0aG91Z2h0IHlvdSBtaWdodCBzYXkuICBZZXMsIGl0IG1heSBu b3QgYmUgY2xlYW4sIGJ1dCBpdCBzaG91bGQgYmUgdW5kZXJzdG9vZCwgcmlnaHQ/DQoNCg0KDQoN ClNlcGFyYXRlbHksIHdobyBnZW5lcmF0ZXMgdGhlIE1VRCBmaWxlcz8gIElzIGl0IHRoZSBNYW51 ZmFjdHVyZXIgb3Igc29tZW9uZSBlbHNlPyAgU2VjdGlvbiAxMi4xIGRvZXNuJ3Qgc2F5LiAgU2Vj dGlvbiAxMi4yIHNheXMgdGhhdCB0aGUgTVVEIGNvbnRyb2xsZXIgdmVyaWZpZXMgdGhlIHNpZ25h dHVyZSB0byBhIGtub3duIHRydXN0IGFuY2hvciwgYnV0IGl0J3MgdW5jbGVhciBob3cgdGhlc2Ug VEFzIGJlY2FtZSBrbm93bi4gIEVsc2V3aGVyZSB0aGUgZHJhZnQgc2F5cyBNVUQgY2FuIHByb3Zp ZGUgYSBtZWFucyB0byBhZGRyZXNzIHNvbWUgdnVsbmVyYWJpbGl0aWVzIGluIGRldmljZXMgdGhh dCBubyBsb25nZXIgc3VwcG9ydGVkIGJ5IHRoZWlyIG1hbnVmYWN0dXJlciwgc28gSSdtIGd1ZXNz aW5nIHRoYXQgaXQncyB0aGUgbGF0dGVyLCBub3QgdGhlIGZvcm1lci4gICBEb2VzIHRoaXMgaW50 cm9kdWNlIGEgU2VjdXJpdHkgcmlzayAoZGVncmFkYXRpb24gYXR0YWNrKSBvZiBhbnkgc29ydCB0 byB0aGUgYnJza2kgYm9vdHN0cmFwcGluZyBwcm9jZXNzPw0KDQoNClRoYW5rcywNCktlbnQNCg0K DQo= From nobody Tue Sep 26 13:57:59 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 5ADBF134463 for ; Tue, 26 Sep 2017 13:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 s0qUbwjMW0Gf for ; Tue, 26 Sep 2017 13:57:56 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37ECA134467 for ; Tue, 26 Sep 2017 13:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18791; q=dns/txt; s=iport; t=1506459475; x=1507669075; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=QFx5rY6AyQfJQ+IWHhFcnsarIylW71v7gOBVz0KLvfM=; b=aygDhmix684tojY3xLfy3+qeq8hsE3bY8B/FVfDxHI2gM8zW3rrrnIUY tbOs8arBkSKjx2//6lpaMExuED9z6EQ8PyyV5r1cGqTuCH+5J+Bon0vDg sasJkUS3HcStYimm/d3BP6k3tnfQKkdZKG7zLlU9wL/ipJqaxpa36Ulfy 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQCSvspZ/xbLJq1HFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ/boQdixOQUyuQbIdQBwOFOwKFEhQBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBI1sLCw4KExcCAlcGAQwIAQEXig8IqEKCJyeKdAEBAQEBAQQBAQEBAQEBA?= =?us-ascii?q?QEBAQ4PgyuFPSuCfYRBHRCDKYJgBYoIFokFjX2EPIIhhF2JI4ITiUkkhwaVR4E?= =?us-ascii?q?5NiFCTDIhCB0VhV4FHIFpPoh1AQUgghwBAQE?= X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="asc'?scan'208,217";a="655003828" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 20:57:52 +0000 Received: from [10.61.234.198] ([10.61.234.198]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8QKvqKr002952; Tue, 26 Sep 2017 20:57:52 GMT To: Kent Watsen , "opsawg@ietf.org" References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> From: Eliot Lear Message-ID: <51ce638c-a183-6ff4-2e12-5e3341df31b1@cisco.com> Date: Tue, 26 Sep 2017 22:57:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UMpIgboK6S0URdR7FOseCfuVqpTV6J6BB" Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 26 Sep 2017 20:57:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UMpIgboK6S0URdR7FOseCfuVqpTV6J6BB Content-Type: multipart/mixed; boundary="Ngpta5pHtWs0MjVRo7sS9HfDvA5Wnr24u"; protected-headers="v1" From: Eliot Lear To: Kent Watsen , "opsawg@ietf.org" Message-ID: <51ce638c-a183-6ff4-2e12-5e3341df31b1@cisco.com> Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> In-Reply-To: --Ngpta5pHtWs0MjVRo7sS9HfDvA5Wnr24u Content-Type: multipart/alternative; boundary="------------E8691B31D31E7DDC9CE8F138" Content-Language: en-US This is a multi-part message in MIME format. --------------E8691B31D31E7DDC9CE8F138 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 9/26/17 8:54 PM, Kent Watsen wrote: > Hiya again, > >>> In my previous review, I had asked about how MUD intersects with my z= erotouch draft, which has the device reaching out to either a well-known = Internet-based or deployment-specific HTTPS resource. But the need to re= ach out to these HTTPS resources should only be during the device's initi= al bootstrap process. You said before something about an initial policy = followed by an on-going policy, but I don't see that here. Did I miss it= ? >> I think so. There is the notion of =E2=80=9Ccache-validity=E2=80=9D = with the idea being that one can change the policy from time to time. Th= e policy does not itself expire, but the idea with =E2=80=9Ccache-validit= y=E2=80=9D is that mud controllers shouldn't pester the mud file server a= ny sooner than that period. > IIUYC, you're thinking that the switch would receive updated configurat= ion over time; an initial configuration would allow the Thing (to use the= word in the draft, not my preference) to allow the bootstrapping flows a= nd, then later, a second configuration that would reflect normal operatio= n. Perhaps I've misunderstood your initial question, so let me try again.=C2= =A0 While not specifically discussed, it is possible for a device to request a change of state if it starts to emit a different MUD-URL.=C2=A0 This is= possible for DHCP and LLDP but may be problematic for 802.1AR certificates.=C2=A0 I do think there are some security considerations whe= n devices change state like this, and those are discussed in Security Considerations.=C2=A0 I'm NOT recommending that devices do this. > This is not (IMO) a MUD-file thing, so much as a controller-thing, as= the Manufacturer would have no awareness of the operational state of the= devices or be able to sequence the release of MUD files accordingly. Fo= r this to work, I think the MUD file would need to have both states built= into it, so then the controller can initially select the first state and= then later, perhaps based on criteria other than a timeout, selects the = second state. Note, by "select" I mean "select and push updated config t= o switch based on"... See above.=C2=A0 I would worry about the complexity of the solution, whic= h is one of the reasons why I'm tending to agree with you to remove the masa-server entry, but I'm still thinking about that one.=C2=A0 Also, kee= p this in mind: my absolute preference is that this be done with 802.1AR certificates so that the device itself doesn't really assert ANYTHING.=C2= =A0 Rather the manufacturer should do the asserting. > > >>> What is the default behavior of the switch, when no MUD file is avail= able. Section 4 says "Anything not explicitly permitted is denied", but = that section discusses the processing of a MUD file, not when there is no= MUD file. I'm assuming the goal is for the switch to deny traffic (fail= close) when no MUD file can be found, but I worry that this may lead to = unhappy operators as new product deployments (not having MUD support) are= constantly blocked by the switches...=20 >> Fair question. If no MUD file is available, it's a deployment decisio= n as to how to proceed (much as it is today). The intent of Section 4 is= that one should assume that the end of an ACL is the JSON equivalent of = "deny any". Should I clarify this? > Right, the ACL is default deny all, but that is the ACL within the MUD = file that the controller (not the switch) processes. Looking to section 1= =2E8, it starts off with "Thing emits URL". In this case, it doesn't hap= pen, the Thing doesn't implement the RFC. In order for solutions to clai= m conformance, There is no conformance claim here at all.=C2=A0 These are called "descriptions" not "directives".=C2=A0 Deployments can do what with this information they will.=C2=A0 That is stated several times in the draft. > I think the switch would have to have a "mud-mode" whereby it refused = pass traffic on a port unless a mud-controller gave it the config to do s= o. If this is indeed the intent, I think the draft should be clear about= it. It is intentionally unclear on that.=C2=A0 See below. > > >>> Building upon the above two comments, I'm assuming that the switch co= uld be configured to *always* allow access to some resources, even when n= o MUD file is found. Is this what you had in mind? >> Yes. I can clarify this as well. > Okay, but then this seems to be at odds with the previous conclusion, w= hich I may have gotten wrong. To me, it seems that either the switch fai= ls-closed (mud mode) or not (normal mode), is there room for anything els= e? How a pizza parlor deals with is will likely differ from a bank.=C2=A0 An= d a bank will likely differ from how Juniper deals with it, which will likely differ from how a healthcare provider deals with it.=C2=A0 I'm hap= py, if you like to insert the following into Section 1.7 to make this abundantly clear: Network administrators have the ultimate say over how their networks are configured.=C2=A0 MUD files are recommendations.=C2=A0 The access= to network services assigned to a particular device either before a MUD file is read or after will depend on the deployment.=C2=A0 In some ca= ses, deployments may allow open access or limit access prior to receiving a MUD-URL.=C2=A0 In some cases, deployments may completely ignore MUD= URLs, or substitute some other behavior. > > > > > >>> Nits: >> I'll check each of these, but the term "Thing" is intended to be used > consistently, and changes made were in response to Robert Sparks' > review. I'll make sure that each is as intended. > > Okay, but I think it puts off the wrong signals and marginalizes the so= lution as a whole. But, if you insist, at least be sure to define "Thing= " before first use in the document (this is not the case currently) and g= ive it a definition that clearly indicates that it applies to all network= elements, not just lightbulbs, etc. Emm...=C2=A0 it is clearly (I hope, again based on reviewer comments) def= ined in the definitions section (there is a single forward reference). =46rom your other message: > Separately, who generates the MUD files? Is it the Manufacturer or som= eone else? Section 12.1 doesn't say. But Section 1 does ;-)=C2=A0 See bottom of page 3 top of page 4. Finally, > As an aside, why are these fields called "[my-]controller"? Because controllers are a pretty well understood IoT concept.=C2=A0 To an= swer the other question, I think it might help to state clearly that all the abstractions are translated into appropriate IP addresses that would be suitable for use in the ACL model. I'll comment on BRSKI in a separate post, probably tomorrow. Eliot --------------E8691B31D31E7DDC9CE8F138 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,


On 9/26/17 8:54 PM, Kent Watsen wrote:= 
Hiya again,


In my previous review, I had asked about how MUD=
 intersects with my zerotouch draft, which has the device reaching out to=
 either a well-known Internet-based or deployment-specific HTTPS resource=
=2E  But the need to reach out to these HTTPS resources should only be du=
ring the device's initial bootstrap process.  You said before something a=
bout an initial policy followed by an on-going policy, but I don't see th=
at here.  Did I miss it?


      

        
I think so.  There is the notion of  =E2=80=9Ccach=
e-validity=E2=80=9D with the idea being that one can change the policy fr=
om time to time.  The policy does not itself expire, but the idea with =E2=
=80=9Ccache-validity=E2=80=9D is that mud controllers shouldn't pester th=
e mud file server any sooner than that period.


      

      
IIUYC, you're thinking that the switch would receive updated configuratio=
n over time; an initial configuration would allow the Thing (to use the w=
ord in the draft, not my preference) to allow the bootstrapping flows and=
, then later, a second configuration that would reflect normal operation.=


    

    

    Perhaps I've misunderstood your initial question, so let me try
    again.=C2=A0 While not specifically discussed, it is possible for a
    device to request a change of state if it starts to emit a different
    MUD-URL.=C2=A0 This is possible for DHCP and LLDP but may be problema=
tic
    for 802.1AR certificates.=C2=A0 I do think there are some security
    considerations when devices change state like this, and those are
    discussed in Security Considerations.=C2=A0 I'm NOT recommending that=

    devices do this.

    

    

    

      
  This is not (IMO) a MUD-file thing, so much as a c=
ontroller-thing, as the Manufacturer would have no awareness of the opera=
tional state of the devices or be able to sequence the release of MUD fil=
es accordingly.  For this to work, I think the MUD file would need to hav=
e both states built into it, so then the controller can initially select =
the first state and then later, perhaps based on criteria other than a ti=
meout, selects the second state.  Note, by "select" I mean "select and pu=
sh updated config to switch based on"...


    

    

    See above.=C2=A0 I would worry about the complexity of the solution,
    which is one of the reasons why I'm tending to agree with you to
    remove the masa-server entry, but I'm still thinking about that
    one.=C2=A0 Also, keep this in mind: my absolute preference is that th=
is
    be done with 802.1AR certificates so that the device itself doesn't
    really assert ANYTHING.=C2=A0 Rather the manufacturer should do the
    asserting.

    

    

    

      




      

        

          
What is the default behavior of the switch, when=
 no MUD file is available.  Section 4 says "Anything not explicitly permi=
tted is denied", but that section discusses the processing of a MUD file,=
 not when there is no MUD file.  I'm assuming the goal is for the switch =
to deny traffic (fail close) when no MUD file can be found, but I worry t=
hat this may lead to unhappy operators as new product deployments (not ha=
ving MUD support) are constantly blocked by the switches...=20


        

      

      

      

        
Fair question.  If no MUD file is available, it's =
a deployment decision as to how to proceed (much as it is today).  The in=
tent of Section 4 is that one should assume that the end of an ACL is the=
 JSON equivalent of "deny any".  Should I clarify this?


      

      
Right, the ACL is default deny all, but that is the ACL within the MUD fi=
le that the controller (not the switch) processes. Looking to section 1.8=
, it starts off with "Thing emits URL".  In this case, it doesn't happen,=
 the Thing doesn't implement the RFC.  In order for solutions to claim co=
nformance,

    

    

    There is no conformance claim here at all.=C2=A0 These are called
    "descriptions" not "directives".=C2=A0 Deployments can do what with t=
his
    information they will.=C2=A0 That is stated several times in the draf=
t.

    

    

    

      
 I think the switch would have to have a "mud-mode" =
whereby it refused pass traffic on a port unless a mud-controller gave it=
 the config to do so.  If this is indeed the intent, I think the draft sh=
ould be clear about it.


    

    

    It is intentionally unclear on that.=C2=A0 See below.

    

      




      

        

          
Building upon the above two comments, I'm assumi=
ng that the switch could be configured to *always* allow access to some r=
esources, even when no MUD file is found.  Is this what you had in mind?


        

      

      

      

        
Yes.  I can clarify this as well.


      

      
Okay, but then this seems to be at odds with the previous conclusion, whi=
ch I may have gotten wrong.  To me, it seems that either the switch fails=
-closed (mud mode) or not (normal mode), is there room for anything else?=


    

    

    

    How a pizza parlor deals with is will likely differ from a bank.=C2=A0=

    And a bank will likely differ from how Juniper deals with it, which
    will likely differ from how a healthcare provider deals with it.=C2=A0=

    I'm happy, if you like to insert the following into Section 1.7 to
    make this abundantly clear:

    

    
Network administrators have the ultimate say over how
      their networks are configured.=C2=A0 MUD files are recommendations.=
=C2=A0
      The access to network services assigned to a particular device
      either before a MUD file is read or after will depend on the
      deployment.=C2=A0 In some cases, deployments may allow open access =
or
      limit access prior to receiving a MUD-URL.=C2=A0 In some cases,
      deployments may completely ignore MUD URLs, or substitute some
      other behavior.

    

    

    

    

      







      

        

          
Nits:


        

      

      

      

        
I'll check each of these, but the term "Thing" is =
intended to be used


      

      
consistently, and changes made were in response to R=
obert Sparks'
review.  I'll make sure that each is as intended.

Okay, but I think it puts off the wrong signals and marginalizes the solu=
tion as a whole.  But, if you insist, at least be sure to define "Thing" =
before first use in the document (this is not the case currently) and giv=
e it a definition that clearly indicates that it applies to all network e=
lements, not just lightbulbs, etc.

    

    

    Emm...=C2=A0 it is clearly (I hope, again based on reviewer comments)=

    defined in the definitions section (there is a single forward
    reference).

    

    

    From your other message:

    

    

      
Separately, who generates the MUD files?  Is it the =
Manufacturer or someone else?  Section 12.1 doesn't say.

    

    

    But Section 1 does ;-)=C2=A0 See bottom of page 3 top of page 4.

    

    Finally, 

    

    

      
As an aside, why are these fields called "[my-]contr=
oller"?

    

    

    Because controllers are a pretty well understood IoT concept.=C2=A0 T=
o
    answer the other question, I think it might help to state clearly
    that all the abstractions are translated into appropriate IP
    addresses that would be suitable for use in the ACL model.

    

    

    I'll comment on BRSKI in a separate post, probably tomorrow.

    

    Eliot

    

  


--------------E8691B31D31E7DDC9CE8F138--

--Ngpta5pHtWs0MjVRo7sS9HfDvA5Wnr24u--

--UMpIgboK6S0URdR7FOseCfuVqpTV6J6BB
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

iQEcBAEBCAAGBQJZyr9SAAoJEIe2a0bZ0nozYacIAM8IGsAKK6LynFz8lcpEVEbk
Rr813aV+ix3vT2dJvmIXsPYqVS59bITkQfoZ2DVRDw5P+RHX3yCKryi7BUPDPrcY
gJuTtIuBHN7iglcEVfvCjzrrY/jMlFGT9XxSvSXpDQbqjH0uoPGwI0IKbxtwFkwK
SZljRai/ul2VSZiCZJ/iirb6rYQ+OyMjqV/0gjWs5kCRF6cEcmQ6WQSNJHH7ATGe
3az9NkQOsJwMNnBO/12HkhoPibInXlNu0fjJuefPx+mjaoaZCNubY15lsXJd7faU
ob90tPh5JYb4e/T12h3Cv9/zHJRPcp4Z0ucGA8opmwkTDo5v/HSbmQpij0FypTU=
=Cq+K
-----END PGP SIGNATURE-----

--UMpIgboK6S0URdR7FOseCfuVqpTV6J6BB--


From nobody Tue Sep 26 16:12:37 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 CB69D132F3E for ; Tue, 26 Sep 2017 16:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, 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 6NLoQSuqOUMj for ; Tue, 26 Sep 2017 16:12:34 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E5C13202D for ; Tue, 26 Sep 2017 16:12:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10720; q=dns/txt; s=iport; t=1506467553; x=1507677153; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e3DpMbbFpjK8jTcpvLS5joyIbh4y5HcFaMv3/izihAc=; b=LKB2TWP5QX8NMq2xBwQ/sfN4Zfx+aduWEfJgFDQi1at6oZzLBu9ew1ct G1+XEmUFAPUBgPNbIEBK3gVTs3/VMWO9IS6KKwFu+KBHRIV4ND2SIaucG JzFMxIPMQlTYF0zrnnjL5lY2f/z8njPJEqdoguUk1BtfRIiehv5rzpiWJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQCR3cpZ/5NdJa1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNbZG4nB4NvmhuBVCJ5lTEOggQKI4UYAhqENUEWAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECASMRRQULAgEGAg4KAgImAgICMBUQAgQOBRuKDwgQimydZoIni?= =?us-ascii?q?xsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOghkEggKDOysLgWVYNYRaAw8CFoM?= =?us-ascii?q?TL4IxBYoeji+IUwKHXIx/DJJ6lRoCERkBgTgBJgYrgQ54FUkSAYUHHIFndgGIP?= =?us-ascii?q?oEygRABAQE?=
X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="scan'208";a="300348869"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 23:12:32 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8QNCWlr025727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2017 23:12:32 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Sep 2017 18:12:31 -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.1320.000; Tue, 26 Sep 2017 18:12:31 -0500
From: "Max Pritikin (pritikin)" 
To: Kent Watsen 
CC: Eliot Lear , "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11
Thread-Index: AQHTNvTSDWItj0h5hUeSQEbjimMLTqLH7vkAgAAw+oA=
Date: Tue, 26 Sep 2017 23:12:31 +0000
Message-ID: 
References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com>  <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> <8500A252-4867-41E3-806D-DD700953A777@cisco.com> <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>
In-Reply-To: <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>
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: <3E2BD5A6716C60468406162E25B57D21@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11
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, 26 Sep 2017 23:12:36 -0000

DQo+IE9uIFNlcCAyNiwgMjAxNywgYXQgMjoxNyBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVu
aXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gDQo+IEhpIE1heCwNCj4gDQo+IA0KPj4gVGhlIHJlbGV2
YW50IGludGVyc2VjdGlvbiB3b3VsZCBiZSBpZi9ob3cvd2hlbiBNVUQgZGVueeKAmXMgb3IgYWxs
b3dzIGEgY29ubmVjdGlvbiB0byB0aGUgbmV0Y29uZiB6ZXJvdG91Y2ggYm9vdHN0cmFwIHNlcnZp
Y2UgYXMgZGVzY3JpYmVkIGluOiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0Y29u
Zi0yRHplcm90b3VjaC0yRDE3LTIzc2VjdGlvbi0yRDQuNCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09elJKTkJ4V2ZKOFVXS2xOZkJZRTItdWs4MHFwbEZfMDNt
WVlUc1RVSzJNYyZzPVVtNGtBTEo0NVZMekw0UllBWmltakUwaTB2c1BEbjhmamRiTmJ4cE91eEUm
ZT0gID8NCj4gDQo+IA0KPiBZZXMgYW5kIG5vLiAgWWVzLCBpbiB0aGF0IGluZGVlZCB0aGUgemVy
b3RvdWNoIGJvb3RzdHJhcCBzZXJ2ZXIgbWF5IGJlIGVpdGhlciBhIHdlbGwta25vd24gSW50ZXJu
ZXQtYmFzZWQgcmVzb3VyY2UgKGUuZy4sIGRldmljZXMgYXJlIGhhcmRjb2RlZCB3aXRoIGl0cyBs
b2NhdGlvbiBhbmQgdHJ1c3QgY3JlZGVudGlhbHMpIG9yIGEgZGVwbG95bWVudC1zcGVjaWZpYyBy
ZXNvdXJjZSAoZS5nLiwgZGV2aWNlcyBsZWFybiBhYm91dCBpdHMgbG9jYXRpb24gYW5kIHRydXN0
IGNyZWRlbnRpYWxzIGR5bmFtaWNhbGx5KS4gIE5vLCBpbiB0aGF0IHRoZSB6ZXJvdG91Y2ggc29s
dXRpb24gY2FuIGFsc28gbGV2ZXJhZ2UgREhDUCwgRE5TLCBhbmQgcG90ZW50aWFsbHkgb3RoZXIg
VEJEIHJlc291cmNlcyBhcyB3ZWxsLiAgSSdtIG5vdCBzcGVjaWZpY2FsbHkgY2FsbGluZyBvdXQg
REhDUCBhbmQgRE5TIGhlcmUgdGhvdWdoIGJlY2F1c2UgdGhlIE1VRCBkcmFmdCBhbHJlYWR5IGlt
cGxpY2l0bHkgYWxsb3dzIGFjY2VzcyB0byB0aG9zZSB0d28gcmVzb3VyY2VzLiAgTXkgaW50ZW50
IHdhcyB0byBqdXN0IHVzZSB6ZXJvdG91Y2ggYXMgYW4gZXhhbXBsZSBoZXJlLCBvdGhlciBtZWNo
YW5pc21zIChwb3RlbnRpYWxseSBub3QgcmVsYXRlZCB0byBib290c3RyYXBwaW5nKSBtYXkgaGF2
ZSBzaW1pbGFyIGNvbmNlcm5zLg0KPiANCj4gDQo+PiBJIHRoaW5rIHRoZSBNVUQg4oCYY29udHJv
bGxlcuKAmSBvciDigJhteS1jb250cm9sbGVy4oCZIG1lY2hhbmlzbSB3b3VsZCBiZSB1c2VkIHRv
IGVuc3VyZSBkZXZpY2VzIG9mIHRoaXMgY2xhc3MgY2FuIGFjY2VzcyB0aGUgaW5kaWNhdGVkIOKA
nGludGVybmV0LWJhc2Vk4oCdIG9yIOKAnGRlcGxveW1lbnQtc3BlY2lmaWMgSFRUUFMgcmVzb3Vy
Y2XigJ0gYm9vdHN0cmFwLXNlcnZlcj8NCj4gDQo+IE1heWJlPyBUbyBiZSBob25lc3QsIHRoZSB1
c2Ugb2YgdGhlICdjb250cm9sbGVyJyBhbmQgJ215LWNvbnRyb2xsZXInIGNsYXNzZXMgYXJlbid0
IHZlcnkgY2xlYXIgdG8gbWUuICBUaGV5J3JlIG5vdCBwYXJ0IG9mIHRoZSBNVUQgZmlsZSBleGFt
cGxlIGluIHNlY3Rpb24gOC4gIEFyZSB5b3UgdGhpbmtpbmcgdGhhdCB0aGUgTWFudWZhY3R1cmVy
IHdvdWxkIHByZXBvcHVsYXRlICdjb250cm9sbGVyJyB3aXRoIGl0cyBJbnRlcm5ldC1iYXNlZCBy
ZXNvdXJjZSBhbmQgdGhhdCBkZXBsb3ltZW50cyB3b3VsZCBwb3B1bGF0ZSB0aGUgJ215LWNvbnRy
b2xsZXInIHdpdGggdGhlaXIgZGVwbG95bWVudC1zcGVjaWZpYyByZXNvdXJjZXM/DQo+IA0KPiAN
Cj4+IFNpbWlsYXJseSBmb3IgYW5pbWEgZGV2aWNlcyBtaWdodCBiZSBsaW1pdGVkIHRvIG9ubHkg
Y29udGFjdGluZyB0aGVpciBsb2NhbCBCUlNLSSByZWdpc3RyYXIgdmlhIOKAmG15LWNvbnRyb2xs
ZXInPw0KPiANCj4gSSBndWVzcywgYmFzZWQgb24gdGhlIGFib3ZlLCBidXQgdGhpcyBpcyB3aGF0
IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZC4NCj4gDQo+IA0KPj4gQXNzdW1pbmcgbXkgaW50ZXJw
cmV0YXRpb24gaXMgY29ycmVjdCBJIGRvbuKAmXQgc2VlIGFueSBjaGFuZ2UgbmVlZGVkIGluIHRo
ZSB0ZXh0IGFib3V0IHRoaXMuIA0KPiANCj4gV2VsbCwgYXQgYSBtaW5pbXVtIGl0IHdvdWxkIG5l
ZWQgdG8gYmUgbW9yZSBjbGVhcmx5IGV4cGxhaW5lZC4gIEFsc28sIEkgdGhpbmsgdGhhdCB0aGUg
YnJza2kgZHJhZnQgbmVlZHMgdG8gZXhwbGFpbiBob3cgdGhpcyBmaWVsZCBpcyBpbnRlbmRlZCB0
byBiZSB1c2VkIGJlZm9yZSB0aGlzIGZpZWxkJ3MgZXhpc3RlbmNlIGNhbiBiZSBmdWxseSBqdXN0
aWZpZWQuICANCj4gDQo+IEFzIGFuIGFzaWRlLCB3aHkgYXJlIHRoZXNlIGZpZWxkcyBjYWxsZWQg
IltteS1dY29udHJvbGxlciI/IC0gbWF5YmUgc29tZXRoaW5nIGxpa2UgInJlc291cmNlIiB3b3Vs
ZCBiZSBtb3JlIGdlbmVyYWxseSBhcHBsaWNhYmxlLCBhcyBub3QgZXZlcnl0aGluZyBpcyBhIGNv
bnRyb2xsZXI/DQoNCk15IHRoaW5raW5nIGlzIHRoYXQgTVVEIGFsbG93cyBmb3IgYm90aCBORVRD
T05GICYgQlJTS0kgbW9kZWxzIHZpYSB0aGVzZSBmaWVsZHMuIFRoYXQgSSBjYW7igJl0IGNvbmNs
dXNpdmVseSBzaG93IHRoaXMgYnkgcXVvdGluZyB0aGUgcGFyYWdyYXBocyBpbiDigJhjb250cm9s
bGVy4oCZIGFuZCDigJhteS1jb250cm9sbGVy4oCZIHNlY3Rpb25zIG9mIHRoZSBNVUQgZG9jdW1l
bnQgcmUtZW5mb3JjZXMgeW91ciBwb2ludHMgdGhhdCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgbWln
aHQgaGVscC4gSeKAmW0gY3VyaW91cyB3aGF0IEVsaW90IHdpbGwgc2F5LiANCg0KPj4gSSB0aGlu
ayB0aGUgY3VycmVudCB0ZXh0IGlzIHZhbGlkIGFuZCBjb3JyZWN0LiBJIHZvdGUgYWdhaW5zdCBh
bnkgY2hhbmdlcyBpbiB0aGlzIGFyZWE6IA0KPj4gDQo+PiBEaXN0cmlidXRpb24gb2YgdGhlIE1B
U0Egc2VydmVyIFVSTCBpcyBpbmZvcm1hdGl2ZSB0byB0aGUgbG9jYWwgbmV0d29yayBpbmZyYXN0
cnVjdHVyZS4gU3VwcG9ydCBmb3IgdGhpcyBtZWNoYW5pc21zIGFsbG93cyBhIGxvY2FsIG5ldHdv
cmsgaW5mcmFzdHJ1Y3R1cmUgdG8ga25vdyB3aGljaCBNQVNBIHNlcnZpY2UgdG8gY29udGFjdCBm
b3IgdGhpcyBkZXZpY2UuIEFsbG93aW5nIHRoaXMgd2l0aGluIE1VRCBwcm92aWRlcyBhbiBvcHRp
bWl6YXRpb24gb3Bwb3J0dW5pdHkgZm9yIHZlbmRvcnMgdGhhdCBhcmUgYW5pbWEgQlJTS0kgY29t
cGF0aWJsZS4gVGhleSBjYW4gZWl0aGVyIGltcGxlbWVudCB0aGUgTUFTQSBleHRlbnNpb24gVVJM
LCBhbmQgYW55IG90aGVyIHVybHMsIHdpdGhpbiB0aGVpciBpbml0aWFsIGRldmljZSBpZGVudGl0
eSAtb3ItIHRoZXkgY2FuIGltcGxlbWVudCBvbmx5IHRoZSBNVUQgVVJMIGV4dGVuc2lvbi4gU3Bh
Y2UgYW5kIGNoYW5nZXMgdG8gdGhlIGRldmljZSBpZGVudGl0eSBjZXJ0aWZpY2F0ZSBhcmUgbGlt
aXRlZCBhbmQgZGlmZmljdWx0IHNvIGFuIGluZGlyZWN0aW9uIHRocm91Z2ggdGhlIE1VRCBzZXJ2
aWNlIGlzIGEgdmFsdWFibGUgYXBwcm9hY2guDQo+IA0KPiBJJ20gbm90IGRpc3B1dGluZyB0aGUg
dmFsdWUgb2YgYmVpbmcgYWJsZSB0byByZWxheSBzdWNoIGluZm9ybWF0aW9uICh0aG91Z2ggaXQn
cyBtaXNzaW5nIGluIHRoZSBicnNraSBkcmFmdCksDQoNClRoZXJlIGlzIHRleHQgYWJvdXQgdGhl
IGV4dGVuc2lvbiBhbmQgaG93IGl0IGlzIGNvbW11bmljYXRlZCBpbiB0aGUgY3VycmVudCBCUlNL
SSBkcmFmdC4gSeKAmXZlIG9wZW5lZCBhbiBpc3N1ZSB0byBtYWtlIGl0IGNsZWFyZXIgKHdlIGNh
biBjb250aW51ZSB0aGF0IHBvcnRpb24gb2YgdGhpcyBkaXNjdXNzaW9uIG9uIHRoZSBCUlNLSSBn
aXRodWIpLg0KDQo+IEknbSBqdXN0IHRoaW5raW5nIHRoYXQgcmF0aGVyIHRoYW4gaGFyZGNvZGUg
c29tZXRoaW5nIGludG8gdGhlIGJhc2UgTVVEIGZpbGUgZGVzY3JpcHRpb24sIHRoYXQgdGhlIHNh
bWUgY2FuIGJlIGRvbmUgdXNpbmcgdGhlIGV4dGVuc2lvbiBtZWNoYW5pc20gdGhhdCB0aGlzIGRy
YWZ0IGlzIGRlZmluaW5nIGluc3RlYWQuICBTYW1lIGRhdGEsIGp1c3QgZGVjbGFyZWQgZGlmZmVy
ZW50bHkuICBJZiB0aGVyZSBpcyBhIGNsYWltIHRoYXQgaXQgaXMgdG9vIGhhcmQsIHRoZW4gSSdk
IHJlY29tbWVuZCBzcGVuZGluZyBtb3JlIHRpbWUgZXhhbWluaW5nIHRoZSBleHRlbnNpb24gbWVj
aGFuaXNtIG5vdyByYXRoZXIgdGhhbiBhZnRlciB0aGlzIGJlY29tZXMgYW4gUkZDLg0KPiANCj4g
VGhhdCBzYWlkLCBtYXliZSB3ZSBzaG91bGQgY2hhbGxlbmdlIHRoZSBuZWNlc3NpdHkgb2YgdGhp
cyBmaWVsZCwgb3IgYXQgbGVhc3QgZXhhbWluZSB0byB3aGF0IGVuZCB0aGlzIGlkZWEgaXMgdmFs
aWQuICBGaXJzdCwganVzdCB0byB0aHJvdyBpdCBvdXQgdGhlcmUsIHdoeSBub3QgYWxzbyBhZGQg
YSAiemVyb3RvdWNoLXNlcnZlciIgZmllbGQ/ICBJJ20gZ3Vlc3NpbmcgdGhhdCB0aGlzIGZpZWxk
IGVuYWJsZXMgbGF6eS1iaW5kaW5nIHNvLCByYXRoZXIgdGhhbiBhIGRldmljZSBoYXJkY29kaW5n
IHN1Y2ggaW5mbywgaXQgYmUgZGV0ZXJtaW5lZCBvcGVyYXRpb25hbGx5LiAgT3RoZXIgcmVzb3Vy
Y2VzIGFwcGx5IHRvbywgcmlnaHQ/ICBTb21ldGltZXMgZGV2aWNlcyBuZWVkIHRvIHJlYWNoIG91
dCB0byB3ZWxsLWtub3duIHJlc291cmNlcyBmb3IgZS5nLiwgYW50aS14IHNpZ25hdHVyZSBwYWNr
cy4gIFdvdWxkIHRoZSBsb2NhdGlvbiBmb3IgdGhlc2UgcmVzb3VyY2VzIGFsc28gYmUgbWFwLWFi
bGUgdmlhIGEgTVVEIGZpbGU/ICBOb3RlIHRoYXQgSSdtIG5vdCBhY3R1YWxseSBhZHZvY2F0aW5n
IGZvciBhbnkgb2YgdGhpcyBhdCB0aGUgbW9tZW50LCBqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5k
IHdoYXQncyBpbnRlbmRlZCBoZXJlLg0KPiANCj4gDQo+IA0KPj4gVG8gbWFrZSB0aGlzIGV4dGVu
c2libGUgZWl0aGVyIEJSU0tJIChldCBhbGwgKSBuZWVkcyB0byBleHRlbmQgdGhlIHlhbmcgbW9k
ZWxzIG11Y2ggdGhlIHdheSBpdCBkb2VzIHdpdGggdGhlIHZvdWNoZXIgZG9jdW1lbnQgb3IgdGhl
cmUgbmVlZHMgdG8gYmUgYSBNVUQgc3BlY2lmaWMgZXh0ZW5zaW9uIG1ldGhvZCAoaWFuYSBuYW1l
c3BhY2UgZGVjbGFyZWQgd2l0aGluIE1VRD8pIG9yIHNvbWV0aGluZy4gSSBkb27igJl0IHNlZSBo
b3cgdGhhdCBmaXRzIHRvZ2V0aGVyIGNsZWFubHkgYW5kIGRvbuKAmXQgc2VlIHNvbHZpbmcgdGhv
c2UgcXVlc3Rpb25zIGFzIG5lY2Vzc2FyeSBhdCB0aGlzIHRpbWUuDQo+IA0KPiBZZXAsIHRoaXMg
aXMgd2hhdCBJIHRob3VnaHQgeW91IG1pZ2h0IHNheS4gIFllcywgaXQgbWF5IG5vdCBiZSBjbGVh
biwgYnV0IGl0IHNob3VsZCBiZSB1bmRlcnN0b29kLCByaWdodD8NCg0KSSB0aGluayB5b3XigJly
ZSBzdWdnZXN0aW5nIHRoYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
b3BzYXdnLW11ZC0xMSNzZWN0aW9uLTMuNCBiZSByZW1vdmVkIGFuZCB0aGF0IGluc3RlYWQgdGhl
IEJSU0tJIGRvY3VtZW50IGxldmVyYWdlIHNlY3Rpb24gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb3BzYXdnLW11ZC0xMSNzZWN0aW9uLTMuNyB0byBkZWZpbmUgYSBtYXNh
LXVybCBleHRlbnNpb24gYnkgbWlycm9yaW5nIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTEjYXBwZW5kaXgtQyB0byBkZWZpbmUgdGhlIGV4dGVuc2lv
bi4NCg0KSW4gdGhlIHByb2Nlc3Mgb2YgZm9sbG93aW5nIHRoaXMgdGhpbmtpbmcgSSBoYXZlIHRo
ZSBmb2xsb3dpbmcgTEMgTk9URVMgRk9SIEVMSU9UOiANCg0KMSkgVGhpcyBzZW50ZW5jZSBvZiAz
LjcgcHJvYmFibHkgbmVlZHMgdG8gYmUgYWRqdXN0ZWQgdG8gYmV0dGVyIG1hdGNoIFJGQzIxMTkg
dGVybWlub2xvZ3kuIEkgc3VnZ2VzdDoNCiAgICJOb3RlIHRoYXQgTk8gTVVEIGV4dGVuc2lvbnMg
bWF5IGJlIHVzZWQgaW4gYSBNVUQgZmlsZSBwcmlvciB0bw0KICAgdGhlIGV4dGVuc2lvbnMgYmVp
bmcgZGVjbGFyZWQuIg0KdG8NCiAgIOKAnE1VRCBleHRlbnNpb25zIE1VU1QgTk9UIGJlIHVzZWQg
aW4gYSBNVUQgZmlsZSBwcmlvciB0byB0aGUgZXh0ZW5zaW9ucyBiZWluZyByZWdpc3RlcmVkIHdp
dGggSUFOQSAoc2VlIEV4dGVuc2lvbnMgUmVnaXN0cnksIHNlY3Rpb24gMTYuOC7igJ0NCg0KQWx0
aG91Z2ggdGhpcyB0ZXh0IG1pZ2h0IGluc3RlYWQgYmUgc3RhdGluZyB0aGF0LCDigJxNVUQgZXh0
ZW5zaW9ucyBNVVNUIE5PVCBiZSB1c2VkIGluIGEgTVVEIGZpbGUgdW5sZXNzIHRob3NlIGV4dGVu
c2lvbnMgYXJlIGxpc3RlZCBpbiB0aGUgb3B0aW9uYWwgbGVhZi1saXN0IOKAmGV4dGVuc2lvbnPi
gJnigJ0uIEEgZGlzY3Vzc2lvbiBvZiB0aGUgdmFsdWUgb2YgdGhpcyBsZWFmIGxpc3QgbWlnaHQg
cHJvdmlkZSBuZWNlc3NhcnkgY29udGV4dCBmb3IgdGhpcyByZWFkZXIgdG8gZGlzYW1iaWd1YXRl
LiAgDQoNCjIpIFRoZSDigJxFeGFtcGxlLUV4dGVuc2lvbuKAnSB0ZXh0IG9mIEFwcGVuZGl4IEMg
d2FzIHByb2JhYmx5IG1lYW50IHRvIGluZGljYXRlICJpZXRmLW11ZC1kZXRleHQtZXhhbXBsZeKA
nSBhcyBzaG93biBpbiB0aGUgZXhhbXBsZSBleHByZXNzaW9uIGxvd2VyIGluIHRoZSBzZWN0aW9u
LiANCg0KSXMgdGhpcyB3aGF0IHlvdeKAmXJlIGdldHRpbmcgYXQ/IA0KSSB3b3VsZG7igJl0IGhh
dmUgc3VnZ2VzdGVkIHRoaXMgY2hhbmdlOyBidXQgSSB0aGluayBJIGNhbiBjb25maXJtIEkgc2Vl
IGhvdyBpdCB3b3VsZCB3b3JrLiANCg0KPiBTZXBhcmF0ZWx5LCB3aG8gZ2VuZXJhdGVzIHRoZSBN
VUQgZmlsZXM/ICBJcyBpdCB0aGUgTWFudWZhY3R1cmVyIG9yIHNvbWVvbmUgZWxzZT8gIFNlY3Rp
b24gMTIuMSBkb2Vzbid0IHNheS4gIFNlY3Rpb24gMTIuMiBzYXlzIHRoYXQgdGhlIE1VRCBjb250
cm9sbGVyIHZlcmlmaWVzIHRoZSBzaWduYXR1cmUgdG8gYSBrbm93biB0cnVzdCBhbmNob3IsIGJ1
dCBpdCdzIHVuY2xlYXIgaG93IHRoZXNlIFRBcyBiZWNhbWUga25vd24uICBFbHNld2hlcmUgdGhl
IGRyYWZ0IHNheXMgTVVEIGNhbiBwcm92aWRlIGEgbWVhbnMgdG8gYWRkcmVzcyBzb21lIHZ1bG5l
cmFiaWxpdGllcyBpbiBkZXZpY2VzIHRoYXQgbm8gbG9uZ2VyIHN1cHBvcnRlZCBieSB0aGVpciBt
YW51ZmFjdHVyZXIsIHNvIEknbSBndWVzc2luZyB0aGF0IGl0J3MgdGhlIGxhdHRlciwgbm90IHRo
ZSBmb3JtZXIuICANCg0Kbm8gY29tbWVudC4NCg0KPiBEb2VzIHRoaXMgaW50cm9kdWNlIGEgU2Vj
dXJpdHkgcmlzayAoZGVncmFkYXRpb24gYXR0YWNrKSBvZiBhbnkgc29ydCB0byB0aGUgYnJza2kg
Ym9vdHN0cmFwcGluZyBwcm9jZXNzPw0KDQpOby4gSWYgdGhlIG1hbnVmYWN0dXJlciBjZXJ0aWZp
Y2F0ZSBkb2VzbuKAmXQgaW5jbHVkZSB0aGUgTUFTQSBVUkwgYW5kIGl0IGlzIGRpc3RyaWJ1dGVk
IHZpYSBNVUQgZmlsZXMgaW5zdGVhZCB0aGVuIHRoZXJlIGlzIG5vIGltcGFjdCBvbiB0aGUgc2Vj
dXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIEJSU0tJLiBJbiB0aGlzIGNvbnRleHQgTVVEIGlzIGp1
c3QgYW5vdGhlciBtZXRob2Qgb2YgY29uZmlndXJpbmcgdGhlIEJSU0tJIHJlZ2lzdHJhciB0byBr
bm93IHRoZSBNQVNBIHNlcnZlciBVUkwuIFdvcnN0IGNhc2UgaXMgbWlzY29uZmlndXJhdGlvbiB3
aGljaCBpcyBkZWFsdCB3aXRoIHNlY3VyZWx5LiANCg0KLSBtYXgNCg0KPiANCj4gDQo+IFRoYW5r
cywNCj4gS2VudA0KPiANCj4gDQoNCg==


From nobody Wed Sep 27 01:18: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 25B8A134581 for ; Wed, 27 Sep 2017 01:18:00 -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 J2bgZFFlG3ZJ for ; Wed, 27 Sep 2017 01:17:58 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349651345AB for ; Wed, 27 Sep 2017 01:12:34 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8R8CSGc014985; Wed, 27 Sep 2017 09:12:28 +0100
Received: from 950129200 (218.122.115.87.dyn.plus.net [87.115.122.218]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8R8CRuN014965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2017 09:12:28 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Warren Kumari'" 
Cc: "'Benoit Claise'" , 
References: <00f601d3353e$e0dfbc80$a29f3580$@olddog.co.uk> 
In-Reply-To: 
Date: Wed, 27 Sep 2017 09:12:22 +0100
Message-ID: <03d901d33768$59623090$0c2691b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIpFjGRx+Ba95af8EKwKacJSxZMZwKn6NPiogdkMVA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23354.005
X-TM-AS-Result: No--2.739-10.0-31-10
X-imss-scan-details: No--2.739-10.0-31-10
X-TMASE-MatchedRID: u1zqiMeMcro4HKI/yaqRm00jzafXv7tTWOi4GPaBr79JJReS9JUB3K6L sRCt9QbJ/nIg4GMZt09wKl6VliNoZIaAlLtW1rjtvHKClHGjjr19LQinZ4QefDuUMbK1NdLP+gt Hj7OwNO2OhzOa6g8KrWchZkYaWQLiu6QlF5lSueEENpQLIJ0shzCGmp9AuQ3nDBj6wraB8NvkP2 yapUEP3KKWedUMQI938fsC+xPFkxvsNp90fT4EjuoLJh5uXtfs
Archived-At: 
Subject: Re: [OPSAWG] AD Review of draft-ietf-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: Wed, 27 Sep 2017 08:18:00 -0000

> For now I'll complete the AD writeup, and put it in AD watching,
> revised ID needed state. Once y'all have figured out an answer I'll
> hit the Go button.

Fair enough, Warren.

I have an update ready with changes for everyone else's comment, so we =
are "close".

I know that Benoit is busy fellow, but if you find yourself able to =
nudge him then please do.

Adrian


From nobody Wed Sep 27 01:33: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 50B771345D1 for ; Wed, 27 Sep 2017 01:33:08 -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 xy5rTJQfhm8B for ; Wed, 27 Sep 2017 01:33:06 -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 78048134564 for ; Wed, 27 Sep 2017 01:33:06 -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 v8R8X080005430; Wed, 27 Sep 2017 09:33:00 +0100
Received: from 950129200 (218.122.115.87.dyn.plus.net [87.115.122.218]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8R8Wxxq005392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2017 09:32:59 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'t.petch'" , "'Benoit Claise'" ,  "'Warren Kumari'" 
Cc: 
References: <00f601d3353e$e0dfbc80$a29f3580$@olddog.co.uk> <007a01d33761$8db54960$4001a8c0@gateway.2wire.net>
In-Reply-To: <007a01d33761$8db54960$4001a8c0@gateway.2wire.net>
Date: Wed, 27 Sep 2017 09:32:54 +0100
Message-ID: <03dd01d3376b$3762b340$a62819c0$@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: AQIpFjGRx+Ba95af8EKwKacJSxZMZwKFIUueogh79AA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23354.005
X-TM-AS-Result: No--15.756-10.0-31-10
X-imss-scan-details: No--15.756-10.0-31-10
X-TMASE-MatchedRID: xcONGPdDH5on2WEbWzq9raDH6drx3JPVkUtSee+57IEs7eP5cPCWQ4Qm ENBkUZwT6dBaLYpKyHY0L7hY/wAQOjWAitAoEQdjTQh9A4m9EtErHkgIan9a0fgnJH5vm2+g/VQ G3oVfx35lLertQuuFanbbTtWpu2f+5b/DdE/7G1H87vS8PQu3wLNI9rnyO+FWArMcoUfMuwlssj pRBSdcKht8AIH//t5xLs9dhAtf++aE10GPyDGx4vHkpkyUphL9vrwC6hEjckXSYAzZ6KmqWgE8g tucFNjVtvjJi2zRcA97gN/UNBe5jU18C7Low4cBwCZxkTHxccmz5LIh2+IOfFeilmPI7oJlP+Ot HbJZwW4eqD29/elme4LEdDPP19Uo4ms/Rt5qViJ+FHBf6ohqzZE+3DCX3uibAOrNpiFyN5CbH4L DP8SxBYMmUcN/l8E7kZOl7WKIImq0P2qkGU0XylZ0V5tYhzdWxEHRux+uk8h+ICquNi0WJBTgX8 Lqg5WqA7ij11PbpzcaaREk4qGVDTB9WreLo9WHftwZ3X11IV0=
Archived-At: 
Subject: Re: [OPSAWG] AD Review of draft-ietf-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: Wed, 27 Sep 2017 08:33:08 -0000

Hi Tom,
Long time!

> > What I see from 7950 is that a "YANG module" is a compilable blob of
> > YANG that may include other modules or specific constructs from another
> > module. That is clear enough.
> >
> > What is less clear is what a "data model" is or is not. I think that
> > if, for example, I wanted to model a router, I would construct a data
> > model from one or mode YANG modules that encode various aspects of the
> > router. You could, I suppose, present that construct as a module its own
> > right.
> >
> > And that leads me to ask you when it is appropriate to use term "data
> > model".
> >
> > 8199 doesn't offer me a lot of clarity. For example, section 1 says:
> >       For example, a
> >       Layer 2 Virtual Private Network (L2VPN) YANG module might be a
> >       Network Service YANG Module, ready to be used as a service model
> >       by a network operator.
> >
> > Later (in 2.1) it says that a module "describes an abstract model"
> > And (in 2.2) that a module "provides a coherent data model
> > representation"
> >
> > All this means (I think) that modules are documentation, but models
> > are used.
> >
> > It's all a bit esoteric for me and I can't find a way forward :-(
> >
> > What I want to do is observe that:
> > - Modules a constructed from YANG and may include other whole YANG
> >    modules or specific elements from other YANG modules
> > - Modules describe may define pieces of modelling that are only useful
> >    when applied in a context. For example, a module might define a
> >    YANG construct for a timestamp or an interface, but those constructs
> >    would only be useful when included in another module that gave
>  >   context to the timestamp or interface.
> > - Modules may also describe data models for components or
> >    sub-components of a managed system (often by including YANG from
> >    other modules).
> > - Not all modules provide data models that are independently useful,
> >    but some do. And one example is that when we want to model
> >    something like a service, we use a service model that is presented
> >    in a single YANG module. Thus, it is perfectly reasonable that 7223 is
> >    called "A YANG Data Model for Interface Management" and 8049 is a
> >    "YANG Data Model for L3VPN Service Delivery".
> >
> > So, my inclination is to include pointers to the 7950 definitions, and
> > to carefully re-read the text in our draft, but not to make a wholesale
> > change of terms.
> >
> > Any clues?
> 
> Adrian,
> 
> What jumps out at me, as being an infelicitous of language,  is the
> first sentence,
> "   The IETF has produced many data modules in the YANG modeling
>    language.  "
> and that is because of 'data module'.
> 
> Modules are compilable, as you say, because they are written in a
> language, a data definition language, such as SMI, ABNF or even YANG, so
> what you have is a SMI module or a YANG module; they appear in an RFC
> and define a schema for data, arguably they are not the data itself, so
> I think that 'data
> module' is an oxymoron and that first sentence should be
> "   The IETF has produced many modules in the YANG modeling
>    language. "

That is good.
We can avoid all "data modules". Four instances.

> When RFC7950 defines data model as 'A data model describes how data is
> represented and accessed' I think that it misses the point somewhat,
> that a data model is in contrast to an information model as described in
> RFC3444. That RFC suggests  that all SMI modules are data models and so
> by implication so would all YANG modules be.
> 
> A YANG module for routing or interfaces can or will be a data
> model but will a YANG module that defines data types for routing be?
> um, unsure.
> 
> I myself would avoid all uses of 'data model'

But we have all the weight of recorded history :-)

I've also cleaned up "YANG model". That seems to be wrong: we either have "data
models" or "YANG modules".

But the big distinction still eludes me. Perhaps you are right that the way
forward is just to dodge the issue and only talk about modules.

Adrian




From nobody Wed Sep 27 01:55:36 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 C8E511347CE for ; Wed, 27 Sep 2017 01:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.5
X-Spam-Level: 
X-Spam-Status: No, score=-13.5 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, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_HI=-5, 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 doNvgX7Y0_pd for ; Wed, 27 Sep 2017 01:55:32 -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 954A51347B6 for ; Wed, 27 Sep 2017 01:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56370; q=dns/txt; s=iport; t=1506502531; x=1507712131; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TL5o8ZGlcRAF9x08Muer7DWzSsC9llrVxpWZebqi49g=; b=BsBNiyW6apuBsMBj4lcHtfBgpHtU5WxCSOA9E24TR8K4XUfgx8Rfjuv2 22OomuqwJItOOjX4C89Pa+Sif3rQt0a6URUWn4Af5mMMnrGqen+HzGDbc tbShHaMmribsO5gjhKCgiAX6ehIrwrC7n/owEi/+/qfitRvM+XMXBdxbQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCSZstZ/xbLJq1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvgVFuJ4N2ixOQfnmMV4hbghIKG4FBg18ChRgWAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEEASMKPg4FCwkCEiYBCQICJiMOBgEMBQECAQGKJQiKTZ1mgicnilsBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgyuDU4FqK4JINYRZgz6CYAEEihKOO4hTh16?= =?us-ascii?q?Mf4ITW4htJIcGjW6HWYE5JgsmgQ4yIQgdFYVjHIFpPjaIKwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,444,1500940800";  d="scan'208,217";a="656037340"
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; 27 Sep 2017 08:55:26 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8R8tQQu029008; Wed, 27 Sep 2017 08:55:26 GMT
To: adrian@olddog.co.uk, "'Warren Kumari'" 
Cc: opsawg@ietf.org
References:   <57bf897c-e73d-9f80-a950-e4c4488afd34@cisco.com> <000001d33209$361ef7d0$a25ce770$@olddog.co.uk>
From: Benoit Claise 
Message-ID: <0591a97b-09f7-5c0c-0a85-3c2db0d76c71@cisco.com>
Date: Wed, 27 Sep 2017 10:55:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <000001d33209$361ef7d0$a25ce770$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------59D83680C5B3A92893D1A98A"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] Fwd: AD Review of draft-ietf-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: Wed, 27 Sep 2017 08:55:35 -0000

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

Hi Adrian,
>
> > In the same figure, could the "Device Configuration Model" be 
> renamed to RFC 8199
>
> > "Network Element YANG module" (this is what you did in figure 4 anyway)
>
> I believe we are separating the "device configuration model" that is 
> used to talk to an NE, and a "network configuration model" used to 
> talk to a controller that is responsible for a set of NEs. I think the 
> correct thing is to add exactly that statement (i.e., a definition of 
> the terms alongside figure 3).Then the mapping of these terms should 
> show up alongside Figure 4.
>
ok.
>
> But, you know what?
>
> Looking at this made me go back to Figure 1 of RFC8199 again. And 
> finally I understood it. That is probably a bit sad.
>
> I had been misled (no blame associated) by the OSS/BSS box in the 
> figure because that is an entity not a module. That made me read the 
> horizontal lines as interfaces (over which the named module types are 
> used) and the boxes as functional units that consume the modules.
>
> Now, thatis a *horrible* misreading, but there we go! And RFC8199 has 
> already been published, so adding clarification so that fools like me 
> are not confused is not possible.
>
> I believe the intention is to only show modules and not things that 
> consume or use modules.
>
> So I wonder whether we should make some clarification in our Figure 4. 
> Possibly it should look like...
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Operations Support and Business Support YANG Modules
>
> +-----------------------++-----------------------+
>
> ||||
>
> |Customer Service||Other|
>
> |YANG Modules||Operations Support|
>
> |||and|
>
> |+------++------+||Business Support|
>
> |||||||YANG Modules|
>
> || L2SM || L3SM ||||
>
> ||||||||
>
> |+------++------+|||
>
> ||||
>
> +-----------------------++-----------------------+
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Network Service YANG Modules
>
> +------------++-------------++-------------++-------------+
>
> ||||||||
>
> |- L2VPN| |- L2VPN||EVPN||L3VPN|
>
> |- VPWS||- VPLS|||||
>
> ||||||||
>
> +------------++-------------++-------------++-------------+
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Network Element YANG Modules
>
> +------------++------------++-------------++------------+
>
> ||||||||
>
> |MPLS||BGP|| IPv4 / IPv6 ||Ethernet|
>
> ||||||||
>
> +------------++------------++-------------++------------+
>
> The text in that section becomes...
>
> As previously noted,  provides a 
> classification
>
> of YANG data modules.It introduces the term "Network Service YANG 
> Module" to
>
> identify the type of module used to "describe the configuration, state 
> data,
>
> operations and notifications of abstract representations of services 
> implemented
>
> on one or multiple network elements."These modules are used to 
> construct the
>
> service delivery models as described in this document; that is, they 
> are the
>
> modules used on the interface between the Service Orchestrator or 
> OSS/BSS and
>
> the Network Orchestrator as shown in .
>
> Figure 1 of  can be modified to make this 
> more clear
>
> and to add an additional example of a Network Service YANG module as 
> shown in
>
> .As can be seen, the highest classification of 
> modules
>
> collects those that are used to deliver operations support and 
> business support.
>
> These might be consumed by an Operations Support System (OSS) or a 
> Business Support
>
> System (BSS), and a Service Orchestrator may form part of an OSS/BSS 
> or may be a
>
> separate component.This highest layer in the figure is divided into 
> the Customer
>
> Service Modules that are used to describe services to a customer as 
> discussed in
>
> this document, and other modules that describe further OSS/BSS 
> function such as
>
> billing and SLAs.
>
Fine with me.
>
> > - section 6.2 "service delivery and network element model work"
>
> >
>
> >Some
>
> >of these models are classified as service delivery models, while
>
> >others have details that are related to specific element
>
> >configuration and so are classed as network element models (also
>
> >called device models).
>
> >
>
> > Next to each model description, that would help the audience to 
> clarify what the correct term is:
>
> > customer service model, service delivery model, network service YANG 
> modules [RFC8199]
>
I understand the difficulty and the conscious decision.
This is however the first question readers will ask themselves, and the 
conclusion that the experts could find the answer is not a good sign. 
Anyway, let's move on.
>
> I agree, but we have made a conscious decision to not do that 
> *in*this*document*. None of the models in 6.2 is a customer service 
> model (so that part is easy), but beyond that we could not get 
> coherent advice from the authors of the listed documents. Most were 
> pretty certain that their work was "mainly network element model" 
> although some thought that they were dealing with "network wide 
> configuration" and a few thought they were "delivering services".
>

> While it would be good to get more clarity on this, it looks like we 
> are trying to retrofit an architecture on an organically evolved set 
> of modules and perhaps we shouldn't push too hard. What is important 
> in this document is to get the "Customer Service Model" piece more 
> clearly explained.
>
> > In RFC 8199, we made a distinction between model and YANG modules. 
> This is why we defined
>
> > the terms "Network Service YANG modules" and "Network Element YANG 
> modules" and not models.
>
> > You should follow this convention. After all, from the abstract, 
> this document focuses on YANG.
>
> > Ex: should "model" be replaced by "YANG module"?
>
> The definition imported from 7950 by 8199 looks like a reasonable 
> distinction and we will attempt to apply it here. I hope I am not 
> importing too much thought from SMI but isn't a "model" built from one 
> or modules? A model is used to "model" some larger entity or function, 
> while a module is used to describe a component of an entity or a 
> granular function.
>
> Probably just some cleanup needed through this document. I'll have a go.
>
> > - section 6.4 "The MEF architecture".
>
> > Do we want to mention that MEF currently focuses on the customer 
> service model?
>
> We could do this, but...
>
> Not so happy to use "currently" in an archival document.
>
> Also not comfortable about asserting in an IETF document what another 
> body is doing.
>
> And not convince that the MANO architecture is focused in the way you 
> describe.
>
> So I prefer no change for this.
>
Fair enough.

Regards, Benoit
>
> > - I'm glad you cleverly avoided the term "intend"
>
> That was intentional :-)
>
> Thanks,
>
> Adrian
>


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


  
    
  
  
    
Hi Adrian,

    

    

      
      
      
      
      
      
      
      

        
 

        
> In the same figure, could the
          "Device Configuration Model" be renamed to RFC 8199 

        
> "Network Element YANG module" (this
          is what you did in figure 4 anyway)

        
 

        
I believe we are separating the "device
          configuration model" that is used to talk to an NE, and a
          "network configuration model" used to talk to a controller
          that is responsible for a set of NEs. I think the correct
          thing is to add exactly that statement (i.e., a definition of
          the terms alongside figure 3). 
          Then the mapping of these terms should show up
          alongside Figure 4.

      

    

    ok.

    

      

        

        
 

        
But, you know what?

        
Looking at this made me go back to
          Figure 1 of RFC8199 again. And finally I understood it. That
          is probably a bit sad.

        
I had been misled (no blame associated)
          by the OSS/BSS box in the figure because that is an entity not
          a module. That made me read the horizontal lines as interfaces
          (over which the named module types are used) and the boxes as
          functional units that consume the modules.

        
Now, that 
          is a *horrible* misreading, but there we go! And
          RFC8199 has already been published, so adding clarification so
          that fools like me are not confused is not possible.

        
 

        
I believe the intention is to  only show modules and not
          things that consume or use modules.

        
So I wonder whether we should make some
          clarification in our Figure 4. Possibly it should look like...

        
 

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

        
     Operations
            Support and Business Support YANG Modules

        
 

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

        
     |                       |     |                       |

        
     |    Customer Service   |     |         Other         |            

        
     |      YANG Modules     |     |  Operations Support   |

        
     |                       |     |          and          |

        
     |  +------+   +------+  |     |    Business Support   |

        
     |  |      |   |      |  |     |      YANG Modules     |

        
     |  | L2SM |   | L3SM |  |     |                       |

        
     |  |      |   |      |  |     |                       |

        
     |  +------+   +------+  |     |                       |

        
     |                       |     |                       |

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

        
 

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

        
     Network
            Service YANG Modules

        
 

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

        
    |            |   |             |   |             |   |             |

        
    |  - L2VPN   |   |   - L2VPN   |   |    EVPN     |   |    L3VPN    |

        
    |  - VPWS    |   |   - VPLS    |   |             |   |             |

        
    |            |   |             |   |             |   |             |

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

        
 

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

        
     Network
            Element YANG Modules

        
 

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

        
     |            |  |            |  |             |  |            |

        
     |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |

        
     |            |  |            |  |             |  |            |

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

        
 

        
The text in that section becomes...

        
 

        
          
          <t>As previously noted, <xref target="RFC8199"
          /> provides a classification

        
          
          of YANG data modules.  It
          introduces the term "Network Service YANG Module" to

        
          
          identify the type of module used to "describe the
          configuration, state data,

        
          
          operations and notifications of abstract
          representations of services implemented

        
          
          on one or multiple network elements."  These modules are used to
          construct the 

        
           service
          delivery models as described in this document; that is, they
          are the 

        
           modules
          used on the interface between the Service Orchestrator or
          OSS/BSS and

        
          
          the Network Orchestrator as shown in <xref
          target="svc_arch" />.</t>

        
 

        
          
          <t>Figure 1 of <xref target="RFC8199" />
          can be modified to make this more clear

        
          
          and to add an additional example of a Network Service
          YANG module as shown in

        
          
          <xref target="modfig" />.  As can be seen, the
          highest classification of modules

        
          
          collects those that are used to deliver operations
          support and business support.

        
          
          These might be consumed by an Operations Support System
          (OSS) or a Business Support

        
          
          System (BSS), and a Service Orchestrator may form part
          of an OSS/BSS or may be a

        
          
          separate component.  This
          highest layer in the figure is divided into the Customer

        
          
          Service Modules that are used to describe services to a
          customer as discussed in

        
          
          this document, and other modules that describe further
          OSS/BSS function such as

        
          
          billing and SLAs.</t>

      

    

    Fine with me.

    

      

        

        
 

        
> - section 6.2 "service delivery and
          network element model work"

        
> 

        
>   Some

        
>  of
          these models are classified as service delivery models, while

        
>   others
          have details that are related to specific element

        
>   configuration
          and so are classed as network element models (also

        
>   called
          device models).

        
> 

        
> Next to each model description,
          that would help the audience to clarify what the correct term
          is:

        
> customer service model, service
          delivery model, network service YANG modules [RFC8199]

      

    

    I understand the difficulty and the conscious decision.

    This is however the first question readers will ask themselves, and
    the conclusion that the experts could find the answer is not a good
    sign. Anyway, let's move on.

    

      

        

        
 

        
I agree, but we have made a conscious
          decision to not do that *in*this*document*. None of the models
          in 6.2 is a customer service model (so that part is easy), but
          beyond that we could not get coherent advice from the authors
          of the listed documents. Most were pretty certain that their
          work was "mainly network element model" although some thought
          that they were dealing with "network wide configuration" and a
          few thought they were "delivering services".

      

    

    

    

      

        

        
 

        
While it would be good to get more
          clarity on this, it looks like we are trying to retrofit an
          architecture on an organically evolved set of modules and
          perhaps we shouldn't push too hard. What is important in this
          document is to get the "Customer Service Model" piece more
          clearly explained.

        
 

        
> In RFC 8199, we made a distinction
          between model and YANG modules. This is why we defined

        
> the terms "Network Service YANG
          modules" and "Network Element YANG modules" and not models.

        
> You should follow this convention.
          After all, from the abstract, this document focuses on YANG.

        
> Ex: should "model" be replaced by
          "YANG module"?

        
 

        
The definition imported from 7950 by
          8199 looks like a reasonable distinction and we will attempt
          to apply it here. I hope I am not importing too much thought
          from SMI but isn't a "model" built from one or modules? A
          model is used to "model" some larger entity or function, while
          a module is used to describe a component of an entity or a
          granular function.

        
 

        
Probably just some cleanup needed
          through this document. I'll have a go.

        
 

        
> - section 6.4 "The MEF
          architecture".

        
> Do we want to mention that MEF
          currently focuses on the customer service model?

        
 

        
We could do this, but...

        
Not so happy to use "currently" in an
          archival document.

        
Also not comfortable about asserting in
          an IETF document what another body is doing.

        
And not convince that the MANO
          architecture is focused in the way you describe.

        
 

        
So I prefer no change for this.

      

    

    Fair enough.

    

    Regards, Benoit

    

      

        

        
 

        
> - I'm glad you cleverly avoided the
          term "intend"

        
 

        
That was intentional :-)

        
 

        
Thanks,

        
Adrian

      

    

    

  


--------------59D83680C5B3A92893D1A98A--


From nobody Wed Sep 27 02:28:00 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 E7AA61348B1 for ; Wed, 27 Sep 2017 02:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ux9AmIsAj0lG for ; Wed, 27 Sep 2017 02:27:56 -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 E3E2B1348B6 for ; Wed, 27 Sep 2017 02:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9913; q=dns/txt; s=iport; t=1506504476; x=1507714076; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fWeHtyKzjlrB9qsKoDzyEt5y/wDvtk5nq6n+5D9tG/Q=; b=kUwnvkikh8e2Pbq5ZBomatp55otfoRE4o+EOAvYBK9FO0uFfOzeZj9lV G7vje9nmlue8xIF657MjRi7OjOYbLppWe61U4Q00PwlSWcI7CRaXsf1YW AN/mDTLFS1IdZ+R2ALPh2wynIDODTc866/54q+BCcTYh74pGampeUguOV Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgDebstZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhEBuhB2LE5BcIpBthUyCBAoehR0ChRkVAQIBAQEBAQEBayiFGQEEASN?= =?us-ascii?q?LCwULC0ICAlcGAQwIAQEWig8IEKgQgicnilsBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RkFgyuDU4IVC4JygzKBOoMrgmAFihqXBodejH+CE4Vug1okhwaNbodZgTk1IoE?= =?us-ascii?q?OMiEIHRVJhx8+iGEBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,444,1500940800";  d="scan'208,217";a="656037951"
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; 27 Sep 2017 09:27:31 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8R9RVli003285; Wed, 27 Sep 2017 09:27:31 GMT
To: adrian@olddog.co.uk, "'Warren Kumari'" 
Cc: opsawg@ietf.org
References: <00f601d3353e$e0dfbc80$a29f3580$@olddog.co.uk>
From: Benoit Claise 
Message-ID: <1ba25306-8333-7344-c571-44d0d74cf210@cisco.com>
Date: Wed, 27 Sep 2017 11:27:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <00f601d3353e$e0dfbc80$a29f3580$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------91298E0ABFAF2AE75284519A"
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] AD Review of draft-ietf-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: Wed, 27 Sep 2017 09:27:59 -0000

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

Hi Adrian,

Some of this has been discussed on YANG doctors list some time ago. Bad 
luck, before it was archived.
Good news, I explained the conclusions on the NETMOD mailing list. See 
https://mailarchive.ietf.org/arch/search/?email_list=netmod&q=Terminology+%3D%3E+YANG+module+versus+YANG+data+model+versus+YANG+model+%3A+please+don%27t+use+%22YANG+model%22+any+longer

So in our document, we removed the term "YANG model".
Personally, I try to avoid the term "YANG data model". If it's written 
in YANG, then it's a YANG _module_.
And the term "data model" is a more generic term, regardless of the 
language (SMI, YANG, etc.)

Are we consistent across all documents? No
Should we try to be consistent? Ideally
Am I going to hold a DISCUSS on this? Absolutely not.

Bottom line, do your best. That should be an easy enough guideline, right?
So "my inclination is to include pointers to the 7950 definitions, and 
to carefully re-read the text in our draft" is about right.

Regards, Benoit

> Hi Benoit,
>
>>> In RFC 8199, we made a distinction between model and YANG modules.
>>> This is why we defined the terms "Network Service YANG modules" and
>>> "Network Element YANG modules" and not models.  You should follow this
>>> convention. After all, from the abstract, this document focuses on YANG.
>>> Ex: should "model" be replaced by "YANG module"?
>> The definition imported from 7950 by 8199 looks like a reasonable distinction
>> and we will attempt to apply it here. I hope I am not importing too much
>> thought from SMI but isn't a "model" built from one or modules? A model is
>> used to "model" some larger entity or function, while a module is used to
>> describe a component of an entity or a granular function.
>>
>> Probably just some cleanup needed through this document. I'll have a go.
> Well, now I'm struggling and I wonder if you can help.
>
> What I see from 7950 is that a "YANG module" is a compilable blob of YANG that may include other modules or specific constructs from another module. That is clear enough.
>
> What is less clear is what a "data model" is or is not. I think that if, for example, I wanted to model a router, I would construct a data model from one or mode YANG modules that encode various aspects of the router. You could, I suppose, present that construct as a module its own right.
>
> And that leads me to ask you when it is appropriate to use term "data model".
>
> 8199 doesn't offer me a lot of clarity. For example, section 1 says:
>        For example, a
>        Layer 2 Virtual Private Network (L2VPN) YANG module might be a
>        Network Service YANG Module, ready to be used as a service model
>        by a network operator.
>
> Later (in 2.1) it says that a module "describes an abstract model"
> And (in 2.2) that a module "provides a coherent data model representation"
>
> All this means (I think) that modules are documentation, but models are used.
>
> It's all a bit esoteric for me and I can't find a way forward :-(
>
> What I want to do is observe that:
> - Modules a constructed from YANG and may include other whole YANG
>     modules or specific elements from other YANG modules
> - Modules describe may define pieces of modelling that are only useful
>     when applied in a context. For example, a module might define a YANG
>     construct for a timestamp or an interface, but those constructs would
>     only be useful when included in another module that gave context to
>     the timestamp or interface.
> - Modules may also describe data models for components or
>     sub-components of a managed system (often by including YANG from
>     other modules).
> - Not all modules provide data models that are independently useful,
>     but some do. And one example is that when we want to model something
>     like a service, we use a service model that is presented in a single YANG
>     module. Thus, it is perfectly reasonable that 7223 is called "A YANG Data
>     Model for Interface Management" and 8049 is a "YANG Data Model for
>     L3VPN Service Delivery".
>   
> So, my inclination is to include pointers to the 7950 definitions, and to carefully re-read the text in our draft, but not to make a wholesale change of terms.
>
> Any clues?
>
> Thanks,
> Adrian
>
> .
>


--------------91298E0ABFAF2AE75284519A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Adrian,

      

      Some of this has been discussed on YANG doctors list some time
      ago. Bad luck, before it was archived.

      Good news, I explained the conclusions on the NETMOD mailing list.
      See
https://mailarchive.ietf.org/arch/search/?email_list=netmod&q=Terminology+%3D%3E+YANG+module+versus+YANG+data+model+versus+YANG+model+%3A+please+don%27t+use+%22YANG+model%22+any+longer

      

      So in our document, we removed the term "YANG model". 

      Personally, I try to avoid the term "YANG data model". If it's
      written in YANG, then it's a YANG module.

      And the term "data model" is a more generic term, regardless of
      the language (SMI, YANG, etc.)

      

      Are we consistent across all documents? No 

      Should we try to be consistent? Ideally

      Am I going to hold a DISCUSS on this? Absolutely not.

      

      Bottom line, do your best. That should be an easy enough
      guideline, right?

      So "my inclination is to include pointers to the 7950 definitions,
      and to carefully re-read the text in our draft" is about right. 

      

      Regards, Benoit

      

    

    

      
Hi Benoit,



      

        

          
In RFC 8199, we made a distinction between model and YANG modules.
This is why we defined the terms "Network Service YANG modules" and
"Network Element YANG modules" and not models.  You should follow this
convention. After all, from the abstract, this document focuses on YANG.
Ex: should "model" be replaced by "YANG module"?


        

        
The definition imported from 7950 by 8199 looks like a reasonable distinction
and we will attempt to apply it here. I hope I am not importing too much 
thought from SMI but isn't a "model" built from one or modules? A model is
used to "model" some larger entity or function, while a module is used to
describe a component of an entity or a granular function.

Probably just some cleanup needed through this document. I'll have a go.


      

      
Well, now I'm struggling and I wonder if you can help.

What I see from 7950 is that a "YANG module" is a compilable blob of YANG that may include other modules or specific constructs from another module. That is clear enough.

What is less clear is what a "data model" is or is not. I think that if, for example, I wanted to model a router, I would construct a data model from one or mode YANG modules that encode various aspects of the router. You could, I suppose, present that construct as a module its own right. 

And that leads me to ask you when it is appropriate to use term "data model".

8199 doesn't offer me a lot of clarity. For example, section 1 says:
      For example, a
      Layer 2 Virtual Private Network (L2VPN) YANG module might be a
      Network Service YANG Module, ready to be used as a service model
      by a network operator.

Later (in 2.1) it says that a module "describes an abstract model"
And (in 2.2) that a module "provides a coherent data model representation"

All this means (I think) that modules are documentation, but models are used.

It's all a bit esoteric for me and I can't find a way forward :-(

What I want to do is observe that:
- Modules a constructed from YANG and may include other whole YANG
   modules or specific elements from other YANG modules
- Modules describe may define pieces of modelling that are only useful
   when applied in a context. For example, a module might define a YANG
   construct for a timestamp or an interface, but those constructs would 
   only be useful when included in another module that gave context to
   the timestamp or interface.
- Modules may also describe data models for components or
   sub-components of a managed system (often by including YANG from
   other modules).
- Not all modules provide data models that are independently useful,
   but some do. And one example is that when we want to model something
   like a service, we use a service model that is presented in a single YANG
   module. Thus, it is perfectly reasonable that 7223 is called "A YANG Data
   Model for Interface Management" and 8049 is a "YANG Data Model for
   L3VPN Service Delivery".
 
So, my inclination is to include pointers to the 7950 definitions, and to carefully re-read the text in our draft, but not to make a wholesale change of terms.

Any clues?

Thanks,
Adrian

.



    

    

  


--------------91298E0ABFAF2AE75284519A--


From nobody Wed Sep 27 03:34: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 D67C8134684; Wed, 27 Sep 2017 03:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ifrivET-MZVn; Wed, 27 Sep 2017 03:34:32 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5171345AE; Wed, 27 Sep 2017 03:34:31 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8RAYSW3009724; Wed, 27 Sep 2017 11:34:29 +0100
Received: from 950129200 (218.122.115.87.dyn.plus.net [87.115.122.218]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8RAYPZJ009629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2017 11:34:28 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Robert Sparks'" , 
Cc: , , 
References: <150592002817.29335.8762036344417909160@ietfa.amsl.com>
In-Reply-To: <150592002817.29335.8762036344417909160@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 11:34:21 +0100
Message-ID: <040501d3377c$2fc5c940$8f515bc0$@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: AQF4nlKXHvtRoZ3nBAUKfDu5BedhnKN9r7SA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23354.005
X-TM-AS-Result: No--8.837-10.0-31-10
X-imss-scan-details: No--8.837-10.0-31-10
X-TMASE-MatchedRID: VPleTT1nwdSnykMun0J1wvHkpkyUphL9IfyQNHR2naZXPwnnY5XL5IrJ LtnzLZWOGB47tH/7BLfyXH6dEQg1mv9/CfUC4LZKU+OjsPhIWDj4uJ1REX4MHSgMxnfFXjiIK93 7aFdF5XOoqk9quFGZe5KnBNxYrreWsEBAuoaUqK/5wpfrIJDXe3xKrqNquhWx3ZqGWCMdqrdyE1 VHvQXnDiOP5gi3f9kCkZOl7WKIImq0P2qkGU0XygtuKBGekqUpbGVEmIfjf3vkrMJ0jtvZ6OKyA ydaH0Qo4IM8agKIeKhmvPOgYj6uP3SjCqt066pw
Archived-At: 
Subject: Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-service-model-explained-03
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, 27 Sep 2017 10:34:34 -0000

Thanks Robert,

> I don't have text to suggest, but please look at the first bullet of section
5.
> The explanation here was less helpful than the other bullets. Demonstrating
the
> confusion due to the reuse of the word "service" doesn't help clarify the
> confusion. I wonder if there's more conversation that hasn't been captured
that
> this paragraph is alluding to.

Yes, the paragraph is not as clear as it could be. We were trying to distinguish
between different uses of the word "service" where we are primarily interested
in connectivity services achieved by manipulating the network resources, and not
value-added services provided using other resources (compute, storage, ...) that
are reachable over the network.

I have tried to make this a bit clearer.

> (nit) I also suggest raising the level of abstraction in the security
> consideration section where it currently lists authorization, authentication,
> and encryption by speaking initially to what, and calling the how out as a
> detail.

OK

Adrian


From nobody Wed Sep 27 03:53: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 1EC18134846; Wed, 27 Sep 2017 03:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 1rwEQqjoZPmX; Wed, 27 Sep 2017 03:52:59 -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 1DE5813430E; Wed, 27 Sep 2017 03:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1506509579; x=1507719179; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yy1FYUKHDm+4jTq6SWhRPJrz3f6hHatWVIvNGsvUD48=; b=HdsxObipHAqiVRWUltogKHnFhqEfRFMYl/AecB8A5BL2kGRy5zJjBMYN IxXn4P4xUGmm0SuhUPWSgOfQ9TyGaDeT9UPgy+3sphdL4MWH941CYFjbV u+bvBkoMG08xm7g/7lG7NL4x0zodel39ZXhAy+uSzuicOXyMNoCkb2oBj s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAADBgstZ/xbLJq1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRAbieDdoofdJA+lk2CEgoYDYUWAoUXGAECAQEBAQEBAWsdC4U?= =?us-ascii?q?ZAgEDAQEhFTYLEAsaAiYCAicwBg0GAgEBBYooEDKoIYIniwMBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBH4EOgh2DU4FqKwuCcoMyhGWCYAWhIIdejH+CE1uFE4NahyqNHlC?= =?us-ascii?q?HWYE5HzgZKUwyIQgdFR8qhx8+NgEBhWkrghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,444,1500940800"; d="scan'208";a="657860488"
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; 27 Sep 2017 10:52:54 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8RAqsYM031504; Wed, 27 Sep 2017 10:52:54 GMT
To: "draft-ietf-opsawg-nat-yang@ietf.org" 
Cc: opsawg@ietf.org
References: <150573857595.29085.1183832890030255439@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: <240f7d79-a65d-0746-1ee1-dd593dfdea38@cisco.com>
Date: Wed, 27 Sep 2017 12:52:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150573857595.29085.1183832890030255439@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-03.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 10:53:01 -0000

Hi,

Great. This YANG module now correctly validates and is NMDA compliant.
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-l2vpn-svc@2017-08-25.yang

Regards, Benoit
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Operations and Management Area Working Group WG of the IETF.
>
>          Title           : A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT)
>          Authors         : Mohamed Boucadair
>                            Senthil Sivakumar
>                            Christian Jacquenet
>                            Suresh Vinapamula
>                            Qin Wu
> 	Filename        : draft-ietf-opsawg-nat-yang-03.txt
> 	Pages           : 76
> 	Date            : 2017-09-18
>
> Abstract:
>     For the sake of network automation and the need for programming
>     Network Address Translation (NAT) function in particular, a data
>     model for configuring and managing the NAT is essential.  This
>     document defines a YANG data model for the NAT function.
>
>     NAT44, Network Address and Protocol Translation from IPv6 Clients to
>     IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
>     Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and
>     IPv6 Network Prefix Translation (NPTv6) are covered in this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-03
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-03
>
>
> 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/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> .
>


From nobody Wed Sep 27 04:23:44 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 999A3132D54; Wed, 27 Sep 2017 04:23:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150651141756.25047.8155425837483985297@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 04:23:37 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-model-explained-04.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 11:23:38 -0000

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

        Title           : Service Models Explained
        Authors         : Qin Wu
                          Will Liu
                          Adrian Farrel
	Filename        : draft-ietf-opsawg-service-model-explained-04.txt
	Pages           : 22
	Date            : 2017-09-27

Abstract:
   The IETF has produced many modules in the YANG modeling language.
   The majority of these modules are used to construct data models to
   model devices or monolithic functions.

   A small number of YANG modules have been defined to model services
   (for example, the Layer Three Virtual Private Network Service Model
   produced by the L3SM working group and documented in RFC 8049).

   This document describes service models as used within the IETF, and
   also shows where a service model might fit into a Software Defined
   Networking architecture.  Note that service models do not make any
   assumption of how a service is actually engineered and delivered for
   a customer; details of how network protocols and devices are
   engineered to deliver a service are captured in other modules that
   are not exposed through the Customer-Provider Interface.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-service-model-explained-04
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model-explained-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-model-explained-04


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 Sep 27 05:36: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 D8CE0134A8C for ; Wed, 27 Sep 2017 05:36:09 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y-Th_Eaj2x_L for ; Wed, 27 Sep 2017 05:36:06 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174AA134A2E for ; Wed, 27 Sep 2017 05:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16381; q=dns/txt; s=iport; t=1506515765; x=1507725365; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=UBIT2p9abz1hU6ZwNE0UAXj8UhoNoyoWyAaB3DnkFwM=; b=Sem/jXsFy332UxwdycFO33X5D30utohXyVIj/OJjZ5ZGG6LuG6MwvjMU MtpseGWtPFhWG87VRM1YcmtycIIW2V8iV8S+I+wEENp14rQhCGrjelek6 lzAnXYAktCVKkEveRL+DgqgSvsaIxy1gGKd+iTwt0XjK6LUt2hKTbES1P E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAACZmstZ/4QNJK1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNcZG4ng3iKH49egVQijVCIWw6CBAoYC4RJTwKEWj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQECAQEBIQ8BOwsMBAsRBAEBAQICIwMCAicfCQgGAQwGAgEBF?= =?us-ascii?q?4oOCBCoeIIniwQBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ6CHYICgVGBaisLgnK?= =?us-ascii?q?BJIIOgRoNBQYBAYMxgmABBIoShymPaIdejQGCE1uFE4NaJIcHcIkdizyBOR84g?= =?us-ascii?q?Q5TJRUfKoccHSQ2h20OGIIcAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800"; d="scan'208";a="300635537"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2017 12:36:04 +0000
Received: from [10.150.54.223] (dhcp-10-150-54-223.cisco.com [10.150.54.223]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8RCa3Qn015957; Wed, 27 Sep 2017 12:36:04 GMT
To: mohamed.boucadair@orange.com, "opsawg@ietf.org" 
Cc: "Poscic, Kristian (Nokia - US) (kristian.poscic@nokia.com)" 
References: <787AE7BB302AE849A7480A190F8B93300A02DF87@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05F3CAD8-36D4-48B0-8989-82F1B965D0A2@nokia.com>  <787AE7BB302AE849A7480A190F8B93300A04606F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A04961A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Wed, 27 Sep 2017 08:36:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A04961A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01
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, 27 Sep 2017 12:36:10 -0000

On 9/26/17 10:06, mohamed.boucadair@orange.com wrote:
> Dear OPSAWG,
> 
> I have requested an external review of the draft from a vendor who is not a co-author of the draft. 
> 
> Kris (cced) has kindly shared his comments about the current structure of the module and voiced for some features (mainly to allow for distinct pools; each with its specific parameters). I'm forwarding the latest exchange.
> 
> As you can read in the exchange below, the current version of the draft allows to achieve the same objective by defining multiple NAT instances. Each of these instances may have its own parameters and policies. Further, the draft allows to define multiple pools within the same instance, but it is silent about how to bind specific flows to a given pool. The initial reason was that we wanted to focus on the NAT function rather than overloading the module with advanced classification functions (that are not specific to NAT). 
> 
> Of course, we will continue the discussion with Kris to figure out which changes are to be implemented. In the meantime, inputs from the working group are more than welcome.  

Speaking as a co-chair, I would want to avoid over-complicating the
model to the point that it can never be ratified.  Adding policy and
other non-NAT items would conflate the scope.

Speaking as an individual -- and maybe this is what you mean by the
multiple instances -- wouldn't the ability to have routing contexts act
as inside and outside of each other be covered in your draft today?

Joe

> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.poscic@nokia.com]
>> Envoyé : mardi 26 septembre 2017 00:31
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : draft-ietf-opsawg-nat-yang@ietf.org
>> Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01
>>
>> Hi Med,
>> Sorry for the late reply, this time from my side.
>> We can continue in whichever way is the most efficient in your opinion.
>> I'm OK either way.
>>
>> I replied to your comments inline.
>> But my preference would be that this (NAT YANG model) is a more modular,
>> i.e. have building blocks.
>> Current model is a bit too monolithic and maybe even CE centric.
>>
>> We (Nokia) will be able to consolidate some configuration data and maybe
>> even make it within a single configuration instance.
>> For example, for inside make it a 'choice' between interface and entire
>> 'vrf' (not sure how you want to call this if not routing context); same
>> for outside.
>> This way we can say the whole VRF is the inside and another (or the same)
>> whole VRF is outside, which means that routing is used to determine where
>> the translated packet needs to go out (this is how we do it, there no
>> interfaces in our NAT for the reason I specified below - transport
>> independent).
>>
>> But in general, my idea would be:
>>
>> - your NAT instance kinds of defines what gets mapped where
>>
>> But then outside of the nat-instance you have a bunch of other
>> configuration that can be referenced from inside this nat-instance
>> (classifiers and different policies).
>> For example, when certain traffic is mapped to a pool, then this traffic
>> may have different NAT parameters (ALGs, TCP/UDP timers, etc) than some
>> other traffic that is mapped to a different pool within the same NAT
>> instance. This kind of flexibility should exist. Thanks.
>> Kris
>>
>> -----Original Message-----
>> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
>> Sent: Wednesday, September 20, 2017 3:51 AM
>> To: Poscic, Kristian (Nokia - US) 
>> Cc: draft-ietf-opsawg-nat-yang@ietf.org
>> Subject: RE: Request to review draft-ietf-opsawg-nat-yang-01
>>
>> Hi Kris,
>>
>> (ccing my co-authors)
>>
>> Apologies for the delay to answer. I was out of office.
>>
>> Thank you very much for sharing the comments. Much appreciated!
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.poscic@nokia.com]
>>> Envoyé : mercredi 13 septembre 2017 23:01 À : BOUCADAIR Mohamed
>>> IMT/OLN Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01
>>>
>>> Hi Med,
>>>
>>> Wim asked me to review this draft and I here I provide my feedback.
>>
>> [Med] Thank you.
>>
>>> Unfortunately it does not line-up with our implementation. It seems
>>> that this model configures everything under the same nat instance
>>> (private side, public side and all the other config options).
>>
>> [Med] As a reminder, the module covers both "simple NAT" (that you can
>> find in a CPE) and more advanced ones like your implementation. As such
>> the module allows:
>> - an implementation to determine its internal/external interfaces in its
>> own. This is typically the residential gateway case.
>> - instruct an implementation about the external interface(s) to which to
>> bind the NAT with or without filter on the internal interface(s).
>>
>>
>> [Kris] Ok, thanks for mentioning this, I'll talk from the CGN perspective,
>> scalable version of NAT deployed in SP networks (not the CE).
>> I'm not sure that the interface is the right way to go. I think this
>> should be based on the routes. So you translate the packet and then let
>> the routing decides where to go. Different transports my encapsulate this
>> packet differently on egress (MPLS/GRE, etc.) and this is interface
>> independent.
>> ---------------------
>> If no indication is provided, all the traffic that is send/received on an
>> external interface is NATed.
>> If subscriber-match is provided, the NAT will be applied only if that
>> filter matches.
>>
>> [Kris]  In this case this is based only on dest prefix. But sometimes it
>> should be based on filters which are more flexible in identifying what
>> should be translated (for example translate only traffic coming from these
>> source IP addresses, or only going to those destination ports, ect).
>> So I'm talking about real IP filters (or access-lists, however you call
>> them) that are applied to interfaces.
>> -------------------------------------------
>> If nat-pass-through is provided, all the traffic will be NATed except the
>> one that matches the nat-pass-through filter(s).
>>
>> The current version allows to define multiple pools; each identified by an
>> id. This id can be called typically for advanced filtering operations.
>> Such filters are not supported in the current version. I'm open to discuss
>> those with you.
>>
>>
>> [Kris] yes, this is important. What is needed is a sort of classification
>> block, where you say 'this traffic' is mapped to this 'pool'.
>> This should be done via ip-filters that are applied to interfaces, and
>> thus all together outside of NAT instance, or on a coarser level via
>> subscriber-match that is a list with a  leaf that accepts not only ip-
>> prefix but a pool id (leafref) as well.
>>
>> Talking about multiple pools, it is possible that pools have different
>> settings (max number of subs per outside IP address, etc). So pool config
>> should have additional parameters (pool should be a list with multiple
>> leafs). So we allow this today, a very flexible config that may now get
>> restricted because of configuration constraints.
>>
>> ----------------
>> The reason why such advanced filters are not included is that the same
>> objective can be achieved by defining multiple NAT instances; each with
>> dedicated pools and port assignment policies .
>>
>>
>> [Kris] True, but I was hoping that a more elegant solution can be found.
>> Otherwise a new NAT instance would be required per pool. NAT instance even
>> in your proposal supports multiple pools, it would be nice to find a way
>> to selectively map traffic to those pools within the context of a NAT
>> instance.
>>
>> Please note that a similar feature is supported for NAT64: the NAT64
>> prefix can be selected as a function of the destination prefix.
>>
>>              +--rw nat64-prefixes* [nat64-prefix]
>>              |  +--rw nat64-prefix               inet:ipv6-prefix
>>              |  +--rw destination-ipv4-prefix* [ipv4-prefix]
>>              |     +--rw ipv4-prefix    inet:ipv4-prefix
>>
>> One minor comment: from an IETF standpoint, "routing context" may be
>> confusing for people as NAT is not a routing function.
>>
>>>
>>> We have a different approach, with three main building blocks:
>>>
>>> 1)  in inside (private) routing context we define parameters that are
>>> related to inside. For example destination-prefix (what will get sent
>>> to NAT for translation) in NAT44, then NAT64 prefix, deterministic nat
>>> parameters, DS-lite AFTR address (I know that ds-lite is covered in
>>> different draft), some other L2-Aware NAT parameters, etc.
>>
>> [Med] Putting aside that we mark explicitly those parameters as "inside",
>> most of those parameters are supported in this version (and the DS-Lite
>> YANG).
>>
>>> 2) then we go to outside routing contextS. There we define pool and
>>> pool related parameters: outside-address range, pool watermarks, size
>>> of the port-blocks in the pool, port-forwarding ranges in the pool,
>>> number of subscribers per outside IP, etc.
>>
>> [Med] Great. Putting aside that we mark explicitly those parameters as
>> "outside", those parameters are supported in this version.
>>
>>> 3) then we have a nat-policy that serves as a glue that connects the
>>> inside routing context and the outside routing contexts (can be more
>>> of
>>> them) and the pools.
>>> In nat-policy  definition we reference a pool, enable ALGs, set the
>>> session limit per subscriber, number of port-blocks per subscriber,
>>> filtering mode, priority sessions (based on forwarding-class), timouts
>>> (tpc, udp, icmp), etc.
>>> This policy is then referenced in the inside routing context. At that
>>> point when the packet is received in the inside, it knows which pool
>>> (and outside routing context) it needs to go to - based on the
>>> classification in the ip-filter with action NAT (applied to an
>>> interface) or based on the destination-prefix (as configured in the
>> inside routing context).
>>>
>>> The key is that we allow forking to multiple pools from the same
>>> inside routing context. For example:
>>> Destination-prefix   10.10.10.0/24 nat-policy "nat-pol-name-1"    ==>
>> nat-
>>> pol-name-1 references a pool and the outside routing context
>>> Destination-prefix 10.20.20.0/24 nat policy "nat-pol-name-2"  ==>
>>> nat-pol-
>>> name-2 reference a different pool in the same outside routing context
>>> as above or a different one
>>>
>>> (same can be achieved with filters that are applied to interfaces -
>>> with filters we have a much wider range of classification options -
>>> what gets diverted to NAT).
>>
>> [Med] Agree. Those are out of the scope.
>>
>>>
>>> Then on a side, we have nat-classifiers that deal with destination-nat.
>>> There we identify traffic that needs to be dNTAed and we specify the
>>> dest- ip address in the same classifier. This classifier is then
>>> applied in nat- policy as well.
>>>
>>> There are a few other pieces that deal with logging, pcp etc functions
>>> that are scattered around, but this can be consolidated. But I'm
>>> afraid that this 3 prong structure (inside, outside, nat-policy) would
>>> be harder to consolidate.
>>>
>>>
>>> From your proposal in the draft, I'm not clear how do you ensure
>>> separation of routing context and selection of different pools.
>>
>> [Med] As mentioned above, the current model does support this by defining
>> multiple NAT instances.
>>
>>  I see that
>>> inside interfaces and outside interfaces are referenced in the nat-
>>> instance, but there is no mention of routing context (although this
>>> can be derived from the interface name, assuming that intf name are
>>> unique chassis wide). Moreover I can't see how do you ensure selection
>>> of a pool based on some classification on ingress (say
>>> destination-prefix A go to pool 1, destination-prefix B to pool 2).
>>
>> [Med] This is not supported within the same NAT instance. I'm open to
>> discuss if/how to update the module to include this feature.
>>
>>>
>>>
>>> We definitely want to be part of this discussion
>>
>> [Med] Great!
>>
>> , but at this point I'm
>>> not sure how to proceed. It would be great if you can advise. Thanks.
>>
>> [Med] I see the following options:
>> (1) Continue the discussion in private to figure out what modifications
>> can be implemented to address your comments.
>> (2) Forward this mail to the OPSAWG mailing list and take it for there.
>>
>> Proceeding with both is also an option. For example, I can start by
>> sharing your concern with the WG and then discuss in private how to
>> address it.
>>
>> Please let me know your preference.
>>
>>> Kris
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Henderickx, Wim (Nokia - BE/Antwerp)
>>> Sent: Thursday, August 31, 2017 11:31 PM
>>> To: Poscic, Kristian (Nokia - US) 
>>> Subject: FW: Request to review draft-ietf-opsawg-nat-yang-01
>>>
>>> Can you comments on this?
>>>
>>> On 22/08/2017, 14:23, "mohamed.boucadair@orange.com"
>>>  wrote:
>>>
>>>     Hi Wim,
>>>
>>>     I hope you are doing well!
>>>
>>>     Can you please review this model? I'm particularly interested to
>>> see if the model is aligned with your 7750 NAT44/NAT64 implementation.
>>>
>>>     Thank you.
>>>
>>>     Cheers,
>>>     Med
>>>
>>>     > -----Message d'origine-----
>>>     > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>     > Envoyé : lundi 21 août 2017 11:10
>>>     > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET
>>> Christian
>>>     > IMT/OLN; opsawg-chairs@ietf.org; Qin Wu
>>>     > Objet : New Version Notification for draft-ietf-opsawg-nat-yang-
>>> 01.txt
>>>     >
>>>     >
>>>     > A new version of I-D, draft-ietf-opsawg-nat-yang-01.txt
>>>     > has been successfully submitted by Mohamed Boucadair and posted
>>> to the
>>>     > IETF repository.
>>>     >
>>>     > Name:		draft-ietf-opsawg-nat-yang
>>>     > Revision:	01
>>>     > Title:		A YANG Data Model for Network Address Translation
>>> (NAT)
>>>     > and Network Prefix Translation (NPT)
>>>     > Document date:	2017-08-21
>>>     > Group:		opsawg
>>>     > Pages:		73
>>>     > URL:            https://www.ietf.org/internet-drafts/draft-ietf-
>>> opsawg-
>>>     > nat-yang-01.txt
>>>     > Status:         https://datatracker.ietf.org/doc/draft-ietf-
>> opsawg-
>>> nat-
>>>     > yang/
>>>     > Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-nat-
>>> yang-01
>>>     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-
>>> opsawg-
>>>     > nat-yang-01
>>>     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-
>> opsawg-
>>> nat-
>>>     > yang-01
>>>     >
>>>     > Abstract:
>>>     >    For the sake of network automation and the need for programming
>>>     >    Network Address Translation (NAT) function in particular, a
>> data
>>>     >    model for configuring and managing the NAT is essential.  This
>>>     >    document defines a YANG data model for the NAT function.
>>>     >
>>>     >    NAT44, Network Address and Protocol Translation from IPv6
>> Clients
>>> to
>>>     >    IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
>>>     >    Address Mappings for Stateless IP/ICMP Translation (SIIT EIM),
>>> and
>>>     >    IPv6 Network Prefix Translation (NPTv6) are covered in this
>>> document.
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > 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
>>>
>>>
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 


From nobody Wed Sep 27 06:23: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 18C00134BE0; Wed, 27 Sep 2017 06:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5Oh9PmUsBV3B; Wed, 27 Sep 2017 06:22:39 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68AE134BC4; Wed, 27 Sep 2017 06:20:49 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 8292D18075E; Wed, 27 Sep 2017 15:20:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 607AC1A0066; Wed, 27 Sep 2017 15:20:48 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Wed, 27 Sep 2017 15:20:47 +0200
From: 
To: Joe Clarke , "opsawg@ietf.org" 
CC: "Poscic, Kristian (Nokia - US) (kristian.poscic@nokia.com)" , "draft-ietf-opsawg-nat-yang@ietf.org" 
Thread-Topic: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01
Thread-Index: AdMbQXlvGlQjaXSWRdm5PuWt6eiZewHmZwwAAn0HPaABRY4Y8AESwLvgACdsCAAAK5MvgAAEOIww
Date: Wed, 27 Sep 2017 13:20:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A04ADED@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93300A02DF87@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05F3CAD8-36D4-48B0-8989-82F1B965D0A2@nokia.com>  <787AE7BB302AE849A7480A190F8B93300A04606F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A04961A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01
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, 27 Sep 2017 13:22:46 -0000

SGkgSm9lLCANCg0KVGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuIA0KDQpQbGVh
c2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu
ZS0tLS0tDQo+IERlwqA6IEpvZSBDbGFya2UgW21haWx0bzpqY2xhcmtlQGNpc2NvLmNvbV0NCj4g
RW52b3nDqcKgOiBtZXJjcmVkaSAyNyBzZXB0ZW1icmUgMjAxNyAxNDozNg0KPiDDgMKgOiBCT1VD
QURBSVIgTW9oYW1lZCBJTVQvT0xOOyBvcHNhd2dAaWV0Zi5vcmcNCj4gQ2PCoDogUG9zY2ljLCBL
cmlzdGlhbiAoTm9raWEgLSBVUykgKGtyaXN0aWFuLnBvc2NpY0Bub2tpYS5jb20pDQo+IE9iamV0
wqA6IFJlOiBbT1BTQVdHXSBUUjogUmVxdWVzdCB0byByZXZpZXcgZHJhZnQtaWV0Zi1vcHNhd2ct
bmF0LXlhbmctMDENCj4gDQo+IE9uIDkvMjYvMTcgMTA6MDYsIG1vaGFtZWQuYm91Y2FkYWlyQG9y
YW5nZS5jb20gd3JvdGU6DQo+ID4gRGVhciBPUFNBV0csDQo+ID4NCj4gPiBJIGhhdmUgcmVxdWVz
dGVkIGFuIGV4dGVybmFsIHJldmlldyBvZiB0aGUgZHJhZnQgZnJvbSBhIHZlbmRvciB3aG8gaXMN
Cj4gbm90IGEgY28tYXV0aG9yIG9mIHRoZSBkcmFmdC4NCj4gPg0KPiA+IEtyaXMgKGNjZWQpIGhh
cyBraW5kbHkgc2hhcmVkIGhpcyBjb21tZW50cyBhYm91dCB0aGUgY3VycmVudCBzdHJ1Y3R1cmUN
Cj4gb2YgdGhlIG1vZHVsZSBhbmQgdm9pY2VkIGZvciBzb21lIGZlYXR1cmVzIChtYWlubHkgdG8g
YWxsb3cgZm9yIGRpc3RpbmN0DQo+IHBvb2xzOyBlYWNoIHdpdGggaXRzIHNwZWNpZmljIHBhcmFt
ZXRlcnMpLiBJJ20gZm9yd2FyZGluZyB0aGUgbGF0ZXN0DQo+IGV4Y2hhbmdlLg0KPiA+DQo+ID4g
QXMgeW91IGNhbiByZWFkIGluIHRoZSBleGNoYW5nZSBiZWxvdywgdGhlIGN1cnJlbnQgdmVyc2lv
biBvZiB0aGUgZHJhZnQNCj4gYWxsb3dzIHRvIGFjaGlldmUgdGhlIHNhbWUgb2JqZWN0aXZlIGJ5
IGRlZmluaW5nIG11bHRpcGxlIE5BVCBpbnN0YW5jZXMuDQo+IEVhY2ggb2YgdGhlc2UgaW5zdGFu
Y2VzIG1heSBoYXZlIGl0cyBvd24gcGFyYW1ldGVycyBhbmQgcG9saWNpZXMuIEZ1cnRoZXIsDQo+
IHRoZSBkcmFmdCBhbGxvd3MgdG8gZGVmaW5lIG11bHRpcGxlIHBvb2xzIHdpdGhpbiB0aGUgc2Ft
ZSBpbnN0YW5jZSwgYnV0IGl0DQo+IGlzIHNpbGVudCBhYm91dCBob3cgdG8gYmluZCBzcGVjaWZp
YyBmbG93cyB0byBhIGdpdmVuIHBvb2wuIFRoZSBpbml0aWFsDQo+IHJlYXNvbiB3YXMgdGhhdCB3
ZSB3YW50ZWQgdG8gZm9jdXMgb24gdGhlIE5BVCBmdW5jdGlvbiByYXRoZXIgdGhhbg0KPiBvdmVy
bG9hZGluZyB0aGUgbW9kdWxlIHdpdGggYWR2YW5jZWQgY2xhc3NpZmljYXRpb24gZnVuY3Rpb25z
ICh0aGF0IGFyZQ0KPiBub3Qgc3BlY2lmaWMgdG8gTkFUKS4NCj4gPg0KPiA+IE9mIGNvdXJzZSwg
d2Ugd2lsbCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiB3aXRoIEtyaXMgdG8gZmlndXJlIG91dCB3
aGljaA0KPiBjaGFuZ2VzIGFyZSB0byBiZSBpbXBsZW1lbnRlZC4gSW4gdGhlIG1lYW50aW1lLCBp
bnB1dHMgZnJvbSB0aGUgd29ya2luZw0KPiBncm91cCBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuDQo+
IA0KPiBTcGVha2luZyBhcyBhIGNvLWNoYWlyLCBJIHdvdWxkIHdhbnQgdG8gYXZvaWQgb3Zlci1j
b21wbGljYXRpbmcgdGhlDQo+IG1vZGVsIHRvIHRoZSBwb2ludCB0aGF0IGl0IGNhbiBuZXZlciBi
ZSByYXRpZmllZC4NCg0KW01lZF0gU2FtZSBoZXJlIGFzIGFuIGVkaXRvciBvZiB0aGUgZG9jdW1l
bnQuIA0KDQogIEFkZGluZyBwb2xpY3kgYW5kDQo+IG90aGVyIG5vbi1OQVQgaXRlbXMgd291bGQg
Y29uZmxhdGUgdGhlIHNjb3BlLg0KDQpbTWVkXSBBbGxvd2luZyBmb3IgbXVsdGlwbGUgTkFUIGNv
bmZpZ3VyYXRpb25zIHdpdGhpbiB0aGUgc2FtZSBpbnN0YW5jZSBpcyBlYXN5IHRvIGFkZC4gDQpX
aGF0IEknbSBoZXNpdGF0aW5nIHRvIGFkZCBpcyBhZHZhbmNlZCBjbGFzc2lmaWNhdGlvbiBmaWx0
ZXJpbmcgdGhhdCBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIE5BVCBmdW5jdGlvbi4gQW4gYXBwcm9h
Y2ggSSdtIGludmVzdGlnYXRpbmcgaXM6DQotIEFkZCBhbiBpbmZvcm1hdGl2ZSBzZWN0aW9uIHRv
IHJlY29yZCB0aGUgY29tbWVudCBmcm9tIEtyaXMgKGkuZS4sIGJpbmQgYSBwYWNrZXQvZmxvdyB0
byBhIE5BVCBjb25maWd1cmF0aW9uKSBhbmQgZGVjbGFyZSBpdCBvdXQgb2Ygc2NvcGUuDQotIFN1
Z2dlc3QgdGhhdCBleHRlbnNpb25zIHRvIGlldGYtbmV0bW9kLWFjbC1tb2RlbCBtb2R1bGUgY2Fu
IGJlIGRlZmluZWQgYnkgaW1wbGVtZW50ZXJzLCBpZiBuZWVkZWQuIA0KDQo+IA0KPiBTcGVha2lu
ZyBhcyBhbiBpbmRpdmlkdWFsIC0tIGFuZCBtYXliZSB0aGlzIGlzIHdoYXQgeW91IG1lYW4gYnkg
dGhlDQo+IG11bHRpcGxlIGluc3RhbmNlcyAtLSB3b3VsZG4ndCB0aGUgYWJpbGl0eSB0byBoYXZl
IHJvdXRpbmcgY29udGV4dHMgYWN0DQo+IGFzIGluc2lkZSBhbmQgb3V0c2lkZSBvZiBlYWNoIG90
aGVyIGJlIGNvdmVyZWQgaW4geW91ciBkcmFmdCB0b2RheT8NCg0KW01lZF0gVGhlIGN1cnJlbnQg
dmVyc2lvbiBpcyBzaWxlbnQgYWJvdXQgaW5zaWRlL291dHNpZGUgcm91dGluZyBjb250ZXh0cyBw
ZXIgc2UuIFRoZSBjdXJyZW50IGFwcHJvYWNoIGFzc3VtZXMgdGhhdDogDQoqIFNvbWUgTkFUcyBh
cmUgZW1iZWRkZWQgaW4gc3lzdGVtcyB0aGF0IGFyZSBhYmxlIHRvIGRldGVybWluZSBob3cvd2hl
biB0byBpbnZva2UgdGhlIE5BVCBzZXJ2aWNlLiBUaGlzIGlzIHR5cGljYWxseSB0aGUgY2FzZSBv
ZiBOQVRzIGVtYmVkZGVkIGluIENQRXMuIEZvciBleGFtcGxlLCBhIHJlc2lkZW50aWFsIGdhdGV3
YXkgZGV0ZXJtaW5lcyBpbiBpdHMgb3duIExBTiBpbnRlcmZhY2VzIGFuZCBXQU4gaW50ZXJmYWNl
cy4NCiogU29tZSBOQVRzIG5lZWQgdG8gYmUgYm91bmQgdG8gYW4gZXh0ZXJuYWwgaW50ZXJmYWNl
IGV4cGxpY2l0bHkuIEFuIGludGVyZmFjZSBjYW4gYmUgb2YgYW55IG5hdHVyZSAocGh5c2ljYWws
IHZpcnR1YWwsIHR1bm5lbCwgZXRjLikuIFJlbWFpbmluZyBpbnRlcmZhY2VzIGFyZSBhc3N1bWVk
IHRvIGJlIGludGVybmFsIG9uZXMuICAgDQoNCktyaXMgaXMgYXNraW5nIHRvIGhhdmUgdGhlIGFi
aWxpdHkgdG8gYXNzb2NpYXRlIHRoZSBOQVQgc2VydmljZSB3aXRoIFZSRiBjb250ZXh0cywgdG9v
LiAgDQoNCkkgdGhpbmsgdGhhdCB3ZSBjYW4gYWNjb21tb2RhdGUgdGhhdCBjb21tZW50IGJ5IG1h
a2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgZHJhZnQgKHNlZSB0aGUgcHJvcG9zZWQg
Y2hhbmdlIGJlbG93KS4gSW4gb3JkZXIgdG8gYXZvaWQgY29uZmxhdGluZyB0aGUgc2NvcGUsIEkg
ZG9uJ3Qgd2FudCB0byBsaXN0IGhlcmUgZXZlcnkgcm91dGluZyBjb250ZXh0IHR5cGUsIGJ1dCB0
byBsaW1pdCB0aGUgc2NvcGUgdG8gdGhlc2UgdHdvIGNob2ljZXMuIA0KDQpPTEQ6IA0KDQogICAg
ICAgICAgICAgKy0tcncgaW50ZXJuYWwtaW50ZXJmYWNlcyogW2ludGVybmFsLWludGVyZmFjZV0N
CiAgICAgICAgICAgICB8ICArLS1ydyBpbnRlcm5hbC1pbnRlcmZhY2UgICAgaWY6aW50ZXJmYWNl
LXJlZg0KICAgICAgICAgICAgICstLXJ3IGV4dGVybmFsLWludGVyZmFjZXMqIFtleHRlcm5hbC1p
bnRlcmZhY2VdDQogICAgICAgICAgICAgfCAgKy0tcncgZXh0ZXJuYWwtaW50ZXJmYWNlICAgIGlm
OmludGVyZmFjZS1yZWYNCg0KTkVXOiANCg0KICAgICAgICAgICAgICstLXJ3IGludGVybmFsLXJl
YWxtDQogICAgICAgICAgICAgfCAgKy0tcncgKHJlYWxtLXR5cGUpPw0KICAgICAgICAgICAgIHwg
ICAgICstLTooaW50ZXJmYWNlKQ0KICAgICAgICAgICAgIHwgICAgIHwgICstLXJ3IGludGVybmFs
LWludGVyZmFjZXMqIFtpbnRlcm5hbC1pbnRlcmZhY2VdDQogICAgICAgICAgICAgfCAgICAgfCAg
ICAgKy0tcncgaW50ZXJuYWwtaW50ZXJmYWNlICAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAgICAg
ICAgICB8ICAgICArLS06KHZyZikNCiAgICAgICAgICAgICB8ICAgICAgICArLS1ydyBpbnRlcm5h
bC12cmYtaW5zdGFuY2VzKiBbaW50ZXJuYWwtdnJmLWluc3RhbmNlXQ0KICAgICAgICAgICAgIHwg
ICAgICAgICAgICstLXJ3IGludGVybmFsLXZyZi1pbnN0YW5jZSAgICBpZGVudGl0eXJlZg0KICAg
ICAgICAgICAgICstLXJ3IGV4dGVybmFsLXJlYWxtDQogICAgICAgICAgICAgfCAgKy0tcncgKHJl
YWxtLXR5cGUpPw0KICAgICAgICAgICAgIHwgICAgICstLTooaW50ZXJmYWNlKQ0KICAgICAgICAg
ICAgIHwgICAgIHwgICstLXJ3IGV4dGVybmFsLWludGVyZmFjZXMqIFtleHRlcm5hbC1pbnRlcmZh
Y2VdDQogICAgICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgZXh0ZXJuYWwtaW50ZXJmYWNlICAg
IGlmOmludGVyZmFjZS1yZWYNCiAgICAgICAgICAgICB8ICAgICArLS06KHZyZikNCiAgICAgICAg
ICAgICB8ICAgICAgICArLS1ydyBleHRlcm5hbC12cmYtaW5zdGFuY2VzKiBbZXh0ZXJuYWwtdnJm
LWluc3RhbmNlXQ0KICAgICAgICAgICAgIHwgICAgICAgICAgICstLXJ3IGV4dGVybmFsLXZyZi1p
bnN0YW5jZSAgICBpZGVudGl0eXJlZg0KDQo+IA0KPiBKb2UNCj4gDQo+ID4NCj4gPiBDaGVlcnMs
DQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERl
wqA6IFBvc2NpYywgS3Jpc3RpYW4gKE5va2lhIC0gVVMpIFttYWlsdG86a3Jpc3RpYW4ucG9zY2lj
QG5va2lhLmNvbV0NCj4gPj4gRW52b3nDqcKgOiBtYXJkaSAyNiBzZXB0ZW1icmUgMjAxNyAwMDoz
MQ0KPiA+PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+ID4+IENjwqA6IGRyYWZ0
LWlldGYtb3BzYXdnLW5hdC15YW5nQGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJFOiBSZXF1ZXN0
IHRvIHJldmlldyBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMQ0KPiA+Pg0KPiA+PiBIaSBN
ZWQsDQo+ID4+IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseSwgdGhpcyB0aW1lIGZyb20gbXkgc2lk
ZS4NCj4gPj4gV2UgY2FuIGNvbnRpbnVlIGluIHdoaWNoZXZlciB3YXkgaXMgdGhlIG1vc3QgZWZm
aWNpZW50IGluIHlvdXIgb3Bpbmlvbi4NCj4gPj4gSSdtIE9LIGVpdGhlciB3YXkuDQo+ID4+DQo+
ID4+IEkgcmVwbGllZCB0byB5b3VyIGNvbW1lbnRzIGlubGluZS4NCj4gPj4gQnV0IG15IHByZWZl
cmVuY2Ugd291bGQgYmUgdGhhdCB0aGlzIChOQVQgWUFORyBtb2RlbCkgaXMgYSBtb3JlDQo+IG1v
ZHVsYXIsDQo+ID4+IGkuZS4gaGF2ZSBidWlsZGluZyBibG9ja3MuDQo+ID4+IEN1cnJlbnQgbW9k
ZWwgaXMgYSBiaXQgdG9vIG1vbm9saXRoaWMgYW5kIG1heWJlIGV2ZW4gQ0UgY2VudHJpYy4NCj4g
Pj4NCj4gPj4gV2UgKE5va2lhKSB3aWxsIGJlIGFibGUgdG8gY29uc29saWRhdGUgc29tZSBjb25m
aWd1cmF0aW9uIGRhdGEgYW5kDQo+IG1heWJlDQo+ID4+IGV2ZW4gbWFrZSBpdCB3aXRoaW4gYSBz
aW5nbGUgY29uZmlndXJhdGlvbiBpbnN0YW5jZS4NCj4gPj4gRm9yIGV4YW1wbGUsIGZvciBpbnNp
ZGUgbWFrZSBpdCBhICdjaG9pY2UnIGJldHdlZW4gaW50ZXJmYWNlIGFuZCBlbnRpcmUNCj4gPj4g
J3ZyZicgKG5vdCBzdXJlIGhvdyB5b3Ugd2FudCB0byBjYWxsIHRoaXMgaWYgbm90IHJvdXRpbmcg
Y29udGV4dCk7IHNhbWUNCj4gPj4gZm9yIG91dHNpZGUuDQo+ID4+IFRoaXMgd2F5IHdlIGNhbiBz
YXkgdGhlIHdob2xlIFZSRiBpcyB0aGUgaW5zaWRlIGFuZCBhbm90aGVyIChvciB0aGUNCj4gc2Ft
ZSkNCj4gPj4gd2hvbGUgVlJGIGlzIG91dHNpZGUsIHdoaWNoIG1lYW5zIHRoYXQgcm91dGluZyBp
cyB1c2VkIHRvIGRldGVybWluZQ0KPiB3aGVyZQ0KPiA+PiB0aGUgdHJhbnNsYXRlZCBwYWNrZXQg
bmVlZHMgdG8gZ28gb3V0ICh0aGlzIGlzIGhvdyB3ZSBkbyBpdCwgdGhlcmUgbm8NCj4gPj4gaW50
ZXJmYWNlcyBpbiBvdXIgTkFUIGZvciB0aGUgcmVhc29uIEkgc3BlY2lmaWVkIGJlbG93IC0gdHJh
bnNwb3J0DQo+ID4+IGluZGVwZW5kZW50KS4NCj4gPj4NCj4gPj4gQnV0IGluIGdlbmVyYWwsIG15
IGlkZWEgd291bGQgYmU6DQo+ID4+DQo+ID4+IC0geW91ciBOQVQgaW5zdGFuY2Uga2luZHMgb2Yg
ZGVmaW5lcyB3aGF0IGdldHMgbWFwcGVkIHdoZXJlDQo+ID4+DQo+ID4+IEJ1dCB0aGVuIG91dHNp
ZGUgb2YgdGhlIG5hdC1pbnN0YW5jZSB5b3UgaGF2ZSBhIGJ1bmNoIG9mIG90aGVyDQo+ID4+IGNv
bmZpZ3VyYXRpb24gdGhhdCBjYW4gYmUgcmVmZXJlbmNlZCBmcm9tIGluc2lkZSB0aGlzIG5hdC1p
bnN0YW5jZQ0KPiA+PiAoY2xhc3NpZmllcnMgYW5kIGRpZmZlcmVudCBwb2xpY2llcykuDQo+ID4+
IEZvciBleGFtcGxlLCB3aGVuIGNlcnRhaW4gdHJhZmZpYyBpcyBtYXBwZWQgdG8gYSBwb29sLCB0
aGVuIHRoaXMNCj4gdHJhZmZpYw0KPiA+PiBtYXkgaGF2ZSBkaWZmZXJlbnQgTkFUIHBhcmFtZXRl
cnMgKEFMR3MsIFRDUC9VRFAgdGltZXJzLCBldGMpIHRoYW4gc29tZQ0KPiA+PiBvdGhlciB0cmFm
ZmljIHRoYXQgaXMgbWFwcGVkIHRvIGEgZGlmZmVyZW50IHBvb2wgd2l0aGluIHRoZSBzYW1lIE5B
VA0KPiA+PiBpbnN0YW5jZS4gVGhpcyBraW5kIG9mIGZsZXhpYmlsaXR5IHNob3VsZCBleGlzdC4g
VGhhbmtzLg0KPiA+PiBLcmlzDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gW21haWx0bzptb2hh
bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJl
ciAyMCwgMjAxNyAzOjUxIEFNDQo+ID4+IFRvOiBQb3NjaWMsIEtyaXN0aWFuIChOb2tpYSAtIFVT
KSA8a3Jpc3RpYW4ucG9zY2ljQG5va2lhLmNvbT4NCj4gPj4gQ2M6IGRyYWZ0LWlldGYtb3BzYXdn
LW5hdC15YW5nQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBSZXF1ZXN0IHRvIHJldmlldyBk
cmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMQ0KPiA+Pg0KPiA+PiBIaSBLcmlzLA0KPiA+Pg0K
PiA+PiAoY2NpbmcgbXkgY28tYXV0aG9ycykNCj4gPj4NCj4gPj4gQXBvbG9naWVzIGZvciB0aGUg
ZGVsYXkgdG8gYW5zd2VyLiBJIHdhcyBvdXQgb2Ygb2ZmaWNlLg0KPiA+Pg0KPiA+PiBUaGFuayB5
b3UgdmVyeSBtdWNoIGZvciBzaGFyaW5nIHRoZSBjb21tZW50cy4gTXVjaCBhcHByZWNpYXRlZCEN
Cj4gPj4NCj4gPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4g
TWVkDQo+ID4+DQo+ID4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4+IERlwqA6
IFBvc2NpYywgS3Jpc3RpYW4gKE5va2lhIC0gVVMpIFttYWlsdG86a3Jpc3RpYW4ucG9zY2ljQG5v
a2lhLmNvbV0NCj4gPj4+IEVudm95w6nCoDogbWVyY3JlZGkgMTMgc2VwdGVtYnJlIDIwMTcgMjM6
MDEgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4gPj4+IElNVC9PTE4gT2JqZXTCoDogUkU6IFJl
cXVlc3QgdG8gcmV2aWV3IGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTAxDQo+ID4+Pg0KPiA+
Pj4gSGkgTWVkLA0KPiA+Pj4NCj4gPj4+IFdpbSBhc2tlZCBtZSB0byByZXZpZXcgdGhpcyBkcmFm
dCBhbmQgSSBoZXJlIEkgcHJvdmlkZSBteSBmZWVkYmFjay4NCj4gPj4NCj4gPj4gW01lZF0gVGhh
bmsgeW91Lg0KPiA+Pg0KPiA+Pj4gVW5mb3J0dW5hdGVseSBpdCBkb2VzIG5vdCBsaW5lLXVwIHdp
dGggb3VyIGltcGxlbWVudGF0aW9uLiBJdCBzZWVtcw0KPiA+Pj4gdGhhdCB0aGlzIG1vZGVsIGNv
bmZpZ3VyZXMgZXZlcnl0aGluZyB1bmRlciB0aGUgc2FtZSBuYXQgaW5zdGFuY2UNCj4gPj4+IChw
cml2YXRlIHNpZGUsIHB1YmxpYyBzaWRlIGFuZCBhbGwgdGhlIG90aGVyIGNvbmZpZyBvcHRpb25z
KS4NCj4gPj4NCj4gPj4gW01lZF0gQXMgYSByZW1pbmRlciwgdGhlIG1vZHVsZSBjb3ZlcnMgYm90
aCAic2ltcGxlIE5BVCIgKHRoYXQgeW91IGNhbg0KPiA+PiBmaW5kIGluIGEgQ1BFKSBhbmQgbW9y
ZSBhZHZhbmNlZCBvbmVzIGxpa2UgeW91ciBpbXBsZW1lbnRhdGlvbi4gQXMgc3VjaA0KPiA+PiB0
aGUgbW9kdWxlIGFsbG93czoNCj4gPj4gLSBhbiBpbXBsZW1lbnRhdGlvbiB0byBkZXRlcm1pbmUg
aXRzIGludGVybmFsL2V4dGVybmFsIGludGVyZmFjZXMgaW4NCj4gaXRzDQo+ID4+IG93bi4gVGhp
cyBpcyB0eXBpY2FsbHkgdGhlIHJlc2lkZW50aWFsIGdhdGV3YXkgY2FzZS4NCj4gPj4gLSBpbnN0
cnVjdCBhbiBpbXBsZW1lbnRhdGlvbiBhYm91dCB0aGUgZXh0ZXJuYWwgaW50ZXJmYWNlKHMpIHRv
IHdoaWNoDQo+IHRvDQo+ID4+IGJpbmQgdGhlIE5BVCB3aXRoIG9yIHdpdGhvdXQgZmlsdGVyIG9u
IHRoZSBpbnRlcm5hbCBpbnRlcmZhY2UocykuDQo+ID4+DQo+ID4+DQo+ID4+IFtLcmlzXSBPaywg
dGhhbmtzIGZvciBtZW50aW9uaW5nIHRoaXMsIEknbGwgdGFsayBmcm9tIHRoZSBDR04NCj4gcGVy
c3BlY3RpdmUsDQo+ID4+IHNjYWxhYmxlIHZlcnNpb24gb2YgTkFUIGRlcGxveWVkIGluIFNQIG5l
dHdvcmtzIChub3QgdGhlIENFKS4NCj4gPj4gSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGludGVyZmFj
ZSBpcyB0aGUgcmlnaHQgd2F5IHRvIGdvLiBJIHRoaW5rIHRoaXMNCj4gPj4gc2hvdWxkIGJlIGJh
c2VkIG9uIHRoZSByb3V0ZXMuIFNvIHlvdSB0cmFuc2xhdGUgdGhlIHBhY2tldCBhbmQgdGhlbiBs
ZXQNCj4gPj4gdGhlIHJvdXRpbmcgZGVjaWRlcyB3aGVyZSB0byBnby4gRGlmZmVyZW50IHRyYW5z
cG9ydHMgbXkgZW5jYXBzdWxhdGUNCj4gdGhpcw0KPiA+PiBwYWNrZXQgZGlmZmVyZW50bHkgb24g
ZWdyZXNzIChNUExTL0dSRSwgZXRjLikgYW5kIHRoaXMgaXMgaW50ZXJmYWNlDQo+ID4+IGluZGVw
ZW5kZW50Lg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gSWYgbm8gaW5kaWNhdGlv
biBpcyBwcm92aWRlZCwgYWxsIHRoZSB0cmFmZmljIHRoYXQgaXMgc2VuZC9yZWNlaXZlZCBvbg0K
PiBhbg0KPiA+PiBleHRlcm5hbCBpbnRlcmZhY2UgaXMgTkFUZWQuDQo+ID4+IElmIHN1YnNjcmli
ZXItbWF0Y2ggaXMgcHJvdmlkZWQsIHRoZSBOQVQgd2lsbCBiZSBhcHBsaWVkIG9ubHkgaWYgdGhh
dA0KPiA+PiBmaWx0ZXIgbWF0Y2hlcy4NCj4gPj4NCj4gPj4gW0tyaXNdICBJbiB0aGlzIGNhc2Ug
dGhpcyBpcyBiYXNlZCBvbmx5IG9uIGRlc3QgcHJlZml4LiBCdXQgc29tZXRpbWVzDQo+IGl0DQo+
ID4+IHNob3VsZCBiZSBiYXNlZCBvbiBmaWx0ZXJzIHdoaWNoIGFyZSBtb3JlIGZsZXhpYmxlIGlu
IGlkZW50aWZ5aW5nIHdoYXQNCj4gPj4gc2hvdWxkIGJlIHRyYW5zbGF0ZWQgKGZvciBleGFtcGxl
IHRyYW5zbGF0ZSBvbmx5IHRyYWZmaWMgY29taW5nIGZyb20NCj4gdGhlc2UNCj4gPj4gc291cmNl
IElQIGFkZHJlc3Nlcywgb3Igb25seSBnb2luZyB0byB0aG9zZSBkZXN0aW5hdGlvbiBwb3J0cywg
ZWN0KS4NCj4gPj4gU28gSSdtIHRhbGtpbmcgYWJvdXQgcmVhbCBJUCBmaWx0ZXJzIChvciBhY2Nl
c3MtbGlzdHMsIGhvd2V2ZXIgeW91IGNhbGwNCj4gPj4gdGhlbSkgdGhhdCBhcmUgYXBwbGllZCB0
byBpbnRlcmZhY2VzLg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+ID4+IElmIG5hdC1wYXNzLXRocm91Z2ggaXMgcHJvdmlkZWQsIGFsbCB0aGUgdHJh
ZmZpYyB3aWxsIGJlIE5BVGVkIGV4Y2VwdA0KPiB0aGUNCj4gPj4gb25lIHRoYXQgbWF0Y2hlcyB0
aGUgbmF0LXBhc3MtdGhyb3VnaCBmaWx0ZXIocykuDQo+ID4+DQo+ID4+IFRoZSBjdXJyZW50IHZl
cnNpb24gYWxsb3dzIHRvIGRlZmluZSBtdWx0aXBsZSBwb29sczsgZWFjaCBpZGVudGlmaWVkIGJ5
DQo+IGFuDQo+ID4+IGlkLiBUaGlzIGlkIGNhbiBiZSBjYWxsZWQgdHlwaWNhbGx5IGZvciBhZHZh
bmNlZCBmaWx0ZXJpbmcgb3BlcmF0aW9ucy4NCj4gPj4gU3VjaCBmaWx0ZXJzIGFyZSBub3Qgc3Vw
cG9ydGVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24uIEknbSBvcGVuIHRvDQo+IGRpc2N1c3MNCj4g
Pj4gdGhvc2Ugd2l0aCB5b3UuDQo+ID4+DQo+ID4+DQo+ID4+IFtLcmlzXSB5ZXMsIHRoaXMgaXMg
aW1wb3J0YW50LiBXaGF0IGlzIG5lZWRlZCBpcyBhIHNvcnQgb2YNCj4gY2xhc3NpZmljYXRpb24N
Cj4gPj4gYmxvY2ssIHdoZXJlIHlvdSBzYXkgJ3RoaXMgdHJhZmZpYycgaXMgbWFwcGVkIHRvIHRo
aXMgJ3Bvb2wnLg0KPiA+PiBUaGlzIHNob3VsZCBiZSBkb25lIHZpYSBpcC1maWx0ZXJzIHRoYXQg
YXJlIGFwcGxpZWQgdG8gaW50ZXJmYWNlcywgYW5kDQo+ID4+IHRodXMgYWxsIHRvZ2V0aGVyIG91
dHNpZGUgb2YgTkFUIGluc3RhbmNlLCBvciBvbiBhIGNvYXJzZXIgbGV2ZWwgdmlhDQo+ID4+IHN1
YnNjcmliZXItbWF0Y2ggdGhhdCBpcyBhIGxpc3Qgd2l0aCBhICBsZWFmIHRoYXQgYWNjZXB0cyBu
b3Qgb25seSBpcC0NCj4gPj4gcHJlZml4IGJ1dCBhIHBvb2wgaWQgKGxlYWZyZWYpIGFzIHdlbGwu
DQo+ID4+DQo+ID4+IFRhbGtpbmcgYWJvdXQgbXVsdGlwbGUgcG9vbHMsIGl0IGlzIHBvc3NpYmxl
IHRoYXQgcG9vbHMgaGF2ZSBkaWZmZXJlbnQNCj4gPj4gc2V0dGluZ3MgKG1heCBudW1iZXIgb2Yg
c3VicyBwZXIgb3V0c2lkZSBJUCBhZGRyZXNzLCBldGMpLiBTbyBwb29sDQo+IGNvbmZpZw0KPiA+
PiBzaG91bGQgaGF2ZSBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgKHBvb2wgc2hvdWxkIGJlIGEgbGlz
dCB3aXRoIG11bHRpcGxlDQo+ID4+IGxlYWZzKS4gU28gd2UgYWxsb3cgdGhpcyB0b2RheSwgYSB2
ZXJ5IGZsZXhpYmxlIGNvbmZpZyB0aGF0IG1heSBub3cgZ2V0DQo+ID4+IHJlc3RyaWN0ZWQgYmVj
YXVzZSBvZiBjb25maWd1cmF0aW9uIGNvbnN0cmFpbnRzLg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0t
LS0tLS0tDQo+ID4+IFRoZSByZWFzb24gd2h5IHN1Y2ggYWR2YW5jZWQgZmlsdGVycyBhcmUgbm90
IGluY2x1ZGVkIGlzIHRoYXQgdGhlIHNhbWUNCj4gPj4gb2JqZWN0aXZlIGNhbiBiZSBhY2hpZXZl
ZCBieSBkZWZpbmluZyBtdWx0aXBsZSBOQVQgaW5zdGFuY2VzOyBlYWNoIHdpdGgNCj4gPj4gZGVk
aWNhdGVkIHBvb2xzIGFuZCBwb3J0IGFzc2lnbm1lbnQgcG9saWNpZXMgLg0KPiA+Pg0KPiA+Pg0K
PiA+PiBbS3Jpc10gVHJ1ZSwgYnV0IEkgd2FzIGhvcGluZyB0aGF0IGEgbW9yZSBlbGVnYW50IHNv
bHV0aW9uIGNhbiBiZQ0KPiBmb3VuZC4NCj4gPj4gT3RoZXJ3aXNlIGEgbmV3IE5BVCBpbnN0YW5j
ZSB3b3VsZCBiZSByZXF1aXJlZCBwZXIgcG9vbC4gTkFUIGluc3RhbmNlDQo+IGV2ZW4NCj4gPj4g
aW4geW91ciBwcm9wb3NhbCBzdXBwb3J0cyBtdWx0aXBsZSBwb29scywgaXQgd291bGQgYmUgbmlj
ZSB0byBmaW5kIGENCj4gd2F5DQo+ID4+IHRvIHNlbGVjdGl2ZWx5IG1hcCB0cmFmZmljIHRvIHRo
b3NlIHBvb2xzIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIE5BVA0KPiA+PiBpbnN0YW5jZS4NCj4g
Pj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBhIHNpbWlsYXIgZmVhdHVyZSBpcyBzdXBwb3J0ZWQg
Zm9yIE5BVDY0OiB0aGUgTkFUNjQNCj4gPj4gcHJlZml4IGNhbiBiZSBzZWxlY3RlZCBhcyBhIGZ1
bmN0aW9uIG9mIHRoZSBkZXN0aW5hdGlvbiBwcmVmaXguDQo+ID4+DQo+ID4+ICAgICAgICAgICAg
ICArLS1ydyBuYXQ2NC1wcmVmaXhlcyogW25hdDY0LXByZWZpeF0NCj4gPj4gICAgICAgICAgICAg
IHwgICstLXJ3IG5hdDY0LXByZWZpeCAgICAgICAgICAgICAgIGluZXQ6aXB2Ni1wcmVmaXgNCj4g
Pj4gICAgICAgICAgICAgIHwgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjQtcHJlZml4KiBbaXB2NC1w
cmVmaXhdDQo+ID4+ICAgICAgICAgICAgICB8ICAgICArLS1ydyBpcHY0LXByZWZpeCAgICBpbmV0
OmlwdjQtcHJlZml4DQo+ID4+DQo+ID4+IE9uZSBtaW5vciBjb21tZW50OiBmcm9tIGFuIElFVEYg
c3RhbmRwb2ludCwgInJvdXRpbmcgY29udGV4dCIgbWF5IGJlDQo+ID4+IGNvbmZ1c2luZyBmb3Ig
cGVvcGxlIGFzIE5BVCBpcyBub3QgYSByb3V0aW5nIGZ1bmN0aW9uLg0KPiA+Pg0KPiA+Pj4NCj4g
Pj4+IFdlIGhhdmUgYSBkaWZmZXJlbnQgYXBwcm9hY2gsIHdpdGggdGhyZWUgbWFpbiBidWlsZGlu
ZyBibG9ja3M6DQo+ID4+Pg0KPiA+Pj4gMSkgIGluIGluc2lkZSAocHJpdmF0ZSkgcm91dGluZyBj
b250ZXh0IHdlIGRlZmluZSBwYXJhbWV0ZXJzIHRoYXQgYXJlDQo+ID4+PiByZWxhdGVkIHRvIGlu
c2lkZS4gRm9yIGV4YW1wbGUgZGVzdGluYXRpb24tcHJlZml4ICh3aGF0IHdpbGwgZ2V0IHNlbnQN
Cj4gPj4+IHRvIE5BVCBmb3IgdHJhbnNsYXRpb24pIGluIE5BVDQ0LCB0aGVuIE5BVDY0IHByZWZp
eCwgZGV0ZXJtaW5pc3RpYyBuYXQNCj4gPj4+IHBhcmFtZXRlcnMsIERTLWxpdGUgQUZUUiBhZGRy
ZXNzIChJIGtub3cgdGhhdCBkcy1saXRlIGlzIGNvdmVyZWQgaW4NCj4gPj4+IGRpZmZlcmVudCBk
cmFmdCksIHNvbWUgb3RoZXIgTDItQXdhcmUgTkFUIHBhcmFtZXRlcnMsIGV0Yy4NCj4gPj4NCj4g
Pj4gW01lZF0gUHV0dGluZyBhc2lkZSB0aGF0IHdlIG1hcmsgZXhwbGljaXRseSB0aG9zZSBwYXJh
bWV0ZXJzIGFzDQo+ICJpbnNpZGUiLA0KPiA+PiBtb3N0IG9mIHRob3NlIHBhcmFtZXRlcnMgYXJl
IHN1cHBvcnRlZCBpbiB0aGlzIHZlcnNpb24gKGFuZCB0aGUgRFMtTGl0ZQ0KPiA+PiBZQU5HKS4N
Cj4gPj4NCj4gPj4+IDIpIHRoZW4gd2UgZ28gdG8gb3V0c2lkZSByb3V0aW5nIGNvbnRleHRTLiBU
aGVyZSB3ZSBkZWZpbmUgcG9vbCBhbmQNCj4gPj4+IHBvb2wgcmVsYXRlZCBwYXJhbWV0ZXJzOiBv
dXRzaWRlLWFkZHJlc3MgcmFuZ2UsIHBvb2wgd2F0ZXJtYXJrcywgc2l6ZQ0KPiA+Pj4gb2YgdGhl
IHBvcnQtYmxvY2tzIGluIHRoZSBwb29sLCBwb3J0LWZvcndhcmRpbmcgcmFuZ2VzIGluIHRoZSBw
b29sLA0KPiA+Pj4gbnVtYmVyIG9mIHN1YnNjcmliZXJzIHBlciBvdXRzaWRlIElQLCBldGMuDQo+
ID4+DQo+ID4+IFtNZWRdIEdyZWF0LiBQdXR0aW5nIGFzaWRlIHRoYXQgd2UgbWFyayBleHBsaWNp
dGx5IHRob3NlIHBhcmFtZXRlcnMgYXMNCj4gPj4gIm91dHNpZGUiLCB0aG9zZSBwYXJhbWV0ZXJz
IGFyZSBzdXBwb3J0ZWQgaW4gdGhpcyB2ZXJzaW9uLg0KPiA+Pg0KPiA+Pj4gMykgdGhlbiB3ZSBo
YXZlIGEgbmF0LXBvbGljeSB0aGF0IHNlcnZlcyBhcyBhIGdsdWUgdGhhdCBjb25uZWN0cyB0aGUN
Cj4gPj4+IGluc2lkZSByb3V0aW5nIGNvbnRleHQgYW5kIHRoZSBvdXRzaWRlIHJvdXRpbmcgY29u
dGV4dHMgKGNhbiBiZSBtb3JlDQo+ID4+PiBvZg0KPiA+Pj4gdGhlbSkgYW5kIHRoZSBwb29scy4N
Cj4gPj4+IEluIG5hdC1wb2xpY3kgIGRlZmluaXRpb24gd2UgcmVmZXJlbmNlIGEgcG9vbCwgZW5h
YmxlIEFMR3MsIHNldCB0aGUNCj4gPj4+IHNlc3Npb24gbGltaXQgcGVyIHN1YnNjcmliZXIsIG51
bWJlciBvZiBwb3J0LWJsb2NrcyBwZXIgc3Vic2NyaWJlciwNCj4gPj4+IGZpbHRlcmluZyBtb2Rl
LCBwcmlvcml0eSBzZXNzaW9ucyAoYmFzZWQgb24gZm9yd2FyZGluZy1jbGFzcyksIHRpbW91dHMN
Cj4gPj4+ICh0cGMsIHVkcCwgaWNtcCksIGV0Yy4NCj4gPj4+IFRoaXMgcG9saWN5IGlzIHRoZW4g
cmVmZXJlbmNlZCBpbiB0aGUgaW5zaWRlIHJvdXRpbmcgY29udGV4dC4gQXQgdGhhdA0KPiA+Pj4g
cG9pbnQgd2hlbiB0aGUgcGFja2V0IGlzIHJlY2VpdmVkIGluIHRoZSBpbnNpZGUsIGl0IGtub3dz
IHdoaWNoIHBvb2wNCj4gPj4+IChhbmQgb3V0c2lkZSByb3V0aW5nIGNvbnRleHQpIGl0IG5lZWRz
IHRvIGdvIHRvIC0gYmFzZWQgb24gdGhlDQo+ID4+PiBjbGFzc2lmaWNhdGlvbiBpbiB0aGUgaXAt
ZmlsdGVyIHdpdGggYWN0aW9uIE5BVCAoYXBwbGllZCB0byBhbg0KPiA+Pj4gaW50ZXJmYWNlKSBv
ciBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24tcHJlZml4IChhcyBjb25maWd1cmVkIGluIHRoZQ0K
PiA+PiBpbnNpZGUgcm91dGluZyBjb250ZXh0KS4NCj4gPj4+DQo+ID4+PiBUaGUga2V5IGlzIHRo
YXQgd2UgYWxsb3cgZm9ya2luZyB0byBtdWx0aXBsZSBwb29scyBmcm9tIHRoZSBzYW1lDQo+ID4+
PiBpbnNpZGUgcm91dGluZyBjb250ZXh0LiBGb3IgZXhhbXBsZToNCj4gPj4+IERlc3RpbmF0aW9u
LXByZWZpeCAgIDEwLjEwLjEwLjAvMjQgbmF0LXBvbGljeSAibmF0LXBvbC1uYW1lLTEiICAgID09
Pg0KPiA+PiBuYXQtDQo+ID4+PiBwb2wtbmFtZS0xIHJlZmVyZW5jZXMgYSBwb29sIGFuZCB0aGUg
b3V0c2lkZSByb3V0aW5nIGNvbnRleHQNCj4gPj4+IERlc3RpbmF0aW9uLXByZWZpeCAxMC4yMC4y
MC4wLzI0IG5hdCBwb2xpY3kgIm5hdC1wb2wtbmFtZS0yIiAgPT0+DQo+ID4+PiBuYXQtcG9sLQ0K
PiA+Pj4gbmFtZS0yIHJlZmVyZW5jZSBhIGRpZmZlcmVudCBwb29sIGluIHRoZSBzYW1lIG91dHNp
ZGUgcm91dGluZyBjb250ZXh0DQo+ID4+PiBhcyBhYm92ZSBvciBhIGRpZmZlcmVudCBvbmUNCj4g
Pj4+DQo+ID4+PiAoc2FtZSBjYW4gYmUgYWNoaWV2ZWQgd2l0aCBmaWx0ZXJzIHRoYXQgYXJlIGFw
cGxpZWQgdG8gaW50ZXJmYWNlcyAtDQo+ID4+PiB3aXRoIGZpbHRlcnMgd2UgaGF2ZSBhIG11Y2gg
d2lkZXIgcmFuZ2Ugb2YgY2xhc3NpZmljYXRpb24gb3B0aW9ucyAtDQo+ID4+PiB3aGF0IGdldHMg
ZGl2ZXJ0ZWQgdG8gTkFUKS4NCj4gPj4NCj4gPj4gW01lZF0gQWdyZWUuIFRob3NlIGFyZSBvdXQg
b2YgdGhlIHNjb3BlLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRoZW4gb24gYSBzaWRlLCB3ZSBoYXZl
IG5hdC1jbGFzc2lmaWVycyB0aGF0IGRlYWwgd2l0aCBkZXN0aW5hdGlvbi0NCj4gbmF0Lg0KPiA+
Pj4gVGhlcmUgd2UgaWRlbnRpZnkgdHJhZmZpYyB0aGF0IG5lZWRzIHRvIGJlIGROVEFlZCBhbmQg
d2Ugc3BlY2lmeSB0aGUNCj4gPj4+IGRlc3QtIGlwIGFkZHJlc3MgaW4gdGhlIHNhbWUgY2xhc3Np
Zmllci4gVGhpcyBjbGFzc2lmaWVyIGlzIHRoZW4NCj4gPj4+IGFwcGxpZWQgaW4gbmF0LSBwb2xp
Y3kgYXMgd2VsbC4NCj4gPj4+DQo+ID4+PiBUaGVyZSBhcmUgYSBmZXcgb3RoZXIgcGllY2VzIHRo
YXQgZGVhbCB3aXRoIGxvZ2dpbmcsIHBjcCBldGMgZnVuY3Rpb25zDQo+ID4+PiB0aGF0IGFyZSBz
Y2F0dGVyZWQgYXJvdW5kLCBidXQgdGhpcyBjYW4gYmUgY29uc29saWRhdGVkLiBCdXQgSSdtDQo+
ID4+PiBhZnJhaWQgdGhhdCB0aGlzIDMgcHJvbmcgc3RydWN0dXJlIChpbnNpZGUsIG91dHNpZGUs
IG5hdC1wb2xpY3kpIHdvdWxkDQo+ID4+PiBiZSBoYXJkZXIgdG8gY29uc29saWRhdGUuDQo+ID4+
Pg0KPiA+Pj4NCj4gPj4+IEZyb20geW91ciBwcm9wb3NhbCBpbiB0aGUgZHJhZnQsIEknbSBub3Qg
Y2xlYXIgaG93IGRvIHlvdSBlbnN1cmUNCj4gPj4+IHNlcGFyYXRpb24gb2Ygcm91dGluZyBjb250
ZXh0IGFuZCBzZWxlY3Rpb24gb2YgZGlmZmVyZW50IHBvb2xzLg0KPiA+Pg0KPiA+PiBbTWVkXSBB
cyBtZW50aW9uZWQgYWJvdmUsIHRoZSBjdXJyZW50IG1vZGVsIGRvZXMgc3VwcG9ydCB0aGlzIGJ5
DQo+IGRlZmluaW5nDQo+ID4+IG11bHRpcGxlIE5BVCBpbnN0YW5jZXMuDQo+ID4+DQo+ID4+ICBJ
IHNlZSB0aGF0DQo+ID4+PiBpbnNpZGUgaW50ZXJmYWNlcyBhbmQgb3V0c2lkZSBpbnRlcmZhY2Vz
IGFyZSByZWZlcmVuY2VkIGluIHRoZSBuYXQtDQo+ID4+PiBpbnN0YW5jZSwgYnV0IHRoZXJlIGlz
IG5vIG1lbnRpb24gb2Ygcm91dGluZyBjb250ZXh0IChhbHRob3VnaCB0aGlzDQo+ID4+PiBjYW4g
YmUgZGVyaXZlZCBmcm9tIHRoZSBpbnRlcmZhY2UgbmFtZSwgYXNzdW1pbmcgdGhhdCBpbnRmIG5h
bWUgYXJlDQo+ID4+PiB1bmlxdWUgY2hhc3NpcyB3aWRlKS4gTW9yZW92ZXIgSSBjYW4ndCBzZWUg
aG93IGRvIHlvdSBlbnN1cmUgc2VsZWN0aW9uDQo+ID4+PiBvZiBhIHBvb2wgYmFzZWQgb24gc29t
ZSBjbGFzc2lmaWNhdGlvbiBvbiBpbmdyZXNzIChzYXkNCj4gPj4+IGRlc3RpbmF0aW9uLXByZWZp
eCBBIGdvIHRvIHBvb2wgMSwgZGVzdGluYXRpb24tcHJlZml4IEIgdG8gcG9vbCAyKS4NCj4gPj4N
Cj4gPj4gW01lZF0gVGhpcyBpcyBub3Qgc3VwcG9ydGVkIHdpdGhpbiB0aGUgc2FtZSBOQVQgaW5z
dGFuY2UuIEknbSBvcGVuIHRvDQo+ID4+IGRpc2N1c3MgaWYvaG93IHRvIHVwZGF0ZSB0aGUgbW9k
dWxlIHRvIGluY2x1ZGUgdGhpcyBmZWF0dXJlLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBX
ZSBkZWZpbml0ZWx5IHdhbnQgdG8gYmUgcGFydCBvZiB0aGlzIGRpc2N1c3Npb24NCj4gPj4NCj4g
Pj4gW01lZF0gR3JlYXQhDQo+ID4+DQo+ID4+ICwgYnV0IGF0IHRoaXMgcG9pbnQgSSdtDQo+ID4+
PiBub3Qgc3VyZSBob3cgdG8gcHJvY2VlZC4gSXQgd291bGQgYmUgZ3JlYXQgaWYgeW91IGNhbiBh
ZHZpc2UuIFRoYW5rcy4NCj4gPj4NCj4gPj4gW01lZF0gSSBzZWUgdGhlIGZvbGxvd2luZyBvcHRp
b25zOg0KPiA+PiAoMSkgQ29udGludWUgdGhlIGRpc2N1c3Npb24gaW4gcHJpdmF0ZSB0byBmaWd1
cmUgb3V0IHdoYXQgbW9kaWZpY2F0aW9ucw0KPiA+PiBjYW4gYmUgaW1wbGVtZW50ZWQgdG8gYWRk
cmVzcyB5b3VyIGNvbW1lbnRzLg0KPiA+PiAoMikgRm9yd2FyZCB0aGlzIG1haWwgdG8gdGhlIE9Q
U0FXRyBtYWlsaW5nIGxpc3QgYW5kIHRha2UgaXQgZm9yIHRoZXJlLg0KPiA+Pg0KPiA+PiBQcm9j
ZWVkaW5nIHdpdGggYm90aCBpcyBhbHNvIGFuIG9wdGlvbi4gRm9yIGV4YW1wbGUsIEkgY2FuIHN0
YXJ0IGJ5DQo+ID4+IHNoYXJpbmcgeW91ciBjb25jZXJuIHdpdGggdGhlIFdHIGFuZCB0aGVuIGRp
c2N1c3MgaW4gcHJpdmF0ZSBob3cgdG8NCj4gPj4gYWRkcmVzcyBpdC4NCj4gPj4NCj4gPj4gUGxl
YXNlIGxldCBtZSBrbm93IHlvdXIgcHJlZmVyZW5jZS4NCj4gPj4NCj4gPj4+IEtyaXMNCj4gPj4+
DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogSGVuZGVyaWNreCwgV2ltIChOb2tpYSAt
IEJFL0FudHdlcnApDQo+ID4+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3IDExOjMx
IFBNDQo+ID4+PiBUbzogUG9zY2ljLCBLcmlzdGlhbiAoTm9raWEgLSBVUykgPGtyaXN0aWFuLnBv
c2NpY0Bub2tpYS5jb20+DQo+ID4+PiBTdWJqZWN0OiBGVzogUmVxdWVzdCB0byByZXZpZXcgZHJh
ZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDENCj4gPj4+DQo+ID4+PiBDYW4geW91IGNvbW1lbnRz
IG9uIHRoaXM/DQo+ID4+Pg0KPiA+Pj4gT24gMjIvMDgvMjAxNywgMTQ6MjMsICJtb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tIg0KPiA+Pj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+
IHdyb3RlOg0KPiA+Pj4NCj4gPj4+ICAgICBIaSBXaW0sDQo+ID4+Pg0KPiA+Pj4gICAgIEkgaG9w
ZSB5b3UgYXJlIGRvaW5nIHdlbGwhDQo+ID4+Pg0KPiA+Pj4gICAgIENhbiB5b3UgcGxlYXNlIHJl
dmlldyB0aGlzIG1vZGVsPyBJJ20gcGFydGljdWxhcmx5IGludGVyZXN0ZWQgdG8NCj4gPj4+IHNl
ZSBpZiB0aGUgbW9kZWwgaXMgYWxpZ25lZCB3aXRoIHlvdXIgNzc1MCBOQVQ0NC9OQVQ2NCBpbXBs
ZW1lbnRhdGlvbi4NCj4gPj4+DQo+ID4+PiAgICAgVGhhbmsgeW91Lg0KPiA+Pj4NCj4gPj4+ICAg
ICBDaGVlcnMsDQo+ID4+PiAgICAgTWVkDQo+ID4+Pg0KPiA+Pj4gICAgID4gLS0tLS1NZXNzYWdl
IGQnb3JpZ2luZS0tLS0tDQo+ID4+PiAgICAgPiBEZSA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPj4+ICAgICA+IEVudm95w6kg
OiBsdW5kaSAyMSBhb8O7dCAyMDE3IDExOjEwDQo+ID4+PiAgICAgPiDDgCA6IEJPVUNBREFJUiBN
b2hhbWVkIElNVC9PTE47IFNlbnRoaWwgU2l2YWt1bWFyOyBKQUNRVUVORVQNCj4gPj4+IENocmlz
dGlhbg0KPiA+Pj4gICAgID4gSU1UL09MTjsgb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzsgUWluIFd1
DQo+ID4+PiAgICAgPiBPYmpldCA6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt
aWV0Zi1vcHNhd2ctbmF0LXlhbmctDQo+ID4+PiAwMS50eHQNCj4gPj4+ICAgICA+DQo+ID4+PiAg
ICAgPg0KPiA+Pj4gICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtb3BzYXdn
LW5hdC15YW5nLTAxLnR4dA0KPiA+Pj4gICAgID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p
dHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkDQo+ID4+PiB0byB0aGUNCj4gPj4+
ICAgICA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPj4+ICAgICA+DQo+ID4+PiAgICAgPiBOYW1lOgkJ
ZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcNCj4gPj4+ICAgICA+IFJldmlzaW9uOgkwMQ0KPiA+
Pj4gICAgID4gVGl0bGU6CQlBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBBZGRyZXNzIFRy
YW5zbGF0aW9uDQo+ID4+PiAoTkFUKQ0KPiA+Pj4gICAgID4gYW5kIE5ldHdvcmsgUHJlZml4IFRy
YW5zbGF0aW9uIChOUFQpDQo+ID4+PiAgICAgPiBEb2N1bWVudCBkYXRlOgkyMDE3LTA4LTIxDQo+
ID4+PiAgICAgPiBHcm91cDoJCW9wc2F3Zw0KPiA+Pj4gICAgID4gUGFnZXM6CQk3Mw0KPiA+Pj4g
ICAgID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLQ0KPiA+Pj4gb3BzYXdnLQ0KPiA+Pj4gICAgID4gbmF0LXlhbmctMDEudHh0
DQo+ID4+PiAgICAgPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtaWV0Zi0NCj4gPj4gb3BzYXdnLQ0KPiA+Pj4gbmF0LQ0KPiA+Pj4gICAgID4g
eWFuZy8NCj4gPj4+ICAgICA+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC0NCj4gPj4+IHlhbmctMDENCj4gPj4+ICAg
ICA+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s
L2RyYWZ0LQ0KPiBpZXRmLQ0KPiA+Pj4gb3BzYXdnLQ0KPiA+Pj4gICAgID4gbmF0LXlhbmctMDEN
Cj4gPj4+ICAgICA+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm
P3VybDI9ZHJhZnQtaWV0Zi0NCj4gPj4gb3BzYXdnLQ0KPiA+Pj4gbmF0LQ0KPiA+Pj4gICAgID4g
eWFuZy0wMQ0KPiA+Pj4gICAgID4NCj4gPj4+ICAgICA+IEFic3RyYWN0Og0KPiA+Pj4gICAgID4g
ICAgRm9yIHRoZSBzYWtlIG9mIG5ldHdvcmsgYXV0b21hdGlvbiBhbmQgdGhlIG5lZWQgZm9yDQo+
IHByb2dyYW1taW5nDQo+ID4+PiAgICAgPiAgICBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24g
KE5BVCkgZnVuY3Rpb24gaW4gcGFydGljdWxhciwgYQ0KPiA+PiBkYXRhDQo+ID4+PiAgICAgPiAg
ICBtb2RlbCBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIHRoZSBOQVQgaXMgZXNzZW50aWFs
Lg0KPiBUaGlzDQo+ID4+PiAgICAgPiAgICBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1v
ZGVsIGZvciB0aGUgTkFUIGZ1bmN0aW9uLg0KPiA+Pj4gICAgID4NCj4gPj4+ICAgICA+ICAgIE5B
VDQ0LCBOZXR3b3JrIEFkZHJlc3MgYW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2Ng0K
PiA+PiBDbGllbnRzDQo+ID4+PiB0bw0KPiA+Pj4gICAgID4gICAgSVB2NCBTZXJ2ZXJzIChOQVQ2
NCksIEN1c3RvbWVyLXNpZGUgdHJhbnNMQVRvciAoQ0xBVCksDQo+IEV4cGxpY2l0DQo+ID4+PiAg
ICAgPiAgICBBZGRyZXNzIE1hcHBpbmdzIGZvciBTdGF0ZWxlc3MgSVAvSUNNUCBUcmFuc2xhdGlv
biAoU0lJVA0KPiBFSU0pLA0KPiA+Pj4gYW5kDQo+ID4+PiAgICAgPiAgICBJUHY2IE5ldHdvcmsg
UHJlZml4IFRyYW5zbGF0aW9uIChOUFR2NikgYXJlIGNvdmVyZWQgaW4gdGhpcw0KPiA+Pj4gZG9j
dW1lbnQuDQo+ID4+PiAgICAgPg0KPiA+Pj4gICAgID4NCj4gPj4+ICAgICA+DQo+ID4+PiAgICAg
Pg0KPiA+Pj4gICAgID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUNCj4gb2YNCj4gPj4+ICAgICA+IHN1Ym1pc3Npb24NCj4gPj4+
ICAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg
YXQNCj4gPj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4+PiAgICAgPg0KPiA+Pj4gICAgID4gVGhlIElF
VEYgU2VjcmV0YXJpYXQNCj4gPj4+DQo+ID4+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPUFNBV0cgbWFpbGluZyBsaXN0DQo+
ID4gT1BTQVdHQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vcHNhd2cNCj4gPg0KDQo=


From nobody Wed Sep 27 09:40: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 197FB132F30; Wed, 27 Sep 2017 09:40:00 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YD0RBgHhmFJF; Wed, 27 Sep 2017 09:39:57 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61251342C0; Wed, 27 Sep 2017 09:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18829; q=dns/txt; s=iport; t=1506530397; x=1507739997; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=eynR1dSIqyoc5yO1G5115TCkbIBJloHK+FG3eANtUoE=; b=EqI9yL5XWJE0VUMCt9cCUPRAuHooR1BMV39upQsCsex7X3WEDONYnWAA ZYC9tJwxCbNXmTJ0HHo3m9nUwEu9QDDoG3C0XC2rvlEznS99rMa3YyOUW wC5gXOdVAJlDAQ0OyP82chkAtcpjZromjqXHpAh6Fu2ftdb/77PNoA19L k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAQCc08tZ/40NJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNcZG4ng3iZfYF2eYxXim0KGAuESU8ChFxXAQIBAQEBAQJrKIU?= =?us-ascii?q?YAQEBAQIBAQEhDwE7CwUHBAsRBAEBAQICIwMCAicfCQgGAQwGAgEBF4oOCBCoU?= =?us-ascii?q?4IniwUBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ6CHYICgVGBaiuCSDWBJIIOgSc?= =?us-ascii?q?FBgEBgzGCYAEEihKHKYcUiFSHXoNciSWCE1uFE4NahytwiR2LPIE5V4EOUyUVH?= =?us-ascii?q?yqFGhyBZh0kNodtDhiCHAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800";  d="scan'208";a="9471140"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2017 16:39:55 +0000
Received: from [10.150.54.223] (dhcp-10-150-54-223.cisco.com [10.150.54.223]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8RGdtiX017997; Wed, 27 Sep 2017 16:39:55 GMT
To: mohamed.boucadair@orange.com, "opsawg@ietf.org" 
Cc: "Poscic, Kristian (Nokia - US) (kristian.poscic@nokia.com)" , "draft-ietf-opsawg-nat-yang@ietf.org" 
References: <787AE7BB302AE849A7480A190F8B93300A02DF87@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05F3CAD8-36D4-48B0-8989-82F1B965D0A2@nokia.com>  <787AE7BB302AE849A7480A190F8B93300A04606F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A04961A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A04ADED@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Clarke 
Organization: Cisco
Message-ID: <9a7d3a20-bc52-6e1c-be9c-73d74406133a@cisco.com>
Date: Wed, 27 Sep 2017 12:39:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A04ADED@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01
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, 27 Sep 2017 16:40:00 -0000

On 9/27/17 09:20, mohamed.boucadair@orange.com wrote:
> 
>   Adding policy and
>> other non-NAT items would conflate the scope.
> 
> [Med] Allowing for multiple NAT configurations within the same instance is easy to add. 
> What I'm hesitating to add is advanced classification filtering that is not specific to the NAT function. An approach I'm investigating is:
> - Add an informative section to record the comment from Kris (i.e., bind a packet/flow to a NAT configuration) and declare it out of scope.
> - Suggest that extensions to ietf-netmod-acl-model module can be defined by implementers, if needed. 
> 
>>
>> Speaking as an individual -- and maybe this is what you mean by the
>> multiple instances -- wouldn't the ability to have routing contexts act
>> as inside and outside of each other be covered in your draft today?
> 
> [Med] The current version is silent about inside/outside routing contexts per se. The current approach assumes that: 
> * Some NATs are embedded in systems that are able to determine how/when to invoke the NAT service. This is typically the case of NATs embedded in CPEs. For example, a residential gateway determines in its own LAN interfaces and WAN interfaces.
> * Some NATs need to be bound to an external interface explicitly. An interface can be of any nature (physical, virtual, tunnel, etc.). Remaining interfaces are assumed to be internal ones. 


> 
> Kris is asking to have the ability to associate the NAT service with VRF contexts, too. 

Ah, I did misunderstand a bit.  I assumed the VRFs were bound to
interfaces and then NAT would be bound to those interfaces.

> 
> I think that we can accommodate that comment by making the following change to the draft (see the proposed change below). In order to avoid conflating the scope, I don't want to list here every routing context type, but to limit the scope to these two choices. 
> 
> OLD: 
> 
>              +--rw internal-interfaces* [internal-interface]
>              |  +--rw internal-interface    if:interface-ref
>              +--rw external-interfaces* [external-interface]
>              |  +--rw external-interface    if:interface-ref
> 
> NEW: 
> 
>              +--rw internal-realm
>              |  +--rw (realm-type)?
>              |     +--:(interface)
>              |     |  +--rw internal-interfaces* [internal-interface]
>              |     |     +--rw internal-interface    if:interface-ref
>              |     +--:(vrf)
>              |        +--rw internal-vrf-instances* [internal-vrf-instance]
>              |           +--rw internal-vrf-instance    identityref
>              +--rw external-realm
>              |  +--rw (realm-type)?
>              |     +--:(interface)
>              |     |  +--rw external-interfaces* [external-interface]
>              |     |     +--rw external-interface    if:interface-ref
>              |     +--:(vrf)
>              |        +--rw external-vrf-instances* [external-vrf-instance]
>              |           +--rw external-vrf-instance    identityref

This makes sense to me.

Joe

> 
>>
>> Joe
>>
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.poscic@nokia.com]
>>>> Envoyé : mardi 26 septembre 2017 00:31
>>>> À : BOUCADAIR Mohamed IMT/OLN
>>>> Cc : draft-ietf-opsawg-nat-yang@ietf.org
>>>> Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01
>>>>
>>>> Hi Med,
>>>> Sorry for the late reply, this time from my side.
>>>> We can continue in whichever way is the most efficient in your opinion.
>>>> I'm OK either way.
>>>>
>>>> I replied to your comments inline.
>>>> But my preference would be that this (NAT YANG model) is a more
>> modular,
>>>> i.e. have building blocks.
>>>> Current model is a bit too monolithic and maybe even CE centric.
>>>>
>>>> We (Nokia) will be able to consolidate some configuration data and
>> maybe
>>>> even make it within a single configuration instance.
>>>> For example, for inside make it a 'choice' between interface and entire
>>>> 'vrf' (not sure how you want to call this if not routing context); same
>>>> for outside.
>>>> This way we can say the whole VRF is the inside and another (or the
>> same)
>>>> whole VRF is outside, which means that routing is used to determine
>> where
>>>> the translated packet needs to go out (this is how we do it, there no
>>>> interfaces in our NAT for the reason I specified below - transport
>>>> independent).
>>>>
>>>> But in general, my idea would be:
>>>>
>>>> - your NAT instance kinds of defines what gets mapped where
>>>>
>>>> But then outside of the nat-instance you have a bunch of other
>>>> configuration that can be referenced from inside this nat-instance
>>>> (classifiers and different policies).
>>>> For example, when certain traffic is mapped to a pool, then this
>> traffic
>>>> may have different NAT parameters (ALGs, TCP/UDP timers, etc) than some
>>>> other traffic that is mapped to a different pool within the same NAT
>>>> instance. This kind of flexibility should exist. Thanks.
>>>> Kris
>>>>
>>>> -----Original Message-----
>>>> From: mohamed.boucadair@orange.com
>> [mailto:mohamed.boucadair@orange.com]
>>>> Sent: Wednesday, September 20, 2017 3:51 AM
>>>> To: Poscic, Kristian (Nokia - US) 
>>>> Cc: draft-ietf-opsawg-nat-yang@ietf.org
>>>> Subject: RE: Request to review draft-ietf-opsawg-nat-yang-01
>>>>
>>>> Hi Kris,
>>>>
>>>> (ccing my co-authors)
>>>>
>>>> Apologies for the delay to answer. I was out of office.
>>>>
>>>> Thank you very much for sharing the comments. Much appreciated!
>>>>
>>>> Please see inline.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.poscic@nokia.com]
>>>>> Envoyé : mercredi 13 septembre 2017 23:01 À : BOUCADAIR Mohamed
>>>>> IMT/OLN Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01
>>>>>
>>>>> Hi Med,
>>>>>
>>>>> Wim asked me to review this draft and I here I provide my feedback.
>>>>
>>>> [Med] Thank you.
>>>>
>>>>> Unfortunately it does not line-up with our implementation. It seems
>>>>> that this model configures everything under the same nat instance
>>>>> (private side, public side and all the other config options).
>>>>
>>>> [Med] As a reminder, the module covers both "simple NAT" (that you can
>>>> find in a CPE) and more advanced ones like your implementation. As such
>>>> the module allows:
>>>> - an implementation to determine its internal/external interfaces in
>> its
>>>> own. This is typically the residential gateway case.
>>>> - instruct an implementation about the external interface(s) to which
>> to
>>>> bind the NAT with or without filter on the internal interface(s).
>>>>
>>>>
>>>> [Kris] Ok, thanks for mentioning this, I'll talk from the CGN
>> perspective,
>>>> scalable version of NAT deployed in SP networks (not the CE).
>>>> I'm not sure that the interface is the right way to go. I think this
>>>> should be based on the routes. So you translate the packet and then let
>>>> the routing decides where to go. Different transports my encapsulate
>> this
>>>> packet differently on egress (MPLS/GRE, etc.) and this is interface
>>>> independent.
>>>> ---------------------
>>>> If no indication is provided, all the traffic that is send/received on
>> an
>>>> external interface is NATed.
>>>> If subscriber-match is provided, the NAT will be applied only if that
>>>> filter matches.
>>>>
>>>> [Kris]  In this case this is based only on dest prefix. But sometimes
>> it
>>>> should be based on filters which are more flexible in identifying what
>>>> should be translated (for example translate only traffic coming from
>> these
>>>> source IP addresses, or only going to those destination ports, ect).
>>>> So I'm talking about real IP filters (or access-lists, however you call
>>>> them) that are applied to interfaces.
>>>> -------------------------------------------
>>>> If nat-pass-through is provided, all the traffic will be NATed except
>> the
>>>> one that matches the nat-pass-through filter(s).
>>>>
>>>> The current version allows to define multiple pools; each identified by
>> an
>>>> id. This id can be called typically for advanced filtering operations.
>>>> Such filters are not supported in the current version. I'm open to
>> discuss
>>>> those with you.
>>>>
>>>>
>>>> [Kris] yes, this is important. What is needed is a sort of
>> classification
>>>> block, where you say 'this traffic' is mapped to this 'pool'.
>>>> This should be done via ip-filters that are applied to interfaces, and
>>>> thus all together outside of NAT instance, or on a coarser level via
>>>> subscriber-match that is a list with a  leaf that accepts not only ip-
>>>> prefix but a pool id (leafref) as well.
>>>>
>>>> Talking about multiple pools, it is possible that pools have different
>>>> settings (max number of subs per outside IP address, etc). So pool
>> config
>>>> should have additional parameters (pool should be a list with multiple
>>>> leafs). So we allow this today, a very flexible config that may now get
>>>> restricted because of configuration constraints.
>>>>
>>>> ----------------
>>>> The reason why such advanced filters are not included is that the same
>>>> objective can be achieved by defining multiple NAT instances; each with
>>>> dedicated pools and port assignment policies .
>>>>
>>>>
>>>> [Kris] True, but I was hoping that a more elegant solution can be
>> found.
>>>> Otherwise a new NAT instance would be required per pool. NAT instance
>> even
>>>> in your proposal supports multiple pools, it would be nice to find a
>> way
>>>> to selectively map traffic to those pools within the context of a NAT
>>>> instance.
>>>>
>>>> Please note that a similar feature is supported for NAT64: the NAT64
>>>> prefix can be selected as a function of the destination prefix.
>>>>
>>>>              +--rw nat64-prefixes* [nat64-prefix]
>>>>              |  +--rw nat64-prefix               inet:ipv6-prefix
>>>>              |  +--rw destination-ipv4-prefix* [ipv4-prefix]
>>>>              |     +--rw ipv4-prefix    inet:ipv4-prefix
>>>>
>>>> One minor comment: from an IETF standpoint, "routing context" may be
>>>> confusing for people as NAT is not a routing function.
>>>>
>>>>>
>>>>> We have a different approach, with three main building blocks:
>>>>>
>>>>> 1)  in inside (private) routing context we define parameters that are
>>>>> related to inside. For example destination-prefix (what will get sent
>>>>> to NAT for translation) in NAT44, then NAT64 prefix, deterministic nat
>>>>> parameters, DS-lite AFTR address (I know that ds-lite is covered in
>>>>> different draft), some other L2-Aware NAT parameters, etc.
>>>>
>>>> [Med] Putting aside that we mark explicitly those parameters as
>> "inside",
>>>> most of those parameters are supported in this version (and the DS-Lite
>>>> YANG).
>>>>
>>>>> 2) then we go to outside routing contextS. There we define pool and
>>>>> pool related parameters: outside-address range, pool watermarks, size
>>>>> of the port-blocks in the pool, port-forwarding ranges in the pool,
>>>>> number of subscribers per outside IP, etc.
>>>>
>>>> [Med] Great. Putting aside that we mark explicitly those parameters as
>>>> "outside", those parameters are supported in this version.
>>>>
>>>>> 3) then we have a nat-policy that serves as a glue that connects the
>>>>> inside routing context and the outside routing contexts (can be more
>>>>> of
>>>>> them) and the pools.
>>>>> In nat-policy  definition we reference a pool, enable ALGs, set the
>>>>> session limit per subscriber, number of port-blocks per subscriber,
>>>>> filtering mode, priority sessions (based on forwarding-class), timouts
>>>>> (tpc, udp, icmp), etc.
>>>>> This policy is then referenced in the inside routing context. At that
>>>>> point when the packet is received in the inside, it knows which pool
>>>>> (and outside routing context) it needs to go to - based on the
>>>>> classification in the ip-filter with action NAT (applied to an
>>>>> interface) or based on the destination-prefix (as configured in the
>>>> inside routing context).
>>>>>
>>>>> The key is that we allow forking to multiple pools from the same
>>>>> inside routing context. For example:
>>>>> Destination-prefix   10.10.10.0/24 nat-policy "nat-pol-name-1"    ==>
>>>> nat-
>>>>> pol-name-1 references a pool and the outside routing context
>>>>> Destination-prefix 10.20.20.0/24 nat policy "nat-pol-name-2"  ==>
>>>>> nat-pol-
>>>>> name-2 reference a different pool in the same outside routing context
>>>>> as above or a different one
>>>>>
>>>>> (same can be achieved with filters that are applied to interfaces -
>>>>> with filters we have a much wider range of classification options -
>>>>> what gets diverted to NAT).
>>>>
>>>> [Med] Agree. Those are out of the scope.
>>>>
>>>>>
>>>>> Then on a side, we have nat-classifiers that deal with destination-
>> nat.
>>>>> There we identify traffic that needs to be dNTAed and we specify the
>>>>> dest- ip address in the same classifier. This classifier is then
>>>>> applied in nat- policy as well.
>>>>>
>>>>> There are a few other pieces that deal with logging, pcp etc functions
>>>>> that are scattered around, but this can be consolidated. But I'm
>>>>> afraid that this 3 prong structure (inside, outside, nat-policy) would
>>>>> be harder to consolidate.
>>>>>
>>>>>
>>>>> From your proposal in the draft, I'm not clear how do you ensure
>>>>> separation of routing context and selection of different pools.
>>>>
>>>> [Med] As mentioned above, the current model does support this by
>> defining
>>>> multiple NAT instances.
>>>>
>>>>  I see that
>>>>> inside interfaces and outside interfaces are referenced in the nat-
>>>>> instance, but there is no mention of routing context (although this
>>>>> can be derived from the interface name, assuming that intf name are
>>>>> unique chassis wide). Moreover I can't see how do you ensure selection
>>>>> of a pool based on some classification on ingress (say
>>>>> destination-prefix A go to pool 1, destination-prefix B to pool 2).
>>>>
>>>> [Med] This is not supported within the same NAT instance. I'm open to
>>>> discuss if/how to update the module to include this feature.
>>>>
>>>>>
>>>>>
>>>>> We definitely want to be part of this discussion
>>>>
>>>> [Med] Great!
>>>>
>>>> , but at this point I'm
>>>>> not sure how to proceed. It would be great if you can advise. Thanks.
>>>>
>>>> [Med] I see the following options:
>>>> (1) Continue the discussion in private to figure out what modifications
>>>> can be implemented to address your comments.
>>>> (2) Forward this mail to the OPSAWG mailing list and take it for there.
>>>>
>>>> Proceeding with both is also an option. For example, I can start by
>>>> sharing your concern with the WG and then discuss in private how to
>>>> address it.
>>>>
>>>> Please let me know your preference.
>>>>
>>>>> Kris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Henderickx, Wim (Nokia - BE/Antwerp)
>>>>> Sent: Thursday, August 31, 2017 11:31 PM
>>>>> To: Poscic, Kristian (Nokia - US) 
>>>>> Subject: FW: Request to review draft-ietf-opsawg-nat-yang-01
>>>>>
>>>>> Can you comments on this?
>>>>>
>>>>> On 22/08/2017, 14:23, "mohamed.boucadair@orange.com"
>>>>>  wrote:
>>>>>
>>>>>     Hi Wim,
>>>>>
>>>>>     I hope you are doing well!
>>>>>
>>>>>     Can you please review this model? I'm particularly interested to
>>>>> see if the model is aligned with your 7750 NAT44/NAT64 implementation.
>>>>>
>>>>>     Thank you.
>>>>>
>>>>>     Cheers,
>>>>>     Med
>>>>>
>>>>>     > -----Message d'origine-----
>>>>>     > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>>>     > Envoyé : lundi 21 août 2017 11:10
>>>>>     > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET
>>>>> Christian
>>>>>     > IMT/OLN; opsawg-chairs@ietf.org; Qin Wu
>>>>>     > Objet : New Version Notification for draft-ietf-opsawg-nat-yang-
>>>>> 01.txt
>>>>>     >
>>>>>     >
>>>>>     > A new version of I-D, draft-ietf-opsawg-nat-yang-01.txt
>>>>>     > has been successfully submitted by Mohamed Boucadair and posted
>>>>> to the
>>>>>     > IETF repository.
>>>>>     >
>>>>>     > Name:		draft-ietf-opsawg-nat-yang
>>>>>     > Revision:	01
>>>>>     > Title:		A YANG Data Model for Network Address Translation
>>>>> (NAT)
>>>>>     > and Network Prefix Translation (NPT)
>>>>>     > Document date:	2017-08-21
>>>>>     > Group:		opsawg
>>>>>     > Pages:		73
>>>>>     > URL:            https://www.ietf.org/internet-drafts/draft-ietf-
>>>>> opsawg-
>>>>>     > nat-yang-01.txt
>>>>>     > Status:         https://datatracker.ietf.org/doc/draft-ietf-
>>>> opsawg-
>>>>> nat-
>>>>>     > yang/
>>>>>     > Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-
>> nat-
>>>>> yang-01
>>>>>     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>> ietf-
>>>>> opsawg-
>>>>>     > nat-yang-01
>>>>>     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-
>>>> opsawg-
>>>>> nat-
>>>>>     > yang-01
>>>>>     >
>>>>>     > Abstract:
>>>>>     >    For the sake of network automation and the need for
>> programming
>>>>>     >    Network Address Translation (NAT) function in particular, a
>>>> data
>>>>>     >    model for configuring and managing the NAT is essential.
>> This
>>>>>     >    document defines a YANG data model for the NAT function.
>>>>>     >
>>>>>     >    NAT44, Network Address and Protocol Translation from IPv6
>>>> Clients
>>>>> to
>>>>>     >    IPv4 Servers (NAT64), Customer-side transLATor (CLAT),
>> Explicit
>>>>>     >    Address Mappings for Stateless IP/ICMP Translation (SIIT
>> EIM),
>>>>> and
>>>>>     >    IPv6 Network Prefix Translation (NPTv6) are covered in this
>>>>> document.
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     > 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
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> OPSAWG mailing list
>>> OPSAWG@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>
> 


From nobody Wed Sep 27 10:20:17 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 596C9134E8A for ; Wed, 27 Sep 2017 10:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Nsx33sgGElfm for ; Wed, 27 Sep 2017 10:20:14 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68E1134E7D for ; Wed, 27 Sep 2017 10:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3779; q=dns/txt; s=iport; t=1506532813; x=1507742413; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9JXU5Pc4j1Xpj6OkB7d4s7MIkQ4/0RmVsm8CTOGBaOk=; b=R4wz0UxEb+Yrce1ZezehPnUVDs9d6lfdsEvkZwVhtiscEd+UMWiZSDaZ FsHzPIsjJIaAvqUCAgrQeTo+WE882+pMekQv4rBNNg34RFhgyeKpK9Bfk J90y5Gf/RrIgYZGsgln57eK0f2A0p0UtTIUQldFhtoufhI0VIaI4pntTd A=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800";  d="asc'?scan'208";a="656048031"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 17:20:12 +0000
Received: from [10.61.235.182] ([10.61.235.182]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8RHKBvA009169; Wed, 27 Sep 2017 17:20:11 GMT
To: Kent Watsen , "Max Pritikin (pritikin)" 
Cc: "opsawg@ietf.org" 
References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com>  <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com> <8500A252-4867-41E3-806D-DD700953A777@cisco.com> <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>
From: Eliot Lear 
Message-ID: <86f2caad-9d80-1539-9641-3426df1581c0@cisco.com>
Date: Wed, 27 Sep 2017 19:20:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtaMTFBgMGerc2IldlJLKSbFJIBjWmxtt"
Archived-At: 
Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11
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, 27 Sep 2017 17:20:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vtaMTFBgMGerc2IldlJLKSbFJIBjWmxtt
Content-Type: multipart/mixed; boundary="O7qJHVIr7a00MU8wlHIdVXReqGcLd6luq";
 protected-headers="v1"
From: Eliot Lear 
To: Kent Watsen ,
 "Max Pritikin (pritikin)" 
Cc: "opsawg@ietf.org" 
Message-ID: <86f2caad-9d80-1539-9641-3426df1581c0@cisco.com>
Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11
References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com>
 
 <587377b8-02d5-d209-dc1d-2279be332f2a@cisco.com>
 <8500A252-4867-41E3-806D-DD700953A777@cisco.com>
 <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>
In-Reply-To: <360DB637-6ACD-4BBD-88DF-935F13DDA43A@juniper.net>

--O7qJHVIr7a00MU8wlHIdVXReqGcLd6luq
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Kent,


On 9/26/17 10:17 PM, Kent Watsen wrote:
> I'm not disputing the value of being able to relay such information (th=
ough it's missing in the brski draft), I'm just thinking that rather than=
 hardcode something into the base MUD file description, that the same can=
 be done using the extension mechanism that this draft is defining instea=
d.  Same data, just declared differently.  If there is a claim that it is=
 too hard, then I'd recommend spending more time examining the extension =
mechanism now rather than after this becomes an RFC.
>
> That said, maybe we should challenge the necessity of this field, or at=
 least examine to what end this idea is valid.  First, just to throw it o=
ut there, why not also add a "zerotouch-server" field?  I'm guessing that=
 this field enables lazy-binding so, rather than a device hardcoding such=
 info, it be determined operationally.  Other resources apply too, right?=
  Sometimes devices need to reach out to well-known resources for e.g., a=
nti-x signature packs.  Would the location for these resources also be ma=
p-able via a MUD file?  Note that I'm not actually advocating for any of =
this at the moment, just trying to understand what's intended here.
>
>

As I mentioned in an earlier message, I'm inclined to want to remove
rather than add, and I think it's a reasonable suggestion to remove the
masa-server to an extension that can then be discussed in the ANIMA WG.=C2=
=A0
It may interest you to know the reasoning for it being there in the
first place: initially there was no way in the BRSKI draft to find the
masa server, and this seemed like a simple solution.=C2=A0 Now that they =
have
solved for that separately, I do like the idea of the server being
listed in the MUD file, but as an extension, for the simple reason that
the manufacturer can keep certificates small by listing this in the MUD
file.=C2=A0 I invite you to do the same for a zerotouch-server.

Thanks for calling this out.

Eliot


--O7qJHVIr7a00MU8wlHIdVXReqGcLd6luq--

--vtaMTFBgMGerc2IldlJLKSbFJIBjWmxtt
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

iQEcBAEBCAAGBQJZy93LAAoJEIe2a0bZ0nozSCUH/3/MqAZCNS5QGhgt3WIvNBrU
vJIwxxGy1Z2cMFDkNwKMWfGCJgD6aj1MPDCKwdmStUZzoCrmT1WhK3qVnY3KlqDE
v+O8Cig2rkYcscmWEGNXvMzkLYN7113yihvIla72OBk/4Dx1TcJwQYSarmBiWdCA
s5ckFr2LQoN/dgN1hspqx/t6+YBrpk8e6r9VALF8SLGqKMk2J1phMgfBZ5L88m1+
e2pxuqk/Pydg8JmJBqG/GQhIfqWn9i8k8SnENq9aSmRQ1JMngnmKOxEQ71ZJ8F6E
/nr908LU5cZUKsrjqixiHBG5Sd5WBJuvq2kHWdUZgsaDM12BfzYUmPXTLTPXUOY=
=/KJV
-----END PGP SIGNATURE-----

--vtaMTFBgMGerc2IldlJLKSbFJIBjWmxtt--


From nobody Wed Sep 27 10:31:02 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 D93101342EB; Wed, 27 Sep 2017 10:31:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
CC: draft-ietf-opsawg-service-model-explained@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou , opsawg@ietf.org, zhoutianran@huawei.com, warren@kumari.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <150653346088.25068.7136617050123597275.idtracker@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 10:31:00 -0700
Archived-At: 
Subject: [OPSAWG] Last Call:  (Service Models Explained) to Informational RFC
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: Wed, 27 Sep 2017 17:31:01 -0000

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Service
Models Explained'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   The IETF has produced many modules in the YANG modeling language.
   The majority of these modules are used to construct data models to
   model devices or monolithic functions.

   A small number of YANG modules have been defined to model services
   (for example, the Layer Three Virtual Private Network Service Model
   produced by the L3SM working group and documented in RFC 8049).

   This document describes service models as used within the IETF, and
   also shows where a service model might fit into a Software Defined
   Networking architecture.  Note that service models do not make any
   assumption of how a service is actually engineered and delivered for
   a customer; details of how network protocols and devices are
   engineered to deliver a service are captured in other modules that
   are not exposed through the Customer-Provider Interface.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Wed Sep 27 10:40: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 A4771134EBF for ; Wed, 27 Sep 2017 10:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 gnDiBj9eRyEk for ; Wed, 27 Sep 2017 10:40:03 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D58134EB7 for ; Wed, 27 Sep 2017 10:40:02 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id b195so21067224wmb.5 for ; Wed, 27 Sep 2017 10:40:02 -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=PAI5zwTinMyS1rBjImHnSgw/q/ROm2qWhonenk952X4=; b=VN5a7y6fVg2B+GR6eR/C0Hw/Zag0NdiJMg4rp+j+IDnv9s4pJkJzQoqezklG5NmMgZ lJBnumLIyi1mFIWNU7LfOsLzn+PvmAvasD34PNXJjQiF3PW2BUKL8a/qTojZ4ZlCkvFf rzSt9YTizja4GqXCi2Cw7LJ/Gh+MJkyqZwzbBUlWJv6AfAcZVjlYO3bev9iYQ2ltF3FI r6i4ge+Y8ksa+f4tCbgUmTaURraMbCqt+88jANvxaVER9R5Cxs5UFoDLbugmWOcefWvS WGyLsDGAr1AtUGektwSIbfxhcBGqrObg//hZH95q1kPoSnXWiLFELV3SgdkJ4B12ATIK 9vVQ==
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=PAI5zwTinMyS1rBjImHnSgw/q/ROm2qWhonenk952X4=; b=NS5ltja6WxKy1kpeetALOrLHmWvko8f/KZuC2GDsfph9Z2ZQYReEJ4/OcpsZGaBdz2 GraBAHFaSzk2ngq5zVmsn9t7Yq6JaGrSOCmnyHfw6WvRuobOdLmsa5UiWfFdqLIZOpJ0 SA8TSD1OfBVMjzyFfEY5NX3DtOpgOhJAC3WM0Fduv5Q6cyKLFyCxk7x4t4URjejl+0An nMieGEXLz+hvRFk4qlr1UVRsQP/yUe4ld1M1FDnFr7aw/gk8V/NE8JF781oQ0Obi/+Tw gIGy1Dyak+lG2TFgp/JrOmMZcJypTd1REPQq5/URVc5+fiJnVg6sdUqAsQ5KS03OZcsS TYWQ==
X-Gm-Message-State: AHPjjUgleEguw46DYBSsiZXgqV8vCZFjLWH0MaBgkibFjVQ1fIMxMl0v q5VxPDHKfwKPMShLqytUNaS8K+Kc+1iNdLr/iKlo0w==
X-Google-Smtp-Source: AOwi7QAK06N0Ny4zI16rCwY8GRAJju4WAhErIBmaUTieeBe+PpR8Dx284Olzy+F+UE6lFEfj9wAfTKA7S8SxyzFhQdw=
X-Received: by 10.28.157.1 with SMTP id g1mr851941wme.140.1506534000838; Wed, 27 Sep 2017 10:40:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.141 with HTTP; Wed, 27 Sep 2017 10:39:20 -0700 (PDT)
In-Reply-To: <150653346088.25068.7136617050123597275.idtracker@ietfa.amsl.com>
References: <150653346088.25068.7136617050123597275.idtracker@ietfa.amsl.com>
From: Warren Kumari 
Date: Wed, 27 Sep 2017 10:39:20 -0700
Message-ID: 
To: IETF Discuss 
Cc: draft-ietf-opsawg-service-model-explained@ietf.org,  "opsawg-chairs@ietf.org" , Tianran Zhou , opsawg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OPSAWG] Last Call:  (Service Models Explained) to Informational RFC
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, 27 Sep 2017 17:40:06 -0000

Apologies everyone, I accidentally hit the wrong button in the datatracker.

This document has already successfully passed IETF LC
(https://mailarchive.ietf.org/arch/msg/ietf-announce/FXMc81LranPhaqpS_rIOE6Q8nbA),
I am not restarting it.

Sorry again for the noise / mis-click.
W



On Wed, Sep 27, 2017 at 10:31 AM, The IESG  wrote:
>
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document: - 'Service
> Models Explained'
>    as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The IETF has produced many modules in the YANG modeling language.
>    The majority of these modules are used to construct data models to
>    model devices or monolithic functions.
>
>    A small number of YANG modules have been defined to model services
>    (for example, the Layer Three Virtual Private Network Service Model
>    produced by the L3SM working group and documented in RFC 8049).
>
>    This document describes service models as used within the IETF, and
>    also shows where a service model might fit into a Software Defined
>    Networking architecture.  Note that service models do not make any
>    assumption of how a service is actually engineered and delivered for
>    a customer; details of how network protocols and devices are
>    engineered to deliver a service are captured in other modules that
>    are not exposed through the Customer-Provider Interface.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>



-- 
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 Sep 28 08:03:08 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 92DAB1332CE; Thu, 28 Sep 2017 08:03:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150661098657.27667.3977541214616498530@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 08:03:06 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-04.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 15:03:06 -0000

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

        Title           : A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT)
        Authors         : Mohamed Boucadair
                          Senthil Sivakumar
                          Christian Jacquenet
                          Suresh Vinapamula
                          Qin Wu
	Filename        : draft-ietf-opsawg-nat-yang-04.txt
	Pages           : 78
	Date            : 2017-09-28

Abstract:
   For the sake of network automation and the need for programming
   Network Address Translation (NAT) function in particular, a data
   model for configuring and managing the NAT is essential.  This
   document defines a YANG module for the NAT function.

   NAT44, Network Address and Protocol Translation from IPv6 Clients to
   IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
   Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and
   IPv6 Network Prefix Translation (NPTv6) are covered in this document.


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

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

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


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 Thu Sep 28 08:07:59 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 40127133200 for ; Thu, 28 Sep 2017 08:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oX8eutPwdN4z for ; Thu, 28 Sep 2017 08:07:52 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF58C1332E3 for ; Thu, 28 Sep 2017 08:07:51 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 75E6160564; Thu, 28 Sep 2017 17:07:50 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 5673718006E; Thu, 28 Sep 2017 17:07:50 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Thu, 28 Sep 2017 17:07:47 +0200
From: 
To: "opsawg@ietf.org" 
CC: Senthil Sivakumar , JACQUENET Christian IMT/OLN , Qin Wu , "sureshk@juniper.net" 
Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-04.txt
Thread-Index: AQHTOGrl9hm+xa2tJU65m3iy7ydxu6LKZT0w
Date: Thu, 28 Sep 2017 15:07:47 +0000
Message-ID: <3383eb88-5299-4e94-bec7-bc91a1b04373@OPEXCLILM24.corporate.adroot.infra.ftgroup>
References: <150661098669.27667.2985159583704772900.idtracker@ietfa.amsl.com>
In-Reply-To: <150661098669.27667.2985159583704772900.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-04.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: Thu, 28 Sep 2017 15:07:58 -0000

RGVhciBXRywgDQoNClRoZSBuZXcgdmVyc2lvbiB0YWtlcyBpbnRvIGFjY291bnQgdGhlIGNvbW1l
bnRzIGZyb20gS3JpcywgbWFpbmx5Og0KLSBhbGxvdyBmb3IgbXVsdGlwbGUgY29uZmlnIHdpdGhp
biB0aGUgc2FtZSBOQVQgaW5zdGFuY2UuDQotIGJpbmQgYW4gZXh0ZXJuYWwgaW50ZXJmYWNlIHdp
dGggYSBzcGVjaWZpYyBOQVQgY29uZmlnLg0KDQpDaGFpcnMsIG5vdyB0aGF0IHdlIChhdXRob3Jz
KSBhc2tlZCBmb3IgZXh0ZXJuYWwgcmV2aWV3cyBjb3ZlcmluZyAoQ0xBVCwgRUFNLCBOUFR2NiBh
bmQgQ0dOKSwgd2UgZG8gdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgaXMgbm93IHJlYWR5IGZvciBh
biBlYXJseSBZQU5HIGRvY3RvcnMgcmV2aWV3LiBDYW4geW91IHBsZWFzZSBhcnJhbmdlIGZvciBp
dD8gVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l
LS0tLS0NCj4gRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGpldWRpIDI4IHNlcHRlbWJyZSAyMDE3IDE3
OjAzDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNlbnRoaWwgU2l2YWt1bWFy
OyBKQUNRVUVORVQgQ2hyaXN0aWFuDQo+IElNVC9PTE47IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7
IFFpbiBXdQ0KPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll
dGYtb3BzYXdnLW5hdC15YW5nLTA0LnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E
LCBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wNC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1
bGx5IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ
RVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcN
Cj4gUmV2aXNpb246CTA0DQo+IFRpdGxlOgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5ldHdvcmsg
QWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFUKQ0KPiBhbmQgTmV0d29yayBQcmVmaXggVHJhbnNsYXRp
b24gKE5QVCkNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNy0wOS0yOA0KPiBHcm91cDoJCW9wc2F3Zw0K
PiBQYWdlczoJCTc4DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC15YW5nLTA0LnR4dA0KPiBTdGF0
dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v
cHNhd2ctbmF0LQ0KPiB5YW5nLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTA0DQo+IEh0bWxpemVkOiAgICAg
ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdn
LQ0KPiBuYXQteWFuZy0wNA0KPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4geWFuZy0wNA0KPiANCj4gQWJz
dHJhY3Q6DQo+ICAgIEZvciB0aGUgc2FrZSBvZiBuZXR3b3JrIGF1dG9tYXRpb24gYW5kIHRoZSBu
ZWVkIGZvciBwcm9ncmFtbWluZw0KPiAgICBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5B
VCkgZnVuY3Rpb24gaW4gcGFydGljdWxhciwgYSBkYXRhDQo+ICAgIG1vZGVsIGZvciBjb25maWd1
cmluZyBhbmQgbWFuYWdpbmcgdGhlIE5BVCBpcyBlc3NlbnRpYWwuICBUaGlzDQo+ICAgIGRvY3Vt
ZW50IGRlZmluZXMgYSBZQU5HIG1vZHVsZSBmb3IgdGhlIE5BVCBmdW5jdGlvbi4NCj4gDQo+ICAg
IE5BVDQ0LCBOZXR3b3JrIEFkZHJlc3MgYW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2
NiBDbGllbnRzIHRvDQo+ICAgIElQdjQgU2VydmVycyAoTkFUNjQpLCBDdXN0b21lci1zaWRlIHRy
YW5zTEFUb3IgKENMQVQpLCBFeHBsaWNpdA0KPiAgICBBZGRyZXNzIE1hcHBpbmdzIGZvciBTdGF0
ZWxlc3MgSVAvSUNNUCBUcmFuc2xhdGlvbiAoU0lJVCBFQU0pLCBhbmQNCj4gICAgSVB2NiBOZXR3
b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBUdjYpIGFyZSBjb3ZlcmVkIGluIHRoaXMgZG9jdW1l
bnQuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291
cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRo
ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v
cmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=