From nobody Thu Aug 1 05:36:29 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCB0120114 for ; Thu, 1 Aug 2019 05:36:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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-UDmPKTdZ4e for ; Thu, 1 Aug 2019 05:36:25 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (outbound-ss-879.bluehost.com [69.89.30.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9335D12015C for ; Thu, 1 Aug 2019 05:36:25 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id D7D051E0BE3 for ; Thu, 1 Aug 2019 06:36:22 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id tAJihZT3cOUBLtAJihCcNb; Thu, 01 Aug 2019 06:36:22 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=XpvUx2N9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=FmdZ9Uzk2mMA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=tU8FuLBcg36gNBVfs3MA:9 a=QEXdDO2ut3YA:10:nop_charset_2 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TL+kDdC4ISqsoULI1W+FWY9wOyzQDmIuQ0O/H7xfWtA=; b=YIWpDqvTviWMSaM8ufimeMrQol Fu15AugAMuiT/O8gOojhEjvE4A18w2r77NEEmyZcMsk30x+zk2Vn6JlCUTElIlrszRW+mwKOQzaQi 7W0//IcwyOO/ybLSbYAQcR2nF; Received: from [127.0.0.1] (port=34365 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1htAJi-000gO0-EC; Thu, 01 Aug 2019 06:36:22 -0600 To: Joel Jaeggli , netmod@ietf.org, draft-ietf-netmod-module-tags@ietf.org, ibagdona@gmail.com References: <2dcd4d92-1436-4b9a-050f-ec36053ffa8a@bogus.com> From: Lou Berger Message-ID: <44052500-5827-ba7b-99b4-4d48236a4fb4@labn.net> Date: Thu, 1 Aug 2019 08:36:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <2dcd4d92-1436-4b9a-050f-ec36053ffa8a@bogus.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1htAJi-000gO0-EC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:34365 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] draft-ietf-netmod-module-tags needs a correction X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 12:36:28 -0000 Joel,     The only needed edit is the addition of the -state appendix, right?  Or is something else needed? Thanks, Lou (as co-author) On 7/27/2019 5:54 PM, Joel Jaeggli wrote: > Folks Ignas, > > draft-ietf-netmod-module-tags, currently in IESG review is in need of a > a fairly significant edit, notably the addition of an appendix covering > the nmda state. It seems wiser to pull it back and add that rather than > proceed forward with the document as is. > > Thanks > > joel > From nobody Thu Aug 1 17:09:10 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8B2120073; Thu, 1 Aug 2019 17:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v70qfCHEGCfR; Thu, 1 Aug 2019 17:08:59 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F54912001A; Thu, 1 Aug 2019 17:08:59 -0700 (PDT) Received: from MacBook-Pro.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7208tXx010115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Aug 2019 20:08:56 -0400 To: Kent Watsen Cc: IETF discussion list , Ignas Bagdonas , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, "netmod@ietf.org" References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> <1e399e65-4cc9-1e46-018f-5d6427e953c9@alum.mit.edu> <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com> From: Paul Kyzivat Message-ID: <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu> Date: Thu, 1 Aug 2019 20:08:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Last Call: (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 00:09:01 -0000 Kent, On 7/31/19 3:41 PM, Kent Watsen wrote: > Hi Paul, > > Thanks for your comments! > > >> 1) Section 6.2 recommends only using double backslash folding if >> single backslash folding doesn't work. But all the examples in section >> 9 violate this. > > True, but these example illustrate the algorithm itself, and so seem > okay, or is your suggestion to add text stating this? My suggestion is to use an example that would force the use of double backslash folding. This would mean that the the examples wouldn't be for the same text, but I don't think that is a problem. This would allow you to show the various forms that force use of double backslash folding. > FWIW, the `rfcfold` script in the appendix of the draft was used on all > the examples in Section 9. By default, the `rfcfold` script follows the > recommendation (i.e., single before double), but also accepts a > command-line option to specify the folding strategy to use. For the > examples in section 9, thiscommand-line optionwas used. > > >> 2) Regarding forced folding in section 8.2.1: step 1 (Determine where >> the fold will occur) could benefit from some elaboration regarding >> lines that require forced folding. In particular, when an input line >> flagged for forced folding ends in backslash, then it must indeed be >> folded before the last character, while in all other cases it can be >> folded at any position prior to the max line length. (While this is >> obvious if you think about it, some might miss this.) > > Your comment goes to step 1, are you suggesting a modification such as > the following? > > OLD > 1.Determine where the fold will occur. This location MUST be > before or at the desired maximumcolumn. > > NEW > 1.Determine where the fold will occur. This location MUST be > before or at the desired maximumcolumn. In the case of a forced > folding, the location MUST be before or at the end of the line. Not quite. I think: 1. Determine where the fold will occur. This location MUST be before or at the desired maximum column. This (of course) MUST be prior to the last character on the line. In the case of a forced folding, this may precede the desired maximum column. (Or do you want to allow the degenerate case where the line is folded at the end, so the continuation contains nothing?) >> Also, there should be examples of forced folding. > > Agreed. If forced folding example(s) are *added* then I think it is fine to retain the existing example done both ways. Thanks, Paul From nobody Fri Aug 2 06:22:35 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EA31200EF; Fri, 2 Aug 2019 06:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Yy749Exs2evt; Fri, 2 Aug 2019 06:22:24 -0700 (PDT) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE1312008C; Fri, 2 Aug 2019 06:22:23 -0700 (PDT) Received: from [172.20.10.2] (x2e7205cf.dyn.telefonica.de [46.114.5.207] (may be forged)) (authenticated bits=0) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x72DM6ax037417 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 2 Aug 2019 15:22:16 +0200 To: Paul Kyzivat , Kent Watsen Cc: Ignas Bagdonas , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, IETF discussion list , "netmod@ietf.org" References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> <1e399e65-4cc9-1e46-018f-5d6427e953c9@alum.mit.edu> <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com> <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu> From: Erik Auerswald Message-ID: <99a7009d-7ec4-f4b1-c157-961f2566a6ad@unix-ag.uni-kl.de> Date: Fri, 2 Aug 2019 15:22:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Last Call: (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 13:22:28 -0000 Hi Paul, I'll try to elaborate on my understanding of "forced folding" below: On 02.08.19 02:08, Paul Kyzivat wrote: > On 7/31/19 3:41 PM, Kent Watsen wrote: >> [...] >>> 2) Regarding forced folding in section 8.2.1: step 1 (Determine where >>> the fold will occur) could benefit from some elaboration regarding >>> lines that require forced folding. In particular, when an input line >>> flagged for forced folding ends in backslash, then it must indeed be >>> folded before the last character, while in all other cases it can be >>> folded at any position prior to the max line length. (While this is >>> obvious if you think about it, some might miss this.) If the original text data contains the folding sequence, one line of that text data ends in a backslash. If such a line is folded before the backslash, the folded data still contains the folding sequence that came from the original text data (in addition to the folding sequences inserted by folding). As I see it, forced folding would insert a new folding sequence inside of the original folding sequence. Example before folding: foo\ \bar Example after folding: == NOTE: '\\' line wrapping per BCP XX (RFC XXXX) == foo\\ \ \bar A line that requires forced folding and that is already of maximum length would be lengthened by forced folding, thus it would need to be folded twice. This, of course, shows that unfolding must not recursively try to unfold an already unfolded part of a line again. > [...] > (Or do you want to allow the degenerate case where the line is folded at > the end, so the continuation contains nothing?) I'd say that this degenerate case is required for forced folding to work. Thanks, Erik From nobody Fri Aug 2 09:16:51 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF60912028E; Fri, 2 Aug 2019 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxptkUab1QHt; Fri, 2 Aug 2019 09:16:40 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0E812025F; Fri, 2 Aug 2019 09:16:39 -0700 (PDT) Received: from MacBook-Pro.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x72GGZ2j032639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Aug 2019 12:16:37 -0400 To: Erik Auerswald , Kent Watsen Cc: Ignas Bagdonas , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, IETF discussion list , "netmod@ietf.org" References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> <1e399e65-4cc9-1e46-018f-5d6427e953c9@alum.mit.edu> <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com> <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu> <99a7009d-7ec4-f4b1-c157-961f2566a6ad@unix-ag.uni-kl.de> From: Paul Kyzivat Message-ID: Date: Fri, 2 Aug 2019 12:16:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <99a7009d-7ec4-f4b1-c157-961f2566a6ad@unix-ag.uni-kl.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Last Call: (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 16:16:43 -0000 On 8/2/19 9:22 AM, Erik Auerswald wrote: > Hi Paul, > > I'll try to elaborate on my understanding of "forced folding" below: > > On 02.08.19 02:08, Paul Kyzivat wrote: >> On 7/31/19 3:41 PM, Kent Watsen wrote: >>> [...] >>>> 2) Regarding forced folding in section 8.2.1: step 1 (Determine >>>> where the fold will occur) could benefit from some elaboration >>>> regarding lines that require forced folding. In particular, when an >>>> input line flagged for forced folding ends in backslash, then it >>>> must indeed be folded before the last character, while in all other >>>> cases it can be folded at any position prior to the max line length. >>>> (While this is obvious if you think about it, some might miss this.) > > If the original text data contains the folding sequence, one line of > that text data ends in a backslash. If such a line is folded before > the backslash, the folded data still contains the folding sequence that > came from the original text data (in addition to the folding sequences > inserted by folding). > > As I see it, forced folding would insert a new folding sequence inside > of the original folding sequence. > > Example before folding: > > foo\ > \bar > > Example after folding: > > == NOTE: '\\' line wrapping per BCP XX (RFC XXXX) == > > foo\\ > \ > \bar OK. I was still thinking of it a bit wrong. > A line that requires forced folding and that is already of maximum > length would be lengthened by forced folding, thus it would need to > be folded twice. > > This, of course, shows that unfolding must not recursively try to > unfold an already unfolded part of a line again. > >> [...] >> (Or do you want to allow the degenerate case where the line is folded >> at the end, so the continuation contains nothing?) > > I'd say that this degenerate case is required for forced folding to > work. Yeah, it seems so. It would be silly to do in any other case, but I guess it is not forbidden. But now that I am thinking about this, it occurs to me that maybe the two methods can be collapsed into one: just make the sequence to be inserted for folding be (using ABNF): "\" %x0C [%x0A] *" " ["\"] The trailing backslash only needs to be inserted if the character following it is a space or backslash. (IOW it is *optional* if the net character is *not* space or backslash.) So, when removing the folding, upon finding ("\" %x0C [%x0A] *" ") you remove that and if there is then a backslash remove that too. Thanks, Paul From nobody Fri Aug 2 11:23:12 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA41207DC for ; Fri, 2 Aug 2019 11:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 GOPslM5FecHG for ; Fri, 2 Aug 2019 11:23:09 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 479AC1207DE for ; Fri, 2 Aug 2019 11:23:07 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id x21so13568228otq.12 for ; Fri, 02 Aug 2019 11:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HCU7aVvFADd+AXa3UTL7Oelh/8WNxcv2GZFlBoidWis=; b=D5LrVBye7fmt5jO8ClsroaeDQqz5C2AMV2EyaYb92junP2AK7mWhhs130H8k034oIL nPQtWxqc+1kLoDqKMBFbTkwKdf8zDBNN6IdobByCTgnelFpRiySy9oRwjowFg1gFARSa K1YRMNrCsV2BZMRmwJP0N+TnGuuMO1zN+ppFQn6tv2kMc9784MTAxAxKRM9PTRx7tru8 dRImKZvF4gx6d6x6nyCK3clMTBgmf8F9LcluyEkvOO3RLrc7XHffq9O2xU3tXbYIgk12 eWmSItoieGdVvnRGIS5fLPbWGg3Zo1UfitsX15hiuVKGZaIboTHS+UQQde6WzBC74oPA M2Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HCU7aVvFADd+AXa3UTL7Oelh/8WNxcv2GZFlBoidWis=; b=M4EUBYnDUET1BZvplsY7FRQ08BdDhe+p1uwxJb6dNXHhUytfZNJRENGAfqqhzv2tVJ 3wJlFeD6v/1Dyo3Fzru5tuetb/pOMtzmjQdxwhbTJFP5ZKxkJDpuS5CSe52j4Zc82GYS GYGpmeZG2fxRJkJy7Pkti4gawskzseSptgLxJu3IZPf4XmAvg+2j6PlPdUsRgqJOybrq kRYDLmKqi75V2whHlL1+GJqgP8gJlAQ8zjGHQSh1Pot9xFGwUFpq+78j3sSgwdT1qh2J pQkHlY5FlVxptjals9aCULY2kx9wMMpCKm5afdvXKknixiwpO8LgK6/e9c6/B9tIgsIG Tlqg== X-Gm-Message-State: APjAAAWbtvFmiKpp3uAHyTLhp0Pufmn2jZnnY6uMr0mYd+o4kTSY0Abo BO7cv5Z0LiCHJCCQl2kHiVKW68BXUs1AKF2M7aQ= X-Google-Smtp-Source: APXvYqxxyZQLqdtLnlwqMZEjZzcZyFgPfoIZFPfya0r5EM+g12uxZuoTyIcO5cit1WAyGLPijVhUox6mcQ/CiJ63AHY= X-Received: by 2002:a9d:226c:: with SMTP id o99mr20332796ota.42.1564770186436; Fri, 02 Aug 2019 11:23:06 -0700 (PDT) MIME-Version: 1.0 References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> In-Reply-To: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Fri, 2 Aug 2019 13:22:35 -0500 Message-ID: To: IETF discussion list Cc: IETF-Announce , ibagdona@gmail.com, netmod-chairs@ietf.org, draft-ietf-netmod-artwork-folding@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000001e3784058f267380" Archived-At: Subject: Re: [netmod] Last Call: (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 18:23:11 -0000 --0000000000001e3784058f267380 Content-Type: text/plain; charset="UTF-8" I have no objection to publishing this document, but the fact that it is needed is a clear indication that the RFC series has failed to keep up with the needs of its consumers. Hopefully the new RSE will be able to address this disconnect, among others. --Richard On Tue, Jul 30, 2019 at 3:44 PM The IESG wrote: > > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'Handling Long Lines in Inclusions in > Internet-Drafts and RFCs' > as Best Current Practice > > 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 2019-08-13. 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 > > > This document defines two strategies for handling long lines in > width-bounded text content. One strategy is based on the historic > use of a single backslash ('\') character to indicate where line- > folding has occurred, with the continuation occurring with the first > non-space (' ') character on the next line. The second strategy > extends the first strategy by adding a second backslash character to > identify where the continuation begins and thereby able to handle > cases not supported by the first strategy. Both strategies use a > self-describing header enabling automated reconstitution of the > original content. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --0000000000001e3784058f267380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no objection to publishing this document, but = the fact that it is needed is a clear indication that the RFC series has fa= iled to keep up with the needs of its consumers.=C2=A0 Hopefully the new RS= E will be able to address this disconnect, among others.

=
--Richard

On Tue, Jul 30, 2019 at 3:44 PM The IESG <= iesg-secretary@ietf.org> = wrote:

The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'Handling Long Lines in Inclusions i= n
Internet-Drafts and RFCs'
=C2=A0 <draft-ietf-netmod-artwork-folding-07.txt> as Best Current Pra= ctice

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 mailin= g lists by 2019-08-13. 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


=C2=A0 =C2=A0This document defines two strategies for handling long lines i= n
=C2=A0 =C2=A0width-bounded text content.=C2=A0 One strategy is based on the= historic
=C2=A0 =C2=A0use of a single backslash ('\') character to indicate = where line-
=C2=A0 =C2=A0folding has occurred, with the continuation occurring with the= first
=C2=A0 =C2=A0non-space (' ') character on the next line.=C2=A0 The = second strategy
=C2=A0 =C2=A0extends the first strategy by adding a second backslash charac= ter to
=C2=A0 =C2=A0identify where the continuation begins and thereby able to han= dle
=C2=A0 =C2=A0cases not supported by the first strategy.=C2=A0 Both strategi= es use a
=C2=A0 =C2=A0self-describing header enabling automated reconstitution of th= e
=C2=A0 =C2=A0original content.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-netmod-artwork-folding/

IESG discussion can be tracked via
https://datatracker.ietf.o= rg/doc/draft-ietf-netmod-artwork-folding/ballot/


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




_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--0000000000001e3784058f267380-- From nobody Fri Aug 2 12:09:11 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 409AC12014F; Fri, 2 Aug 2019 12:09:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <156477295017.20930.12714844376867382037@ietfa.amsl.com> Date: Fri, 02 Aug 2019 12:09:10 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 19:09:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Handling Long Lines in Inclusions in Internet-Drafts and RFCs Authors : Kent Watsen Adrian Farrel Qin Wu Filename : draft-ietf-netmod-artwork-folding-08.txt Pages : 28 Date : 2019-08-02 Abstract: This document defines two strategies for handling long lines in width-bounded text content. One strategy is based on the historic use of a single backslash ('\') character to indicate where line- folding has occurred, with the continuation occurring with the first non-space (' ') character on the next line. The second strategy extends the first strategy by adding a second backslash character to identify where the continuation begins and thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-08 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 Aug 2 12:15:25 2019 Return-Path: <0100016c53c1e9f1-83ffddb3-1a59-4deb-b08a-1e16869eb8f2-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63712014F; Fri, 2 Aug 2019 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 isCVpUnfwk96; Fri, 2 Aug 2019 12:15:14 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E821200E9; Fri, 2 Aug 2019 12:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1564773313; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yW+Qq/WlXuXPKD0iHgPiP7wgXAzUORVkJpHeaUv84N8=; b=PpOFjVunervMxYCRzzKzjEYUNVBY/haqUY/EQeZ7RZWcuM3xGtr9u6KPvZEiP83K UFHOuVtwmys5Y1snfcbN2KaNdrTKLBMdmMOV6V8SXfioiChgOffnoUolsu+mNe/go4q wCabx3Fra56uSKNDonfUIUPzy5FXgDOEIrQ1DSA0= From: Kent Watsen Message-ID: <0100016c53c1e9f1-83ffddb3-1a59-4deb-b08a-1e16869eb8f2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4703C420-ED37-4888-BC66-2B089870853E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 2 Aug 2019 19:15:13 +0000 In-Reply-To: Cc: Erik Auerswald , Ignas Bagdonas , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, IETF discussion list , "netmod@ietf.org" To: Paul Kyzivat References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> <1e399e65-4cc9-1e46-018f-5d6427e953c9@alum.mit.edu> <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com> <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu> <99a7009d-7ec4-f4b1-c157-961f2566a6ad@unix-ag.uni-kl.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.02-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Last Call: (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 19:15:17 -0000 --Apple-Mail=_4703C420-ED37-4888-BC66-2B089870853E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Paul, > But now that I am thinking about this, it occurs to me that maybe the = two methods can be collapsed into one: >=20 > just make the sequence to be inserted for folding be (using ABNF): >=20 > "\" %x0C [%x0A] *" " ["\"] >=20 > The trailing backslash only needs to be inserted if the character = following it is a space or backslash. (IOW it is *optional* if the next = character is *not* space or backslash.) >=20 > So, when removing the folding, upon finding ("\" %x0C [%x0A] *" ") you = remove that and if there is then a backslash remove that too. Are you suggesting a hybrid approach where, within a folded file, a line = may be folded one way one the other based on context? Would that = detract from readability? FWIW, I just posted -08 that adds forced-folding support to the = single-backslash strategy as well as a couple forced folding examples. =20= https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-08 = Thank you for requesting these examples, as an issue in the `rfcfold` = script was found and fixed. Kent // as co-author --Apple-Mail=_4703C420-ED37-4888-BC66-2B089870853E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Paul,

But now that I = am thinking about this, it occurs to me that maybe the two methods can = be collapsed into one:

just make the = sequence to be inserted for folding be (using ABNF):

"\" %x0C [%x0A] *" " ["\"]

The = trailing backslash only needs to be inserted if the character following = it is a space or backslash. (IOW it is *optional* if the next character = is *not* space or backslash.)

So, when = removing the folding, upon finding ("\" %x0C [%x0A] *" ") you remove = that and if there is then a backslash remove that too.


Are you suggesting a hybrid approach where, within = a folded file, a line may be folded one way one the other based on = context?  Would that detract from readability?

FWIW, I just posted -08 = that adds forced-folding support to the single-backslash strategy as = well as a couple forced folding examples.   

https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-0= 8

Thank = you for requesting these examples, as an issue in the `rfcfold` script = was found and fixed.

Kent // as = co-author

= --Apple-Mail=_4703C420-ED37-4888-BC66-2B089870853E-- From nobody Fri Aug 2 13:10:21 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D678F120189; Fri, 2 Aug 2019 13:10:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-artwork-folding.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156477661481.21003.10781222745111642469@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:10:14 -0700 Archived-At: Subject: [netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:10:15 -0000 Reviewer: Robert Sparks Review result: Has Nits Reviewer: Robert Sparks Review result: Has Nits 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. This document introduces no new security concerns for the Internet. It aims to establish conventions for wrapping long lines in source code sections of RFCs. It does have shell scripts embedded in the Appendix. I see no obvious security issues with those scripts. I strongly suggest this document proceed as Informational and not BCP. It's fine if some documents adopt the convention. Other conventions may work better for other groups. See, for example, the convention described in section 2.1 of RFC4475. (No automated wrap/unwrap scripts have been written for that convention to my knowledge, but it would not be hard to create some.) Nits: In your headers, you anticipate receiving a two digit BCP number. At the moment, the next available BCP number has three digits. (We are well into the 200s). You have header lengths that would need to be adjusted. In 7.2.1 paragraph 5, I think you're saying to fail if any lines in the input document already end with a \. I think you mean to say any lines that you are considering wrapping. If I'm correct, the clarification may also need to be applied in other places where you say "the text content" From nobody Sun Aug 4 20:32:22 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DCD120146 for ; Sun, 4 Aug 2019 20:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSMe7sjI71kN for ; Sun, 4 Aug 2019 20:32:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00355120140 for ; Sun, 4 Aug 2019 20:32:18 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 58F3F18BD8B4E4B6A98C for ; Mon, 5 Aug 2019 04:32:16 +0100 (IST) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Aug 2019 04:32:15 +0100 Received: from DGGEMM533-MBS.china.huawei.com ([169.254.6.160]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0439.000; Mon, 5 Aug 2019 11:32:07 +0800 From: "Fengchong (frank)" To: "netmod@ietf.org" CC: "Zhangxiaoping (C)" , liuzhiying Thread-Topic: a question about 'when' Thread-Index: AdVLPM5Xmpgaa94hSz6Z+hOvCeCLfw== Date: Mon, 5 Aug 2019 03:32:07 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1DGGEMM533MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 03:32:20 -0000 --_000_5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1DGGEMM533MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I encounter a question about 'when', when I implement yang model associated= when condition. Yang model: leaf password-type { type enumeration { enum null; enum simple; enum cipher; } } leaf password-text { type string; when "../password-type !=3D null"; } I config these two leafs as below: simple 123456 And I changed password-type to null, I get the config like below: null And then, I reconfig the password-type to simple, what data should be retur= ned? Is simple Or simple 123456 --_000_5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1DGGEMM533MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I encounter a question about &#= 8216;when’, when I implement yang model associated when condition.

 

Yang model:

 

leaf password-type {=

   type enumeration {=

      = enum null;

      = enum simple;

      = enum cipher;

   }

}

 

leaf password-text {=

ty= pe string;

wh= en “../password-type !=3D null”;

}

 

I config these two leafs as bel= ow:

<password-type>simple<= /password-type>

<password-text>123456<= /password-text>

 

And I changed password-type to = null, I get the config like below:

<password-type>null</p= assword-type>

 

And then, I reconfig the passwo= rd-type to simple, what data should be returned?

 

Is

  <password-type&g= t;simple</password-type>

 

Or

 

  <password-type>sim= ple</password-type>

  <password-text>123= 456</password-type>

--_000_5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1DGGEMM533MBSchi_-- From nobody Mon Aug 5 02:49:03 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F97812015D for ; Mon, 5 Aug 2019 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 S5JV9QlduM8B for ; Mon, 5 Aug 2019 02:48:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EDE5C1200B6 for ; Mon, 5 Aug 2019 02:48:58 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 5F56D182048C; Mon, 5 Aug 2019 11:51:02 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 2B597182004A; Mon, 5 Aug 2019 11:50:59 +0200 (CEST) From: Ladislav Lhotka To: "Fengchong \(frank\)" , "netmod\@ietf.org" Cc: "Zhangxiaoping \(C\)" , liuzhiying In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> Mail-Followup-To: "Fengchong \(frank\)" , "netmod\@ietf.org" , "Zhangxiaoping \(C\)" , liuzhiying Date: Mon, 05 Aug 2019 11:48:52 +0200 Message-ID: <87o914gcxn.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 09:49:01 -0000 "Fengchong (frank)" writes: > Hi all, > > I encounter a question about 'when', when I implement yang model associated when condition. > > Yang model: > > leaf password-type { > type enumeration { > enum null; > enum simple; > enum cipher; > } > } > > leaf password-text { > type string; > when "../password-type != null"; > } > > I config these two leafs as below: > simple > 123456 > > And I changed password-type to null, I get the config like below: > null > > And then, I reconfig the password-type to simple, what data should be returned? > > Is > simple According to RFC 7950, sec. 8.2, the server deleted "password-text" after you changed "password-type" to null but the original value isn't recovered after you change the type back. This server behaviour means that a typo or similar trivial error may have catastrophic consequences such as auto-deletion of entire configuration subtrees. That's why our RESTCONF implementation (jetconf) does something else: it won't permit you to change "password-type" to null as long as the "password-text" exists. Lada > > Or > > simple > 123456 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Aug 5 07:11:08 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47B12022E; Mon, 5 Aug 2019 07:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPyQzGYYndDm; Mon, 5 Aug 2019 07:11:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFAF1201EC; Mon, 5 Aug 2019 07:11:04 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4A2B965ED94B0B25F1F2; Mon, 5 Aug 2019 15:11:02 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Aug 2019 15:10:55 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.18]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Mon, 5 Aug 2019 22:05:50 +0800 From: Qin Wu To: "draft-ietf-rtgwg-ni-model.all@ietf.org" CC: RTGWG , "netmod@ietf.org" , "Wangleilei (DOPRA SSP)" Thread-Topic: Add network instance name on interface, IPv4, IPv6 Thread-Index: AdVLk710rBBNwCAdSAaU2eImV7sW6Q== Date: Mon, 5 Aug 2019 14:05:50 +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.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA9283A10dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Add network instance name on interface, IPv4, IPv6 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 14:11:07 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA9283A10dggeml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors: In RFC8529, the bind-network-instance-name leaf provides the association be= tween an interface and its associated NI. However it is not clear to me why the same association between Ipv4/Ipv6 ty= pe and its association NI Should be provided as well? See model structure snippet defined in RFC8529 = as follows: " augment /if:interfaces/if:interface: +--rw bind-ni-name? -> /network-instances/network-instance/name augment /if:interfaces/if:interface/ip:ipv4: +--rw bind-ni-name? -> /network-instances/network-instance/name augment /if:interfaces/if:interface/ip:ipv6: +--rw bind-ni-name? -> /network-instances/network-instance/name " So the question is Can we add different NI name for IPv4/IPv6 type? Isn't IPv4 type and IPv6 t= ype and interface pointing to the same NI name? Why IPv4 type and IPv6 type in IP data model can not inherit the same NI na= me from the interface model since IP Data model is an extension to Interfac= e Data Model? Suppose we configure interface and associated IP addresses and assign this = interface to a NI, Which configuration snippet is correct: Option A: { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length": 24 } ] "ietf-network-instance:bind-network-instance-name": "vrf-red" }, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length": 64 } ] "ietf-network-instance:bind-network-instance-name": "vrf-red" }, "ietf-network-instance:bind-network-instance-name": "vrf-red" }, Option B: { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length": 24 } ] }, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length": 64 } ] }, "ietf-network-instance:bind-network-instance-name": "vrf-red" }, -Qin --_000_B8F9A780D330094D99AF023C5877DABAA9283A10dggeml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors:

In RFC8529, the b=
ind-network-instance-name leaf provides the association between an interfac=
e and its associated NI.
However it is not=
 clear to me why the same association between Ipv4/Ipv6 type and its associ=
ation NI
Should be provide=
d as well? See model structure snippet defined in RFC8529 as follows:<=
/o:p>

“

  = ; augment /if:interfaces/if:interface:

  = ;   +--rw bind-ni-name?   -> /network-instances/= network-instance/name

  = ; augment /if:interfaces/if:interface/ip:ipv4:

  = ;   +--rw bind-ni-name?   -> /network-instances/= network-instance/name

  = ; augment /if:interfaces/if:interface/ip:ipv6:

     +--rw bind-ni-name?   -&= gt; /network-instances/network-instance/name

“

So the question i=
s
Can we add differ=
ent NI name for IPv4/IPv6 type? Isn’t IPv4 type and IPv6 type and int=
erface pointing to the same NI name?
Why IPv4 type and=
 IPv6 type in IP data model can not inherit the same NI name from the inter=
face model since IP Data model is an extension to Interface Data Model?

Suppose we configure interface and associated IP addresses and = assign this interface to a NI,

Which configuration snippet is correct:

Option A:

{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
"ietf-network-instance:bind-network-instance-name": "vrf-red= "
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
"ietf-network-instance:bind-network-instance-name": "vrf-red= "
},
"ietf-network-instance:bind-network-instance-name": "vrf-red= "
},

Option B:

{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
},
"ietf-network-instance:bind-network-instance-name": "vrf-red= "
},

 

-Qin

--_000_B8F9A780D330094D99AF023C5877DABAA9283A10dggeml511mbschi_-- From nobody Mon Aug 5 09:47:12 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155BF1202C9; Mon, 5 Aug 2019 09:46:52 -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 header.b=JAKNrOz9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=f4TwRzrG 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 0bv7mW8Yw6tf; Mon, 5 Aug 2019 09:46:49 -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 4E8E11202B0; Mon, 5 Aug 2019 09:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19771; q=dns/txt; s=iport; t=1565023609; x=1566233209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Nxb/RXu3CXqGZzB/L9+5zSx//ZJS3ky3B1L82Eib1cE=; b=JAKNrOz9YPaks9MwVWd6sYDYRgZKcvxFkiJoZim3QkBwt9cCWsqCMzye wW3osGjAMZU612i0Bmd8I9sb6T1TAYsFZVsLAYBwB+5P0M9IPDLp4PQhk h2R+CcVqYukM4UvwFYszcZNlCoS0zp7E7d5U5BhoIg+hiFBRa+DRVMkPd M=; IronPort-PHdr: =?us-ascii?q?9a23=3A3PKc3hBzBKHWE8ejX5MMUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXETwIfPCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAACbXEhd/5FdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRUvJCwDbVUgBAsqhB6DRwOEUoZcglu?= =?us-ascii?q?JV4krhFeBLoEkA1QJAQEBDAEBLQIBAYQ/AheCWCM0CQ4BAwEBBAEBAgEGbYU?= =?us-ascii?q?eDIVKAQEBAQMSEQQZAQE3AQ8CAQgOAwMBAisCAgIfER0IAQEEAQ0FIoMAAYE?= =?us-ascii?q?dTQMdAQKhBwKBOIhgcX8zgnoBAQWFBg0LghMJgTQBi2IXgX+BOB+CHi4+ghq?= =?us-ascii?q?CSoJrMoImjwmFBCOWNEAJAoIbkCeDdxuYKY1HiVCOIAIEAgQFAg4BAQWBUDi?= =?us-ascii?q?BWHAVZQGCQYJCg3GKU3KBKY0TAQE?= X-IronPort-AV: E=Sophos;i="5.64,350,1559520000"; d="scan'208,217";a="610154215" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 16:46:47 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x75Gkl2C004585 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 16:46:47 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 11:46:46 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 12:46:45 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 11:46:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hiUDwxWOa4XOdFFbL1TvyZQ8/kEVmH27hMPpPHHJbqgiKv7paSP4NlZyM+/4j3PhetA3L3ZuIeoyztGj6mM9N2243cYgx+YrsPlaeSnpdqXiyFj818rmpSB5HVwftc9u+CkOE5S+Qnxys2F72UWYXVCOysl5sGxDKhvw3Z0cttAXZHkjY9CntxKaGnMnugi021G6A+Gt3wEruVGQgxZh5xj9a8ilmQWcjYN64dHzWt8IJAKtyhJLJfRnD8upsfq5F32GQ2ENjpMD4UF782YKDTRBd/7GhDjcSYPNnyP3lg11eaD4aHNvNbWuFF2JJBOzw36jJFGPz+hSIG/0Fwl8kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nxb/RXu3CXqGZzB/L9+5zSx//ZJS3ky3B1L82Eib1cE=; b=F0U6r/oOBiXfeh1Kk7mF8uk1YWVWt0C6fKKKBP+QeiU9z8etgH/Gp2WDI/qvXQNL9u2ldz+wK9mxPptrQhPgpi0ZLmCPmin465kdS+lRcGK7UZVFR5cT+uSER0r9Vv8K3psmwovDcBrgaiDBRNpsOiyiVmePVWRni3+d5vwyi4+jbUxLNOXtVa3V0rMQIMg5VAv8znFyH7YKQLsgkHzaAkSTIU3kkVy/pVbto3zOT4sTSN6uO9gT9RrpFOxVc47YJtdBXukYex07+/tgP3Ci/DtqLzXnVotmYtYCT/5M/cmk9w5YL+RTfhDj4jpO3Vh6zdnoHWBp7566lVMfQzo6Cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nxb/RXu3CXqGZzB/L9+5zSx//ZJS3ky3B1L82Eib1cE=; b=f4TwRzrGUWt3Qdakuk3NxXaaqG1ROspjZgawM7kPuih1FJL6WHCmwyabMLA47ejEbBmSarFM9EeaSRAR5I//Te7idZ8gJtcjyvItGoSLnFzl60a0dv0/o77YPwtqz44ZCbMjVQMbPVvXnQXGLX15/ssX9Gm/49PZOYPu0DMmo1M= Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB3856.namprd11.prod.outlook.com (20.178.251.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.20; Mon, 5 Aug 2019 16:46:44 +0000 Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0%3]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 16:46:44 +0000 From: "Acee Lindem (acee)" To: Qin Wu , "draft-ietf-rtgwg-ni-model.all@ietf.org" CC: RTGWG , "netmod@ietf.org" , "Wangleilei (DOPRA SSP)" Thread-Topic: Add network instance name on interface, IPv4, IPv6 Thread-Index: AdVLk710rBBNwCAdSAaU2eImV7sW6f//8C+A Date: Mon, 5 Aug 2019 16:46:44 +0000 Message-ID: <3BA052DB-49A2-4E4C-B6AC-2CB72F7EFA72@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [2001:420:c0c4:1001::2f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87ccf311-2e99-4bed-d50b-08d719c47fac x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3856; x-ms-traffictypediagnostic: MN2PR11MB3856: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(39860400002)(346002)(396003)(189003)(199004)(46003)(6486002)(99286004)(6116002)(86362001)(66476007)(64756008)(66446008)(66556008)(54896002)(6512007)(229853002)(6246003)(2501003)(66946007)(76116006)(33656002)(110136005)(2906002)(6306002)(53936002)(4326008)(6436002)(54906003)(36756003)(76176011)(478600001)(81166006)(256004)(81156014)(25786009)(71190400001)(5660300002)(486006)(8936002)(2616005)(476003)(11346002)(8676002)(446003)(102836004)(71200400001)(9326002)(68736007)(53546011)(14454004)(186003)(316002)(7736002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3856; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vYDJPQyKcLySHrFEZIgmH+n3Nf/5eEicO2050PYlUsIFaqU4iXYDEmhU82WSBZIOnX2MRTzE6r+hk02ncI63ZHE0kDQlN02Lk3gOR4Blu9XDXc1OchUAEnhyUkgx4AXdE/PF9G1BHefY9oAVLLN5OMCPJCQtlxRo58XzpRE2o6ovW0MDB7wP9iznpaPcR6AbyjwYq6EdjbRwJWntvEcLoETMnQGPNI6OWmBqfKLi0miYeCKtPB/BWrmcK9XS1Z8boDNrMULs+XE8I7gMVxVxtRrkUTl4UxIToCw3YYhWfS/Ml44lCav00rq97LHm3QrHtNtHgJxE+4IkwGc/GlBGvjUV8XqqmBImy/2faMCOh1gbwpfws11uHoYQ1h9cjCY1aH1nxAo58BuKLlWvu+eAu2HkZg4I9SbK5duOgF1QRLU= Content-Type: multipart/alternative; boundary="_000_3BA052DB49A24E4CB6AC2CB72F7EFA72ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87ccf311-2e99-4bed-d50b-08d719c47fac X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 16:46:44.0613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: acee@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3856 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netmod] Add network instance name on interface, IPv4, IPv6 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 16:47:04 -0000 --_000_3BA052DB49A24E4CB6AC2CB72F7EFA72ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWluLA0KDQpGcm9tOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCkRhdGU6IE1vbmRh eSwgQXVndXN0IDUsIDIwMTkgYXQgMTA6MTEgQU0NClRvOiAiZHJhZnQtaWV0Zi1ydGd3Zy1uaS1t b2RlbC5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsLmFsbEBpZXRmLm9y Zz4NCkNjOiBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZz4sICJuZXRtb2RAaWV0Zi5vcmciIDxu ZXRtb2RAaWV0Zi5vcmc+LCAiV2FuZ2xlaWxlaSAoRE9QUkEgU1NQKSIgPHdhbmdsZWlsZWlAaHVh d2VpLmNvbT4NClN1YmplY3Q6IEFkZCBuZXR3b3JrIGluc3RhbmNlIG5hbWUgb24gaW50ZXJmYWNl LCBJUHY0LCBJUHY2DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNl bnQtVG86IDxsYmVyZ2VyQGxhYm4ubmV0PiwgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBz Lm9yZz4sIEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbT4sIERlYW4gQm9nZGFub3ZpYyA8aXZh bmRlYW5AZ21haWwuY29tPiwgPHh1ZmVuZ19saXVAamFiaWwuY29tPiwgPGNocmlzYm93ZXJzLmll dGZAZ21haWwuY29tPiwgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+LCBZ aW5nemhlbiBRdSA8eWluZ3poZW4uaWV0ZkBnbWFpbC5jb20+LCBBbGlhIEF0bGFzIDxha2F0bGFz QGdtYWlsLmNvbT4sIE1hcnRpbiBWaWdvdXJldXggPG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29t PiwgRGVib3JhaCBCcnVuZ2FyZCA8ZGIzNTQ2QGF0dC5jb20+LCBBbHZhcm8gUmV0YW5hIDxhcmV0 YW5hLmlldGZAZ21haWwuY29tPiwgWWluZ3poZW4gUXUgPHlpbmd6aGVuLmlldGZAZ21haWwuY29t Pg0KUmVzZW50LURhdGU6IE1vbmRheSwgQXVndXN0IDUsIDIwMTkgYXQgMTA6MTEgQU0NCg0KSGks IGF1dGhvcnM6DQoNCkluIFJGQzg1MjksIHRoZSBiaW5kLW5ldHdvcmstaW5zdGFuY2UtbmFtZSBs ZWFmIHByb3ZpZGVzIHRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIGFuIGludGVyZmFjZSBhbmQgaXRz IGFzc29jaWF0ZWQgTkkuDQoNCkhvd2V2ZXIgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGUg c2FtZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIElwdjQvSXB2NiB0eXBlIGFuZCBpdHMgYXNzb2NpYXRp b24gTkkNCg0KU2hvdWxkIGJlIHByb3ZpZGVkIGFzIHdlbGw/IFNlZSBtb2RlbCBzdHJ1Y3R1cmUg c25pcHBldCBkZWZpbmVkIGluIFJGQzg1MjkgYXMgZm9sbG93czoNCuKAnA0KICAgYXVnbWVudCAv aWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6DQogICAgICstLXJ3IGJpbmQtbmktbmFtZT8gICAt PiAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lDQogICBhdWdtZW50IC9p ZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9pcDppcHY0Og0KICAgICArLS1ydyBiaW5kLW5pLW5h bWU/ICAgLT4gL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZQ0KICAgYXVn bWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UvaXA6aXB2NjoNCiAgICAgKy0tcncgYmlu ZC1uaS1uYW1lPyAgIC0+IC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUN CuKAnA0KDQpTbyB0aGUgcXVlc3Rpb24gaXMNCg0KQ2FuIHdlIGFkZCBkaWZmZXJlbnQgTkkgbmFt ZSBmb3IgSVB2NC9JUHY2IHR5cGU/IElzbuKAmXQgSVB2NCB0eXBlIGFuZCBJUHY2IHR5cGUgYW5k IGludGVyZmFjZSBwb2ludGluZyB0byB0aGUgc2FtZSBOSSBuYW1lPw0KDQpXaHkgSVB2NCB0eXBl IGFuZCBJUHY2IHR5cGUgaW4gSVAgZGF0YSBtb2RlbCBjYW4gbm90IGluaGVyaXQgdGhlIHNhbWUg TkkgbmFtZSBmcm9tIHRoZSBpbnRlcmZhY2UgbW9kZWwgc2luY2UgSVAgRGF0YSBtb2RlbCBpcyBh biBleHRlbnNpb24gdG8gSW50ZXJmYWNlIERhdGEgTW9kZWw/DQoNCg0KDQpUaGUgbW9kZWwgYWxs b3dzIHRoZSBJUHY0L0lQdjYgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgZm9yIG5ldHdvcmstaW5zdGFu Y2Ugc3BlY2lmaWNhdGlvbi4gSG93ZXZlciwgbWFueSwgaWYgbm90IG1vc3QsIGltcGxlbWVudGF0 aW9ucyBkbyBub3QuIE15IG1lbW9yeSBpcyBoYXp5IGFzIHRvIHdoaWNoIGltcGxlbWVudGF0aW9u KHMpIHN1cHBvcnRzIHRoaXMuDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNCg0KDQoNCg0KDQpTdXBw b3NlIHdlIGNvbmZpZ3VyZSBpbnRlcmZhY2UgYW5kIGFzc29jaWF0ZWQgSVAgYWRkcmVzc2VzIGFu ZCBhc3NpZ24gdGhpcyBpbnRlcmZhY2UgdG8gYSBOSSwNCldoaWNoIGNvbmZpZ3VyYXRpb24gc25p cHBldCBpcyBjb3JyZWN0Og0KT3B0aW9uIEE6DQp7DQoibmFtZSI6ICJldGgxIiwNCiJ0eXBlIjog ImlhbmEtaWYtdHlwZTpldGhlcm5ldENzbWFjZCIsDQoiaWV0Zi1pcDppcHY0Ijogew0KImFkZHJl c3MiOiBbDQp7DQoiaXAiOiAiMTkyLjAuMi4xMSIsDQoicHJlZml4LWxlbmd0aCI6IDI0DQp9DQpd DQoiaWV0Zi1uZXR3b3JrLWluc3RhbmNlOmJpbmQtbmV0d29yay1pbnN0YW5jZS1uYW1lIjogInZy Zi1yZWQiDQp9LA0KImlldGYtaXA6aXB2NiI6IHsNCiJhZGRyZXNzIjogWw0Kew0KImlwIjogIjIw MDE6ZGI4OjA6Mjo6MTEiLA0KInByZWZpeC1sZW5ndGgiOiA2NA0KfQ0KXQ0KImlldGYtbmV0d29y ay1pbnN0YW5jZTpiaW5kLW5ldHdvcmstaW5zdGFuY2UtbmFtZSI6ICJ2cmYtcmVkIg0KfSwNCiJp ZXRmLW5ldHdvcmstaW5zdGFuY2U6YmluZC1uZXR3b3JrLWluc3RhbmNlLW5hbWUiOiAidnJmLXJl ZCINCn0sDQpPcHRpb24gQjoNCnsNCiJuYW1lIjogImV0aDEiLA0KInR5cGUiOiAiaWFuYS1pZi10 eXBlOmV0aGVybmV0Q3NtYWNkIiwNCiJpZXRmLWlwOmlwdjQiOiB7DQoiYWRkcmVzcyI6IFsNCnsN CiJpcCI6ICIxOTIuMC4yLjExIiwNCiJwcmVmaXgtbGVuZ3RoIjogMjQNCn0NCl0NCn0sDQoiaWV0 Zi1pcDppcHY2Ijogew0KImFkZHJlc3MiOiBbDQp7DQoiaXAiOiAiMjAwMTpkYjg6MDoyOjoxMSIs DQoicHJlZml4LWxlbmd0aCI6IDY0DQp9DQpdDQp9LA0KImlldGYtbmV0d29yay1pbnN0YW5jZTpi aW5kLW5ldHdvcmstaW5zdGFuY2UtbmFtZSI6ICJ2cmYtcmVkIg0KfSwNCg0KLVFpbg0K --_000_3BA052DB49A24E4CB6AC2CB72F7EFA72ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3100B8E6EB843F4DAB81624E3DCB4CA3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ dGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6U2ltU3Vu O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SGkgUWluLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+UWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPk1vbmRheSwgQXVndXN0IDUsIDIwMTkgYXQgMTA6MTEgQU08YnI+DQo8Yj5UbzogPC9iPiZx dW90O2RyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwuYWxsQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFm dC1pZXRmLXJ0Z3dnLW5pLW1vZGVsLmFsbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPlJv dXRpbmcgV0cgJmx0O3J0Z3dnQGlldGYub3JnJmd0OywgJnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1 b3Q7ICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtXYW5nbGVpbGVpIChET1BSQSBTU1Ap JnF1b3Q7ICZsdDt3YW5nbGVpbGVpQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PkFkZCBuZXR3b3JrIGluc3RhbmNlIG5hbWUgb24gaW50ZXJmYWNlLCBJUHY0LCBJUHY2PGJyPg0K PGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5SZXNlbnQtVG86IDwvYj4mbHQ7bGJlcmdlckBsYWJuLm5ldCZndDssIENocmlzdGlhbiBIb3Bw cyAmbHQ7Y2hvcHBzQGNob3Bwcy5vcmcmZ3Q7LCBBY2VlIExpbmRlbSAmbHQ7YWNlZUBjaXNjby5j b20mZ3Q7LCBEZWFuIEJvZ2Rhbm92aWMgJmx0O2l2YW5kZWFuQGdtYWlsLmNvbSZndDssICZsdDt4 dWZlbmdfbGl1QGphYmlsLmNvbSZndDssICZsdDtjaHJpc2Jvd2Vycy5pZXRmQGdtYWlsLmNvbSZn dDssIEplZmYgVGFudHN1cmEgJmx0O2plZmZ0YW50LmlldGZAZ21haWwuY29tJmd0OywgWWluZ3po ZW4gUXUgJmx0O3lpbmd6aGVuLmlldGZAZ21haWwuY29tJmd0OywNCiBBbGlhIEF0bGFzICZsdDth a2F0bGFzQGdtYWlsLmNvbSZndDssIE1hcnRpbiBWaWdvdXJldXggJmx0O21hcnRpbi52aWdvdXJl dXhAbm9raWEuY29tJmd0OywgRGVib3JhaCBCcnVuZ2FyZCAmbHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7 LCBBbHZhcm8gUmV0YW5hICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0OywgWWluZ3poZW4g UXUgJmx0O3lpbmd6aGVuLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8 L2I+TW9uZGF5LCBBdWd1c3QgNSwgMjAxOSBhdCAxMDoxMSBBTTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OlNpbVN1biI+SGksIGF1dGhvcnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9 IkVOIj5JbiBSRkM4NTI5LCB0aGUgYmluZC1uZXR3b3JrLWluc3RhbmNlLW5hbWUgbGVhZiBwcm92 aWRlcyB0aGUgYXNzb2NpYXRpb24gYmV0d2VlbiBhbiBpbnRlcmZhY2UgYW5kIGl0cyBhc3NvY2lh dGVkIE5JLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj5Ib3dldmVyIGl0 IGlzIG5vdCBjbGVhciB0byBtZSB3aHkgdGhlIHNhbWUgYXNzb2NpYXRpb24gYmV0d2VlbiBJcHY0 L0lwdjYgdHlwZSBhbmQgaXRzIGFzc29jaWF0aW9uIE5JPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iPlNob3VsZCBiZSBwcm92aWRlZCBhcyB3ZWxsPyBTZWUgbW9kZWwgc3Ry dWN0dXJlIHNuaXBwZXQgZGVmaW5lZCBpbiBSRkM4NTI5IGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7igJw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hbGlnbjpsZWZ0O3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6U2ltU3VuIj4mbmJzcDsmbmJzcDsgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRl cmZhY2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYWxpZ246bGVmdDtwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBi aW5kLW5pLW5hbWU/Jm5ic3A7Jm5ic3A7IC0mZ3Q7IC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3Jr LWluc3RhbmNlL25hbWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hbGlnbjpsZWZ0O3Bh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDsmbmJzcDsgYXVnbWVudCAvaWY6aW50 ZXJmYWNlcy9pZjppbnRlcmZhY2UvaXA6aXB2NDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4 dC1hbGlnbjpsZWZ0O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGJpbmQtbmktbmFtZT8mbmJzcDsmbmJzcDsgLSZndDsgL25l dHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWFsaWduOmxlZnQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNw OyZuYnNwOyBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9pcDppcHY2Ojwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6U2ltU3VuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGJpbmQtbmktbmFt ZT8mbmJzcDsmbmJzcDsgLSZndDsgL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2Uv bmFtZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTpTaW1TdW4iPuKAnDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+U28gdGhl IHF1ZXN0aW9uIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPkNhbiB3 ZSBhZGQgZGlmZmVyZW50IE5JIG5hbWUgZm9yIElQdjQvSVB2NiB0eXBlPyBJc248L3NwYW4+4oCZ PHNwYW4gbGFuZz0iRU4iPnQgSVB2NCB0eXBlIGFuZCBJUHY2IHR5cGUgYW5kIGludGVyZmFjZSBw b2ludGluZyB0byB0aGUgc2FtZSBOSSBuYW1lPzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIj5XaHkgSVB2NCB0eXBlIGFuZCBJUHY2IHR5cGUgaW4gSVAgZGF0YSBtb2RlbCBj YW4gbm90IGluaGVyaXQgdGhlIHNhbWUgTkkgbmFtZSBmcm9tIHRoZSBpbnRlcmZhY2UgbW9kZWwg c2luY2UgSVAgRGF0YSBtb2RlbCBpcyBhbiBleHRlbnNpb24gdG8gSW50ZXJmYWNlIERhdGEgTW9k ZWw/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhlIG1vZGVsIGFsbG93cyB0aGUgSVB2NC9JUHY2IGxldmVsIG9mIGdyYW51bGFyaXR5IGZvciBu ZXR3b3JrLWluc3RhbmNlIHNwZWNpZmljYXRpb24uIEhvd2V2ZXIsIG1hbnksIGlmIG5vdCBtb3N0 LCBpbXBsZW1lbnRhdGlvbnMgZG8gbm90LiBNeSBtZW1vcnkgaXMgaGF6eSBhcyB0byB3aGljaCBp bXBsZW1lbnRhdGlvbihzKSBzdXBwb3J0cyB0aGlzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGFua3MsPGJyPkFjZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5TdXBwb3NlIHdlIGNvbmZpZ3Vy ZSBpbnRlcmZhY2UgYW5kIGFzc29jaWF0ZWQgSVAgYWRkcmVzc2VzIGFuZCBhc3NpZ24gdGhpcyBp bnRlcmZhY2UgdG8gYSBOSSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+V2hpY2ggY29uZmlndXJhdGlvbiBzbmlw cGV0IGlzIGNvcnJlY3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPk9wdGlvbiBBOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj57 PGJyPg0KJnF1b3Q7bmFtZSZxdW90OzogJnF1b3Q7ZXRoMSZxdW90Oyw8YnI+DQomcXVvdDt0eXBl JnF1b3Q7OiAmcXVvdDtpYW5hLWlmLXR5cGU6ZXRoZXJuZXRDc21hY2QmcXVvdDssPGJyPg0KJnF1 b3Q7aWV0Zi1pcDppcHY0JnF1b3Q7OiB7PGJyPg0KJnF1b3Q7YWRkcmVzcyZxdW90OzogWzxicj4N Cns8YnI+DQomcXVvdDtpcCZxdW90OzogJnF1b3Q7MTkyLjAuMi4xMSZxdW90Oyw8YnI+DQomcXVv dDtwcmVmaXgtbGVuZ3RoJnF1b3Q7OiAyNDxicj4NCn08YnI+DQpdPGJyPg0KJnF1b3Q7aWV0Zi1u ZXR3b3JrLWluc3RhbmNlOmJpbmQtbmV0d29yay1pbnN0YW5jZS1uYW1lJnF1b3Q7OiAmcXVvdDt2 cmYtcmVkJnF1b3Q7PGJyPg0KfSw8YnI+DQomcXVvdDtpZXRmLWlwOmlwdjYmcXVvdDs6IHs8YnI+ DQomcXVvdDthZGRyZXNzJnF1b3Q7OiBbPGJyPg0Kezxicj4NCiZxdW90O2lwJnF1b3Q7OiAmcXVv dDsyMDAxOmRiODowOjI6OjExJnF1b3Q7LDxicj4NCiZxdW90O3ByZWZpeC1sZW5ndGgmcXVvdDs6 IDY0PGJyPg0KfTxicj4NCl08YnI+DQomcXVvdDtpZXRmLW5ldHdvcmstaW5zdGFuY2U6YmluZC1u ZXR3b3JrLWluc3RhbmNlLW5hbWUmcXVvdDs6ICZxdW90O3ZyZi1yZWQmcXVvdDs8YnI+DQp9LDxi cj4NCiZxdW90O2lldGYtbmV0d29yay1pbnN0YW5jZTpiaW5kLW5ldHdvcmstaW5zdGFuY2UtbmFt ZSZxdW90OzogJnF1b3Q7dnJmLXJlZCZxdW90Ozxicj4NCn0sPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPk9wdGlv biBCOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6U2ltU3VuIj57PGJyPg0KJnF1b3Q7bmFtZSZxdW90OzogJnF1b3Q7ZXRoMSZx dW90Oyw8YnI+DQomcXVvdDt0eXBlJnF1b3Q7OiAmcXVvdDtpYW5hLWlmLXR5cGU6ZXRoZXJuZXRD c21hY2QmcXVvdDssPGJyPg0KJnF1b3Q7aWV0Zi1pcDppcHY0JnF1b3Q7OiB7PGJyPg0KJnF1b3Q7 YWRkcmVzcyZxdW90OzogWzxicj4NCns8YnI+DQomcXVvdDtpcCZxdW90OzogJnF1b3Q7MTkyLjAu Mi4xMSZxdW90Oyw8YnI+DQomcXVvdDtwcmVmaXgtbGVuZ3RoJnF1b3Q7OiAyNDxicj4NCn08YnI+ DQpdPGJyPg0KfSw8YnI+DQomcXVvdDtpZXRmLWlwOmlwdjYmcXVvdDs6IHs8YnI+DQomcXVvdDth ZGRyZXNzJnF1b3Q7OiBbPGJyPg0Kezxicj4NCiZxdW90O2lwJnF1b3Q7OiAmcXVvdDsyMDAxOmRi ODowOjI6OjExJnF1b3Q7LDxicj4NCiZxdW90O3ByZWZpeC1sZW5ndGgmcXVvdDs6IDY0PGJyPg0K fTxicj4NCl08YnI+DQp9LDxicj4NCiZxdW90O2lldGYtbmV0d29yay1pbnN0YW5jZTpiaW5kLW5l dHdvcmstaW5zdGFuY2UtbmFtZSZxdW90OzogJnF1b3Q7dnJmLXJlZCZxdW90Ozxicj4NCn0sPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4tUWluPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3BA052DB49A24E4CB6AC2CB72F7EFA72ciscocom_-- From nobody Mon Aug 5 10:52:08 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9F120253 for ; Mon, 5 Aug 2019 10:52:07 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hPh9Y2CD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=f/kNBLWt 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 MNufsj9Dly_X for ; Mon, 5 Aug 2019 10:52:04 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5C5120256 for ; Mon, 5 Aug 2019 10:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7644; q=dns/txt; s=iport; t=1565027524; x=1566237124; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=M0Ng8u/5ccgHVdsRMIW7xdcPEmeBXjLHoIDzih6fTJM=; b=hPh9Y2CDUpxT8h06sA9cJnCeaMPqf4wYA2dCB/qqb/G/QDUZnG3E2ftg LLMptiyFQRKS4VeS2/0gimNKyAugJYoXygWL0OgvvovSGiNyqzmzej8Hx nDCHgMDF7Ph3Kbk2t6u82RDu2FiE1L+3b/KMRJATXwYgUDrNUj3iZ8GY4 I=; IronPort-PHdr: =?us-ascii?q?9a23=3A1FAfdBLM2QqbyVn1K9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAABwa0hd/5tdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUQkLANtVSAECyqEHoNHA4RShltMgg+WAIFZgS6BJANUCQE?= =?us-ascii?q?BAQwBARgNCAIBAYN6RQIXglgjNAkOAQMBAQQBAQIBBm2FHgyFSgEBAQEDAQE?= =?us-ascii?q?QCwYRDAEBLAwLBAIBCBEEAQEDAiYCAgIlCxUICAIEARIigwABgWoDHQECDKB?= =?us-ascii?q?7AoE4iGBxgTKCegEBBYEzAYNWGIITAwaBDCgBi2IXgX+BEScfgU5+PoJhAQG?= =?us-ascii?q?BeIJ0MoImjC8zA4IknBsJAoIbhlyNQhuCL4csihmENYxlYodYkBgCBAIEBQI?= =?us-ascii?q?OAQEFgVA4gVhwFTsqAYJBgkIJGoNOhRSFPgFygSmNEwEB?= X-IronPort-AV: E=Sophos;i="5.64,350,1559520000"; d="scan'208";a="305135955" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 17:52:03 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x75Hq2nM019201 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 17:52:03 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 12:52:01 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 12:52:00 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 12:52:00 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=baE4whUVwTzvONNleL78Q+Oa4CP496BJtJ26nOWa7z9KQDuzOQiRZgLikcwLRLRxwiDuB8oWrKPZl+AFS7MkqUnj5M5FmI3uHJn0E9cXj3Wc1URydIDemigpaF69KwT5/TL+/QDOwhwWBTNatz3PwRjEeIqcZFrEQzks1ZbD1KJ2UeBsGn2XNJMOvoLyFhcgxeSeVqXsAMGvINSXMSUUnNg58Rs6HTwAXZxPhBmYg4Ovv5L8w/iKB8MzGNpF2OaSey7tktXAVSKksTZgtN91SN0OPY1wmy99ZJ8toNWcpbcNOfbDHk3COTzdxPd3e36ZxINV3UrrYtKEswq+IY4bgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0Ng8u/5ccgHVdsRMIW7xdcPEmeBXjLHoIDzih6fTJM=; b=hP36xy3UQNeyp6WF38Vrw1YxhW9vDI2jrPtmJtDpV9ijXyFKxWMMXlZm6Z1KOfzwsmzH+63aRPp7aGs0h+zQQ5GzWlxGduxk3c+L4EKSI3MEZ9aNb6D2RBf0TE0zmkFOYMWrCA5O6InPTYGf0UVn/G1jZxdboIl/o4eKMTGUpHAkKgMT3gVkCoHElHY3awnVMzmRC+K4ml5Qlbd53DyGIVdqNdInZpdjqHs1hdkG0H/NPEItpX/p4jP8ixEyZLVMTf5m5HbEPrwtwHxVV1V4t+rLJe3JeAibkMl3hkN4VTf9yQhWSnCkFNxHf904U4STMWF2B42dF7mgse1DqCuN0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0Ng8u/5ccgHVdsRMIW7xdcPEmeBXjLHoIDzih6fTJM=; b=f/kNBLWt8jxhj2r+q3V4sAJOBAOild2gwSDo9YAHRovHZ9dWA5Ag/mK9augLHWz7yQXvbxPU/FoA2kFvRStE332TC9t/qenuXham/G9uZlT3SjU/RuyrrrQNhFo6VByYiDhMxLXvtEge8dHIDc3NnMHkH++zaDbpWX4l8DtmIik= Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4222.namprd11.prod.outlook.com (52.135.36.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 17:51:59 +0000 Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0%3]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 17:51:59 +0000 From: "Acee Lindem (acee)" To: "Rob Wilton (rwilton)" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsfThrxX+ZGkSGn6fln7HbLKbDkLwAgAtsl4CAHb8qgA== Date: Mon, 5 Aug 2019 17:51:59 +0000 Message-ID: <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <80F2E6D2-8F6A-4EF4-9838-45AC48BE84E5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [2001:420:c0c4:1001::2f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29eace6d-62a4-42ed-69bf-08d719cd9d88 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4222; x-ms-traffictypediagnostic: MN2PR11MB4222: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(199004)(189003)(51914003)(13464003)(51444003)(6486002)(81156014)(6436002)(6246003)(33656002)(229853002)(86362001)(53936002)(8676002)(561944003)(6512007)(6306002)(8936002)(446003)(476003)(46003)(81166006)(2616005)(966005)(186003)(11346002)(478600001)(486006)(305945005)(102836004)(5024004)(36756003)(14444005)(71200400001)(71190400001)(256004)(76176011)(76116006)(7736002)(2501003)(14454004)(66946007)(25786009)(66446008)(66556008)(5660300002)(64756008)(66476007)(99286004)(6116002)(110136005)(53546011)(6506007)(316002)(2906002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4222; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uhmRJwLsmejc73P6ESMhH0S5ul2DMAUSizMZYkWOw41gojfaKAsOfGj0AMUGGTXbu00ccqL/LR/RIQIUSVJVdpE3tERmq8kcOpMHoCkDcZT10KLewJ0UM23g4oyoqZ8Aq3D4WivEszr81Dj5Y+rjossxen5o/gpwFdeEN0SHwUYDpTunbVTI88PbIRU0Mr/suCgk+TK6eiijV0/ZhEF4GLE9eu5hraHfMzBcU+VFehn+2wCUhnkg07wKmsYzj/dGUzp+e0j7nDxI4rYb+vPVxGmVCANFQ1bgc+jqIBj7hj0inhtbNJ3DSm1uUQuOZ7UkcG0dXB2dZwwZ0zZnkw582dfEBHsd/ZRvQlab3DWJHPKAbUrxAsPyWehgXKgKM8wq5DvWuw6lC2BADhtYkP0R76Y51umZ0ozMsXmVBUA3G+0= Content-Type: text/plain; charset="utf-8" Content-ID: <94D7250DF22EDC469053DFF4B82D7C9A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 29eace6d-62a4-42ed-69bf-08d719cd9d88 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 17:51:59.6698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: acee@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4222 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 17:52:07 -0000 SGkgUm9iLCANCkl0IHNlZW1zIHRoZXNlIGNvdW50ZXJzIGhhdmUgYmVlbiBjb25zaWRlcmVkIGF0 IGdyZWF0IGxlbmd0aC4gSSBhZ3JlZSB3ZSBzaG91bGQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIG1v ZGVsIGFzIGl0IGlzIHRvZGF5Lg0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiA3LzE3LzE5LCAxMToz NiBBTSwgIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0K DQogICAgSGkgQWNlZSwNCiAgICANCiAgICBUaGFua3MgZm9yIHRoZSByZXZpZXcsIGFuZCBhcG9s b2dpZXMgZm9yIHRoZSBkZWxheWVkIHJlcGx5Lg0KICAgIA0KICAgIFJlZ2FyZGluZyB5b3VyIHN0 YXRzIHF1ZXN0aW9uLCB0aGVyZSB3YXMgc29tZSBlZmZvcnQgdG8gaGFuZGxlIHRoaXMgYXMgcGFy dCBvZiBkZWZpbmluZyB0aGUgRXRoZXJuZXQgaW50ZXJmYWNlIFlBTkcgKElFRUUgODAyLjMuMi0y MDE5KSAoaHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy90cmVlL21hc3Rlci9zdGFu ZGFyZC9pZWVlL3B1Ymxpc2hlZC84MDIuMykgdGhhdCBJIHdhcyBpbnZvbHZlZCBpbiB0aGUgZWFy bGllciBwYXJ0cyBvZi4gIFBsZWFzZSBzZWUgdGhlIGF0dGFjaGVkIFhMUyB0aGF0IHdhcyBteSBl YXJsaWVyIGVmZm9ydCB0byByYXRpb25hbGl6ZSB0aGUgZGlmZmVyZW50IGV0aGVybmV0IGludGVy ZmFjZXMgY291bnRlcnMgYmV0d2VlbiBSRkMgNzIyMywgRXRoZXJuZXQgWUFORywgRXRoZXJsaWtl IE1JQiwgUk1PTiBNSUJzLCBhbmQgdGhlIGNvdW50ZXJzIGV4cG9zZWQgaW4gdGhlIDgwMi4zIGNs YXVzZSAzMCBtYW5hZ2VtZW50IEFQSS4NCiAgICANCiAgICBGb3IgcGh5c2ljYWwgRXRoZXJuZXQg aW50ZXJmYWNlcyAoYW5kIGFueXRoaW5nIHRoYXQgbG9va3MgdmVyeSBzaW1pbGFyIHRvIGEgcGh5 c2ljYWwgRXRoZXJuZXQgaW50ZXJmYWNlKSB0aGVuIEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgYmUg d2VsbCBjb3ZlcmVkIGJ5IHRoZSBjb21iaW5hdGlvbiBvZiB3aGF0IGlzIGluIGlldGYtaW50ZXJm YWNlcywgYW5kIElFRUUgODAyLjMuMi4NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBzb21lIGNv dW50ZXJzIHRoYXQgYXBwbHkgdG8gYWxsIEV0aGVybmV0LWxpa2UgaW50ZXJmYWNlcyAocmVhbGx5 IGFueXRoaW5nIHVzaW5nIEV0aGVybmV0IGZyYW1pbmcsIGJ1dCBub3QgYW4gRXRoZXJuZXQgcGh5 c2ljYWwgbGF5ZXIpLiAgVGhlIG9ubHkgY291bnRlciBjdXJyZW50bHkgZGVmaW5lZCBpbiB0aGlz IGNhdGVnb3J5IGlzIGluLWRyb3AtdW5rbm93bi1kZXN0LW1hYy1wa3RzIGluIGlldGYtaW50ZXJm YWNlcy1ldGhlcm5ldC1saWtlLiAgQXJndWFibHkgd2UgY291bGQgYWxzbyBhZGQgYSBkcm9wIGNv dW50ZXIgZm9yIGZyYW1lcyB0aGF0IGNvdWxkIG5vdCBiZSBkZW11eGVkIHRvIGEgc3ViLWludGVy ZmFjZSBiZWNhdXNlIGl0IGRpZG4ndCBtYXRjaCBhbnkgb2YgdGhlIHN1Yi1pbnRlcmZhY2UgbWF0 Y2ggZXhwcmVzc2lvbnMuDQogICAgDQogICAgVGhlcmUgd2FzIG9uZSBzZXQgb2YgY291bnRlcnMg dGhhdCA4MDIuMy4yIGRpZG4ndCB3YW50IHRvIGluY2x1ZGUgaW4gdGhlaXIgWUFORyBtb2R1bGUg d2hpY2ggcmVsYXRlZCB0byB0aGUgaGlzdG9ncmFtIGZyYW1lIHN0YXRpc3RpY3MuICBFLmcuIGNv dW50ZXJzIGxpa2UgdGhlIGZvbGxvd2luZyAodGFrZW4gZnJvbSBJT1MgWFIpOg0KICAgIA0KICAg ICAgICBJbnB1dCBwa3RzIDY1LTEyNyBieXRlcyAgICAgPSAwDQogICAgICAgIElucHV0IHBrdHMg MTI4LTI1NSBieXRlcyAgICA9IDANCiAgICAgICAgSW5wdXQgcGt0cyAyNTYtNTExIGJ5dGVzICAg ID0gMA0KICAgICAgICBJbnB1dCBwa3RzIDUxMi0xMDIzIGJ5dGVzICAgPSAwDQogICAgICAgIElu cHV0IHBrdHMgMTAyNC0xNTE4IGJ5dGVzICA9IDANCiAgICAgICAgSW5wdXQgcGt0cyAxNTE5LU1h eCBieXRlcyAgID0gMA0KICAgIA0KICAgICAgICBPdXRwdXQgcGt0cyA2NS0xMjcgYnl0ZXMgICAg PSAwDQogICAgICAgIE91dHB1dCBwa3RzIDEyOC0yNTUgYnl0ZXMgICA9IDANCiAgICAgICAgT3V0 cHV0IHBrdHMgMjU2LTUxMSBieXRlcyAgID0gMA0KICAgICAgICBPdXRwdXQgcGt0cyA1MTItMTAy MyBieXRlcyAgPSAwDQogICAgICAgIE91dHB1dCBwa3RzIDEwMjQtMTUxOCBieXRlcyA9IDANCiAg ICAgICAgT3V0cHV0IHBrdHMgMTUxOS1NYXggYnl0ZXMgID0gMA0KICAgIA0KICAgIFRoZSA4MDIu MyBZQU5HIFdHIGhhZCB0d28gaXNzdWVzIHdpdGggaW5jbHVkaW5nIGNvdW50ZXJzIGxpa2UgdGhl c2U6DQogICAgKDEpIFRoZXkgZGlkbid0IHJlYWxseSB3YW50IHRvIGRlZmluZSBoaXN0b2dyYW0g Y291bnRlciB2YWx1ZXMgZm9yIE1UVXMgdGhhdCBhcmUgYWJvdmUgdGhlIG9mZmljaWFsbHkgc2Fu Y3Rpb25lZCBNVFUgb2YgMTUxNC8xNTE4IGluIHRoZSBFdGhlcm5ldCBzcGVjaWZpY2F0aW9uLCBl dmVuIHRob3VnaCBhIGxvdCBvZiBoYXJkd2FyZSBzdXBwb3J0cyB1cCB0byA5SysuDQogICAgKDIp IFRoZSBidWNrZXQgcmFuZ2VzLCBhdCBsZWFzdCBvbmNlIHlvdSBnZXQgcGFzdCB0aGUgIjUxMi0x MDIzIiBidWNrZXQsIHNlZW0gdG8gc29tZXdoYXQgdmFyeSBieSBBU0lDIHZlbmRvci4NCiAgICAo MykgSUVFRSA4MDIuMyBoYXMgYSB3ZWxsIGRlZmluZWQgaW50ZXJuYWwgbWFuYWdlbWVudCBBUEkg KDgwMi4zIGNsYXVzZSAzMCksIGFuZCB0aGVzZSBoaXN0b2dyYW0gY291bnRlcnMgYXJlIG5vdCBj dXJyZW50bHkgZGVmaW5lZCBhcyBwYXJ0IG9mIHRoYXQgaW50ZXJuYWwgbWFuYWdlbWVudCBBUEku ICBFeHRlbmRpbmcgdGhlIGludGVybmFsIDgwMi4zIG1hbmFnZW1lbnQgQVBJIHNlZW1zIHRyaWNr eSBkdWUgdG8gcG9pbnQgKDEpIGFuZCAoMikgYWJvdmUuDQogICAgDQogICAgVGhlcmUgd2FzIGEg c3VnZ2VzdGlvbiBpbiB0aGUgODAyLjMgZGlzY3Vzc2lvbnMgdGhhdCB0aGVzZSBjb3VudGVycyBj b3VsZCBiZSBkZWZpbmVkIGluIGFuIElFVEYgWUFORyBtb2R1bGUgKHNraXJ0aW5nIHRoZSBJRUVF IGNvbmNlcm5zIGFib3V0IG1heGltdW0gTVRVcykuICBUaGUgcHJvcG9zYWwgd2FzIHRvIGFsbG93 IHRoZSBvcGVyYXRpb25hbCBkYXRhIHRvIHJldHVybiBhIGxpc3Qgb2YgYnVja2V0IGVudHJpZXMs IHdoZXJlIGVhY2ggZW50cnkgZGVmaW5lcyB0aGUgaW5jbHVzaXZlIHJhbmdlIG9mIHRoZSBidWNr ZXQsIGFuZCBhIGNvdW50IG9mIHRoZSBwa3RzIHRoYXQgbWF0Y2hlZCB0aGUgYnVja2V0IHJhbmdl IChpbiBlaXRoZXIgdGhlIGluZ3Jlc3Mgb3IgZWdyZXNzIGRpcmVjdGlvbikuICBUaGlzIGxpc3Qg d291bGQgc2l0IGFsb25nc2lkZSBhIFJFQ09NTUVOREFUSU9OIG9mIHdoYXQgYnVja2V0IHNpemVz IHRvIHVzZSwgYmFzaWNhbGx5IGRvdWJsaW5nIGVhY2ggdGltZSB1cCB0byB0aGUgTVRVLCB3aXRo IHNvbWUgY29uc2lkZXJhdGlvbiBhcm91bmQgdGhlIDE1MTQvMTUxOC8xNTIyIGJvdW5kYXJ5LCBi dXQgYWxsb3dpbmcgZnJlZWRvbSBmb3IgYSBkZXZpY2UgdG8gYWNjdXJhdGVseSByZXR1cm4gdGhl IGhpc3RvZ3JhbSByYW5nZXMgYWN0dWFsbHkgc3VwcG9ydGVkIGJ5IHRoZSBoYXJkd2FyZS4NCiAg ICANCiAgICBIb3dldmVyLCBJJ20gbm90IHN1cmUgaXQgaXMgd29ydGggZGVsYXlpbmcgdGhlc2Ug ZHJhZnRzIHRvIGFkZCB0aGVzZSBjb3VudGVycyBpbiBub3csIHBhcnRpY3VsYXJseSBiZWNhdXNl IHRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgb24gdGhlbS4gIFBvc3NpYmx5IGJlc3QgZG9uZSBhcyBm dXR1cmUgd29yaz8gIERvIHlvdSwgb3IgYW55b25lIGVsc2UgaW4gdGhlIFdHIGhhdmUgYW4gb3Bp bmlvbiBvbiB0aGlzPw0KICAgIA0KICAgIFRoYW5rcywNCiAgICBSb2INCiAgICANCiAgICANCiAg ICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IG5ldG1vZCA8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNCiAg ICBTZW50OiAxMCBKdWx5IDIwMTkgMTQ6MDkNCiAgICBUbzogS2VudCBXYXRzZW4gPGtlbnQraWV0 ZkB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6IFtuZXRtb2Rd IFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KICAgIA0K ICAgIEkgaGF2ZSByZXZpZXdlZCB0aGUgc3ViamVjdCBkb2N1bWVudCBhbmQgc3VwcG9ydCBwdWJs aWNhdGlvbi4gSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudDoNCiAgICANCiAgICAgIFBlcmhh cHMgaWV0Zi1pbnRlcmZhY2UtZXRoZXJuZXQtbGlrZSBtb2R1bGUgZXRobGlrZTpldGhlcm5ldC1s aWtlL2V0aGxpa2U6c3RhdGlzdGljcyBjb3VsZCBpbmNsdWRlIGEgc3Vic2V0IG9mIHRoZSBjb3Vu dGVycyBmcm9tIFJGQyAzNjM1LiBJIHNheSBhIHN1YnNldCBzaW5jZSBzb21lIG9mIHRoZXNlIGNv dW50ZXJzIGFyZSBhIGJpdCBhcmNoYWljIGdpdmVuIHRoZSBzdGF0ZSBvZiB0aGUgdGVjaG5vbG9n eSBhbmQganVkZ2VtZW50IHNob3VsZCBiZSBhcHBsaWVkIG9uIHdoaWNoIHRvIGluY2x1ZGUuDQog ICAgDQogICAgICBUaGFua3MsDQogICAgQWNlZSANCiAgICANCiAgICBPbiA3LzkvMTksIDg6MTYg UE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCiAgICANCiAg ICAgICAgQWxsLA0KICAgICAgICANCiAgICAgICAgVGhpcyBzdGFydHMgYSB0d2VsdmUtZGF5IHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5n LTA3DQogICAgICAgIA0KICAgICAgICBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBv biBKdWx5IDIxICh0aGUgZGF5IGJlZm9yZSB0aGUgTkVUTU9EIDEwNSBzZXNzaW9ucykuICBQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdC4N CiAgICAgICAgDQogICAgICAgIFBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIs IGFyZSB3ZWxjb21lISAgVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1 dGhvcnMuDQogICAgICAgIA0KICAgICAgICBUaGFuayB5b3UsDQogICAgICAgIE5FVE1PRCBDaGFp cnMNCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICAgICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgICAgICBuZXRtb2RAaWV0Zi5vcmcN CiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAg ICAgICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQog ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K From nobody Mon Aug 5 12:30:57 2019 Return-Path: <0100016c63432c70-5f5c500b-ed4b-407a-ac9c-dc3631a9bac2-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071291200C5; Mon, 5 Aug 2019 12:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 eL67Uu8uHxjl; Mon, 5 Aug 2019 12:30:47 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1744120048; Mon, 5 Aug 2019 12:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565033442; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MIa1rijkblopES+qh5UhSADGDShf7ppBDXXBiaI63hc=; b=G5i8PVpqxMOR0OI+T6098Hcad3PxSH3vDk/j1guLnQ7vRbeQJyBkq/EBq8e4ndhM VQjt61FWnTiIqvpxxLndgODEYM3RqXGfJk9a2UjrWfoHqEqQLDjDCnPQdIkFO4JxcVU 45p5C7qr1P5MuUFyGBci00yup0lFAj+UCyrOoDmo= From: Kent Watsen Message-ID: <0100016c63432c70-5f5c500b-ed4b-407a-ac9c-dc3631a9bac2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 5 Aug 2019 19:30:42 +0000 In-Reply-To: <156477661481.21003.10781222745111642469@ietfa.amsl.com> Cc: secdir@ietf.org, ietf@ietf.org, "netmod@ietf.org" , draft-ietf-netmod-artwork-folding.all@ietf.org To: Robert Sparks References: <156477661481.21003.10781222745111642469@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 19:30:49 -0000 --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Robert, I'm glad that you reviewed this draft, as I envision backend Datatracker = integration may be desired (as we discussed in the Code Sprint before). > On Aug 2, 2019, at 4:10 PM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Has Nits >=20 > Reviewer: Robert Sparks > Review result: Has Nits >=20 > 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. >=20 > This document introduces no new security concerns for the Internet. > It aims to establish conventions for wrapping long lines in source = code=20 > sections of RFCs. >=20 > It does have shell scripts embedded in the Appendix. I see no obvious > security issues with those scripts. >=20 > I strongly suggest this document proceed as Informational and not BCP.=20= > It's fine if some documents adopt the convention. Other conventions = may > work better for other groups. See, for example, the = convention > described in section 2.1 of RFC4475. (No automated wrap/unwrap scripts > have been written for that convention to my knowledge, but it would > not be hard to create some.) The BCP status was recommended by the WG. I'll defer my own opinion at = this time. Regarding , I think that you're actually making a case for = why this should be a BCP ;) FWIW, the NETMOD WG (and it's sister WG, NETCONF) have a long history of = using XML-based inclusions in RFCs. > Nits:=20 >=20 > In your headers, you anticipate receiving a two digit BCP number. At = the > moment, the next available BCP number has three digits. (We are well > into the 200s). You have header lengths that would need to be = adjusted. Good catch. this has been fixed in my local copy. > In 7.2.1 paragraph 5, I think you're saying to fail if any lines in = the > input document already end with a \. I think you mean to say any lines > that you are considering wrapping. If I'm correct, the clarification = may > also need to be applied in other places where you say "the text = content" Updated. My local copy now reads: Scan the text content to ensure no existing lines already end with = a backslash ('\') character, as this could lead to an ambiguous = result. If such a line is found, and its width is less than the desired = maximum, then it SHOULD be flagged for forced folding (folding even though unnecessary). If the folding implementation doesn't support forced foldings, it MUST exit. The symmetric text in Section 8.2.1 already followed this form. Thanks, Kent // as co-author --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Robert,

I'm glad = that you reviewed this draft, as I envision backend Datatracker = integration may be desired (as we discussed in the Code Sprint = before).


On Aug = 2, 2019, at 4:10 PM, Robert Sparks via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Robert Sparks
Review result: Has = Nits

Reviewer: Robert Sparks
Review result: Has Nits

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.

This document introduces no new security concerns for the = Internet.
It aims to establish conventions for wrapping = long lines in source code
sections of RFCs.

It does have shell scripts embedded in the = Appendix. I see no obvious
security issues with those = scripts.

I strongly suggest this document = proceed as Informational and not BCP.
It's fine if some = documents adopt the convention. Other conventions may
work = better for other groups. See, for example, the <allOneLine> = convention
described in section 2.1 of RFC4475. (No = automated wrap/unwrap scripts
have been written for that = convention to my knowledge, but it would
not be hard to = create some.)

The BCP status was recommended by the WG. =  I'll defer my own opinion at this time.

Regarding <allOneLine>, I think that you're = actually making a case for why this should be a BCP   =  ;)

FWIW, the NETMOD WG (and = it's sister WG, NETCONF) have a long history of using XML-based = inclusions in RFCs.




Nits:

In your headers, you anticipate receiving a two digit BCP = number. At the
moment, the next available BCP number has = three digits. (We are well
into the 200s). You have header = lengths that would need to be adjusted.

Good = catch. this has been fixed in my local copy.


In = 7.2.1 paragraph 5, I think you're saying to fail if any lines in the
input document already end with a \. I think you mean to say = any lines
that you are considering wrapping. If I'm = correct, the clarification may
also need to be applied in = other places where you say "the text content"

Updated.  My = local copy now reads:

    =   Scan the text content to ensure no existing lines already end = with a
      backslash ('\') character, as this = could lead to an ambiguous result.
    =   If such a line is found, and its width is less than the = desired maximum,
      then it SHOULD = be flagged for forced folding (folding even though
  =     unnecessary). If the folding implementation doesn't = support forced
      foldings, it MUST = exit.</t>

The symmetric text in = Section 8.2.1 already followed this form.



Thanks,
Kent // as = co-author




= --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A-- From nobody Tue Aug 6 08:10:33 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C99120321 for ; Tue, 6 Aug 2019 08:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVG_VsFspyzn for ; Tue, 6 Aug 2019 08:10:29 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 26A2E1200B9 for ; Tue, 6 Aug 2019 08:10:29 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id p197so61407640lfa.2 for ; Tue, 06 Aug 2019 08:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cYCx5v/0Z0ZkBOzEuLf07FY/a7zOgnrt3JtuddTZWLc=; b=sgMerl8RSDUpqOLgT0BhL2WsgccDC7C3gAPLbkuDFQcnmpmZaxJPwmCGeYdP4FEFk4 PXvBEN3U8NqvtENgyVH8QQbg5o7njWr/Jy+LRTCMXIdmT4qevzXb4JkcX3Tol+bdqQYV 1eSDNml9BsHYD2xRF8au2sJpR1ev0GoQkp5n8/VQaT79y78I8oKh7JEjlyRnbsQ+oCiF Ld3BTvDz/EOikLc+9mDs90G4hSqkhBNOj22CAThaGWvgszPOE9tibtGtQMZQLrwqbRYf 32smSch235WuKonFB70/2uqgK4szv9fngWTl0WHJX8g8nDXYy50+0jfarCwPLRCD1Pul Kaug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cYCx5v/0Z0ZkBOzEuLf07FY/a7zOgnrt3JtuddTZWLc=; b=N+mMJtu6h+0yzrLbGoaEiEEB5tlktrTnh60QCWBx7vbgQE8agOtV8XsHWxSdFDzlug lN9v3oQtVtjlp+qZPt2Lw7ZhdVYlzDOpfmjDzjMWm/4ChHWraJZqdLkJpnul7f9QgRZx fQJvA46xNHTKX/0q2uRRwb/oUBIuZJIf+Xxx94Hf5Ga/Fm/0zdPTZaLGOUrI0VynN0vE /T6i4J4lT+qGztycBQ8TTALCwEtZpIEzYCkZpzr6HXlGWhWZvY39bdqz0YuEolq/0ssF n/V/8PKQRGjyHLYRvyP5QVmKoEaGjjxgfsgjSeK84OmjD1nDbQ5d1XQgOEYEWszt8Ea3 Dg6g== X-Gm-Message-State: APjAAAWUQJQZQUl03oEpFoScKX+6L2m4sybnFbnwXC0CZN+R1FykKdW2 nvH6aEgR58vsVgQl2Zy5ItvRgV7yKcZjldg3GMf12rp6 X-Google-Smtp-Source: APXvYqyAJkvpTiBOXCIJSBP6KVknjBV85oGJ2RQS1wvP9leUeTUegVIzBWcw+rg0Z9W0Zy0Il8VTP2sRrzZt50sgvjg= X-Received: by 2002:a19:f703:: with SMTP id z3mr2767410lfe.171.1565104227277; Tue, 06 Aug 2019 08:10:27 -0700 (PDT) MIME-Version: 1.0 References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> In-Reply-To: <87o914gcxn.fsf@nic.cz> From: Andy Bierman Date: Tue, 6 Aug 2019 08:10:15 -0700 Message-ID: To: "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Content-Type: multipart/alternative; boundary="00000000000080f310058f743985" Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:10:32 -0000 --00000000000080f310058f743985 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka wrote: > "Fengchong (frank)" writes: > > > Hi all, > > > > I encounter a question about 'when', when I implement yang model > associated when condition. > > > > Yang model: > > > > leaf password-type { > > type enumeration { > > enum null; > > enum simple; > > enum cipher; > > } > > } > > > > leaf password-text { > > type string; > > when "../password-type != null"; > > } > > > > I config these two leafs as below: > > simple > > 123456 > > > > And I changed password-type to null, I get the config like below: > > null > > > > And then, I reconfig the password-type to simple, what data should be > returned? > > > > Is > > simple > > According to RFC 7950, sec. 8.2, the server deleted "password-text" after > you changed "password-type" to null but the original value isn't recovered > after you change the type back. > > This server behaviour means that a typo or similar trivial error may have > catastrophic consequences such as auto-deletion of entire configuration > subtrees. That's why our RESTCONF implementation (jetconf) does something > else: it won't permit you to change "password-type" to null as long as the > "password-text" exists. > > It seems odd to optimize the server for client mistakes. It is far more likely (99 to 1?) that the client knows what it is doing and expects the standard to be followed. Consider the burden on the client deleting all the "false-when" nodes manually. This is also inconsistent with the standard behavior for choice-stmt (new case deletes the old case automatically). Lada > > Andy > > > > Or > > > > simple > > 123456 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000080f310058f743985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 5, 2019 at 2:49 AM Ladisl= av Lhotka <lhotka@nic.cz> wrote:=
"Fengchong= (frank)" <frank.fengchong@huawei.com> writes:

> Hi all,
>
> I encounter a question about 'when', when I implement yang mod= el associated when condition.
>
> Yang model:
>
> leaf password-type {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enum null;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enum simple;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enum cipher;
>=C2=A0 =C2=A0 }
> }
>
> leaf password-text {
> type string;
> when "../password-type !=3D null";
> }
>
> I config these two leafs as below:
> <password-type>simple</password-type>
> <password-text>123456</password-text>
>
> And I changed password-type to null, I get the config like below:
> <password-type>null</password-type>
>
> And then, I reconfig the password-type to simple, what data should be = returned?
>
> Is
>=C2=A0 =C2=A0<password-type>simple</password-type>

According to RFC 7950, sec. 8.2, the server deleted "password-text&quo= t; after you changed "password-type" to null but the original val= ue isn't recovered after you change the type back.

This server behaviour means that a typo or similar trivial error may have c= atastrophic consequences such as auto-deletion of entire configuration subt= rees. That's why our RESTCONF implementation (jetconf) does something e= lse: it won't permit you to change "password-type" to null as= long as the "password-text" exists.


It seems odd to optimize the server fo= r client mistakes.
It is far more likely (99 to 1?) that the clie= nt knows what it is doing and expects
the standard to be followed= .=C2=A0 Consider the burden on the client deleting all
the "= false-when" nodes manually.=C2=A0 This is also inconsistent with the s= tandard
behavior for choice-stmt (new case deletes the old case a= utomatically).

Lada


Andy
=C2=A0
>
> Or
>
>=C2=A0 =C2=A0<password-type>simple</password-type>
>=C2=A0 =C2=A0<password-text>123456</password-type>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000080f310058f743985-- From nobody Wed Aug 7 00:38:58 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E011A120285 for ; Wed, 7 Aug 2019 00:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 utlQCIcCuo3A for ; Wed, 7 Aug 2019 00:38:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE412024C for ; Wed, 7 Aug 2019 00:38:54 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id BDBDD182048C; Wed, 7 Aug 2019 09:41:09 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BC37C1820043; Wed, 7 Aug 2019 09:40:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "Fengchong \(frank\)" , "netmod\@ietf.org" , "Zhangxiaoping \(C\)" , liuzhiying In-Reply-To: References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> Mail-Followup-To: Andy Bierman , "Fengchong \(frank\)" , "netmod\@ietf.org" , "Zhangxiaoping \(C\)" , liuzhiying Date: Wed, 07 Aug 2019 09:38:32 +0200 Message-ID: <8736ide87b.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 07:38:57 -0000 Andy Bierman writes: > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka wrote: > >> "Fengchong (frank)" writes: >> >> > Hi all, >> > >> > I encounter a question about 'when', when I implement yang model >> associated when condition. >> > >> > Yang model: >> > >> > leaf password-type { >> > type enumeration { >> > enum null; >> > enum simple; >> > enum cipher; >> > } >> > } >> > >> > leaf password-text { >> > type string; >> > when "../password-type != null"; >> > } >> > >> > I config these two leafs as below: >> > simple >> > 123456 >> > >> > And I changed password-type to null, I get the config like below: >> > null >> > >> > And then, I reconfig the password-type to simple, what data should be >> returned? >> > >> > Is >> > simple >> >> According to RFC 7950, sec. 8.2, the server deleted "password-text" after >> you changed "password-type" to null but the original value isn't recovered >> after you change the type back. >> >> This server behaviour means that a typo or similar trivial error may have >> catastrophic consequences such as auto-deletion of entire configuration >> subtrees. That's why our RESTCONF implementation (jetconf) does something >> else: it won't permit you to change "password-type" to null as long as the >> "password-text" exists. >> >> > It seems odd to optimize the server for client mistakes. This is just the principle of least embarrassment. The problem is that it is not indicated in the data model that deleting or changing something may have far-reaching consequences. > It is far more likely (99 to 1?) that the client knows what it is > doing and expects the standard to be followed. Consider the burden > on the client deleting all the "false-when" nodes manually. This is If it is a significant burden, then it's also quite likely that the client may not be completely aware of what's going to be auto-deleted. > also inconsistent with the standard behavior for choice-stmt (new > case deletes the old case automatically). This is quite different in that the impact is localized: one can easily see that a given leaf is a case in a choice so that it cannot exist along with another case. Lada > > Lada >> >> > Andy > > >> > >> > Or >> > >> > simple >> > 123456 >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Aug 7 02:08:00 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409D112030A for ; Wed, 7 Aug 2019 02:07: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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lino65ei; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BI5nAB/q 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 yuaWZGG8AeRn for ; Wed, 7 Aug 2019 02:07:54 -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 82270120303 for ; Wed, 7 Aug 2019 02:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5412; q=dns/txt; s=iport; t=1565168874; x=1566378474; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UIHIK85VOtX/X6DXh1+LvBBWvfdS6f9sIAdDAvoqrvs=; b=lino65eiP87AtDkt7dbTQ+U40lsN+4LesoUVczsML5IRetFqlw9+oBA8 LsZ0Hn53cAO1ktHrWJnoEX4S2GeZ9mXzM4F1ZL2xOrT0PorfVCboybyUH IGj0gMR8Hi7ihoO3/utxWFwICzXsGSClSJSFPvLyimJNs45kZZy3Lol/6 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AjAYyQxyClK1slfnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQCjlEpd/4oNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgUQkLANtVSAECyoKh1sDizJMgg+XXYEugSQDVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGDekUCgj8jNgcOAQQBAQQBAQIBBm2FJwyFSgEBAQECAQEBECgGAQE?= =?us-ascii?q?sDAQHBAIBCBEEAQEBGAYQJwsdCAEBBAESCBqDAYFqAw4PAQIMnxkCgTiIYII?= =?us-ascii?q?jgnoBAQWBBwGEDhiCFAMGgTQBi2MXgUA/gVeCTD6CYQEBgSohGE2CboImeI4?= =?us-ascii?q?CnDYJAoIclD2CL5YCjU2BNJZAAgQCBAUCDgEBBYFXATCBWHAVO4JsgkKDcYU?= =?us-ascii?q?UhQgBNnKBKYspAiICB4EEAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="scan'208";a="611180844" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 09:07:27 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7797Rps018674 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 09:07:27 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 04:07:27 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 05:07:26 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 05:07:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HitXxeJlcq6YyoIuiBPi9E1N9O3/b3vYm09I2muh7pBQfw+cWocImW2Qj+NCr2HTmqhXMPHq3sGaxZ9Pj5yVixHOou4yk1u//iXqLjDhCmCtQhKZH6LICVESSrzePOyNRyn8clo0TSdRhymroEqMLbAjQhpGjoPIKXJosgsW90t94rttuTfKc7h2AcxOzJag18H+nqgyjYW9EyI7r7lmM3TPCmuXKeOWkiaz1UEmBktA7rlIt5QZQ9Jkk298KaE6ktk9A3EO6fpivzih9c3EAxOYpPn0Yv0IjJtxHn4xMbSt9Os0xm/DPlvwsSBn6kIMHoDN+JXTLRllSdmSQ//ocw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bN4pgmIM/vvD+1k6c1E1SfTOK6SioNJ483btCOuY3DE=; b=GPTYz1fFOeI0e6u1G23JvaWZu4hsPBlsviQXMS3aylndqGnQXmn5QqQP46fMfNjH9ra7QzwoEXQbohlCytHI3WIo+kxLw4tOEXJIEi2BuQokqc+7IYkW21Lv/0oBnekPvn0zG/68VELGL1N3iEsQqG3GXZ+xoAeQSL++30cny60Ep2FzPHvtty9ppPs8zoqQ6cQ+NMU+n+OB/xD2v60B7rBQagFMxx4bn8pTCF3ADpEAH2efQ0yaYpkDF4IuIeVexZTPzNz7KD+VwzKVex3bzE+4O67C7b8YaZC9tqOj20DmtKdEuVm8W3kbkUx38R5PTnGydAgVMYO80nF6ZaDj8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bN4pgmIM/vvD+1k6c1E1SfTOK6SioNJ483btCOuY3DE=; b=BI5nAB/qaqvdcAsR9ue10BqIxwsDofNv+L++fJTsgVDIh4c3rc+6ks1UPdlRFxzJgOrsCHDZMKvForp0hOXWIcwGJj6KuNnKtrb0pgEYguWgDjWzWGyPWjjyQnGHv9cpOgfJZxcruhafC3vDW77JdRjoO3Ihu5sO0VNla2btm7s= Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB3222.namprd11.prod.outlook.com (20.177.127.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Wed, 7 Aug 2019 09:07:24 +0000 Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428%4]) with mapi id 15.20.2136.018; Wed, 7 Aug 2019 09:07:24 +0000 From: "Rob Wilton (rwilton)" To: Ladislav Lhotka , Andy Bierman , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Thread-Topic: [netmod] a question about 'when' Thread-Index: AdVLPM5Xmpgaa94hSz6Z+hOvCeCLfwANi6kAAD2D/oAAIoPxAAABScmg Date: Wed, 7 Aug 2019 09:07:24 +0000 Message-ID: References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> In-Reply-To: <8736ide87b.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2046554-33ef-488d-4a01-08d71b16a9dc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3222; x-ms-traffictypediagnostic: BYAPR11MB3222: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(13464003)(52314003)(53754006)(199004)(189003)(55016002)(33656002)(66946007)(76116006)(305945005)(5660300002)(7736002)(478600001)(66556008)(71190400001)(2906002)(71200400001)(66476007)(86362001)(2501003)(3846002)(66446008)(256004)(6306002)(74316002)(81156014)(53936002)(68736007)(8936002)(64756008)(14444005)(6116002)(66066001)(966005)(186003)(76176011)(8676002)(6436002)(52536014)(110136005)(11346002)(6506007)(476003)(53546011)(102836004)(99286004)(26005)(316002)(446003)(14454004)(7696005)(6246003)(81166006)(25786009)(229853002)(9686003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3222; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hpLurJbUPHw8vozEltkqiJ9zsF2QnJz8sm0Wb5i+njKgP1E+rvT1J+a+fPrxydNRNBrTzHbsy4mFiRku0xErXylcB6tAa/Zl/EPR3a+OuT1xgI34KLF2AiJvjrKaoi3tToQnVSqcxwKliUNiNpfk2qApcTk2uYe/aEYmcf56if4FVL9PGKlKSEpzuJwW2nhV49yHs1U+kMj1Id6aSS7EjMCPqe1hfHZH4VQR7XN4ccWJkvKlGMxh0Vr6w9oTaxscx4q2ADwcytw/VJLuuwUoRuNqTSTnPSjX1MBAUdZF9dcKzaAJhjIyzXF3g++2UirP2lZSN/ccpjpknTKcYO6O3aGXFGkj0qwqAoy2Ffh+m+S7zfVkIGVWkE/6LonRA+Sle3AhoQzbqCXYMYJvagwq4+rC24OY0byyrPCPlJf61X8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f2046554-33ef-488d-4a01-08d71b16a9dc X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 09:07:24.7942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3222 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:07:58 -0000 I can see that 'when automatic deletion' processing can be useful if the co= nfiguration is being manipulated by a human. E.g. if I delete a VRF then a= ll the configuration that references that VRF can magically disappear. Ass= uming the server supports config rollback then even if I make a catastrophi= c mistake, it isn't usually that hard to recover from. But for a fully automated client, then I agree with Lada, in that I see the= server side 'when automatic deletion' processing as unhelpful. The client= logically needs to know/understand the full configuration anyway, so it sh= ould be able to generate the complete configuration change required to upda= te the server with a new valid configuration state. In these scenarios, ha= ving the server perform 'when automatic deletion' processing seems to incre= ase the risk that that client and server views of the configuration could e= nd up out of sync. Some clients simplify the protocol operations by always= doing a config replace on every config change to guarantee that the copy o= f the configuration on the server matches what is in the client. For clients that exist somewhere between no automation and full automation,= then I can imagine that for some cases 'when automatic deletion' processin= g might be useful, and other cases where it is unhelpful. Personally, I would have preferred that the 'when automatic deletion' proce= ssing was controlled via an explicit protocol option, with the default beha= viour to just validate when statements (equivalently to must statements) an= d not perform any automatically config deletion. Thanks, Rob -----Original Message----- From: netmod On Behalf Of Ladislav Lhotka Sent: 07 August 2019 08:39 To: Andy Bierman ; Fengchong (frank) ; netmod@ietf.org; Zhangxiaoping (C) ;= liuzhiying Subject: Re: [netmod] a question about 'when' Andy Bierman writes: > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka wrote: > >> "Fengchong (frank)" writes: >> >> > Hi all, >> > >> > I encounter a question about 'when', when I implement yang model >> associated when condition. >> > >> > Yang model: >> > >> > leaf password-type { >> > type enumeration { >> > enum null; >> > enum simple; >> > enum cipher; >> > } >> > } >> > >> > leaf password-text { >> > type string; >> > when "../password-type !=3D null"; >> > } >> > >> > I config these two leafs as below: >> > simple >> > 123456 >> > >> > And I changed password-type to null, I get the config like below: >> > null >> > >> > And then, I reconfig the password-type to simple, what data should=20 >> > be >> returned? >> > >> > Is >> > simple >> >> According to RFC 7950, sec. 8.2, the server deleted "password-text"=20 >> after you changed "password-type" to null but the original value=20 >> isn't recovered after you change the type back. >> >> This server behaviour means that a typo or similar trivial error may=20 >> have catastrophic consequences such as auto-deletion of entire=20 >> configuration subtrees. That's why our RESTCONF implementation=20 >> (jetconf) does something >> else: it won't permit you to change "password-type" to null as long=20 >> as the "password-text" exists. >> >> > It seems odd to optimize the server for client mistakes. This is just the principle of least embarrassment. The problem is that it i= s not indicated in the data model that deleting or changing something may h= ave far-reaching consequences. > It is far more likely (99 to 1?) that the client knows what it is=20 > doing and expects the standard to be followed. Consider the burden on=20 > the client deleting all the "false-when" nodes manually. This is If it is a significant burden, then it's also quite likely that the client = may not be completely aware of what's going to be auto-deleted. > also inconsistent with the standard behavior for choice-stmt (new case=20 > deletes the old case automatically). This is quite different in that the impact is localized: one can easily see= that a given leaf is a case in a choice so that it cannot exist along with= another case. Lada > > Lada >> >> > Andy > > >> > >> > Or >> > >> > simple >> > 123456 >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 7 02:47:34 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECBB1203C9 for ; Wed, 7 Aug 2019 02:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Cs99m-S1K1sY for ; Wed, 7 Aug 2019 02:47:30 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53981203BC for ; Wed, 7 Aug 2019 02:47:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DD43485E; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 7aVRR102kS1H; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C208220136; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id f1vciAGEJIAX; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4D8B520134; Wed, 7 Aug 2019 11:47:27 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 7 Aug 2019 11:47:26 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 56A38378FD5; Wed, 7 Aug 2019 11:47:25 +0200 (CEST) Date: Wed, 7 Aug 2019 11:47:25 +0200 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" CC: Ladislav Lhotka , Andy Bierman , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Message-ID: <20190807094725.ljhtx67jpsx2h2ak@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , Ladislav Lhotka , Andy Bierman , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:47:32 -0000 On Wed, Aug 07, 2019 at 09:07:24AM +0000, Rob Wilton (rwilton) wrote: > > Personally, I would have preferred that the 'when automatic deletion' processing was controlled via an explicit protocol option, with the default behaviour to just validate when statements (equivalently to must statements) and not perform any automatically config deletion. > In hindsight, I tend to agree with your conclusion. But since the default is recursive deletion, implementors can choose to add an option controling the behavior (and perhaps we could even standardize such an option). But it is in my view not OK to simply implement a different behavior since clients may rightfully expect recursive deletion as this is what the specs says. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 7 03:15:12 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0185120640 for ; Wed, 7 Aug 2019 03:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 EIN7R7T7EzLr for ; Wed, 7 Aug 2019 03:15:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E8E120636 for ; Wed, 7 Aug 2019 03:15:08 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 4B0FC140BA7; Wed, 7 Aug 2019 12:15:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1565172906; bh=jnBvO+fHBVGQLOVTbEoXBbE0HZMTa5qWvLGWYGGrJXM=; h=From:To:Date; b=PlqypwUnBnZAHMeKkp9rvxImJAdoQRkbLpGZrSnm4xRmYWaorDag6B+YH3jRQM+x5 fZj5M7At1hKwQ11LftMMrjk4XjpiJxOCxPIqKRgsh8xQSiCsYZus3icPC0/3e+uGqB KcQh82+gXpqDkevTZy4PCglRGpafmBWqm/ZNFSrg= Message-ID: <721adaafbbd2c7d837f39f6a8ba6e2d89cd5fb71.camel@nic.cz> From: Ladislav Lhotka To: "Rob Wilton (rwilton)" , Andy Bierman , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Date: Wed, 07 Aug 2019 12:15:05 +0200 In-Reply-To: References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 10:15:11 -0000 On Wed, 2019-08-07 at 09:07 +0000, Rob Wilton (rwilton) wrote: > I can see that 'when automatic deletion' processing can be useful if the > configuration is being manipulated by a human. E.g. if I delete a VRF then > all the configuration that references that VRF can magically > disappear. Assuming the server supports config rollback then even if I make a > catastrophic mistake, it isn't usually that hard to recover from. > > But for a fully automated client, then I agree with Lada, in that I see the > server side 'when automatic deletion' processing as unhelpful. The client > logically needs to know/understand the full configuration anyway, so it should > be able to generate the complete configuration change required to update the > server with a new valid configuration state. In these scenarios, having the > server perform 'when automatic deletion' processing seems to increase the risk > that that client and server views of the configuration could end up out of > sync. Some clients simplify the protocol operations by always doing a config > replace on every config change to guarantee that the copy of the configuration > on the server matches what is in the client. > > For clients that exist somewhere between no automation and full automation, > then I can imagine that for some cases 'when automatic deletion' processing > might be useful, and other cases where it is unhelpful. > > Personally, I would have preferred that the 'when automatic deletion' > processing was controlled via an explicit protocol option, with the default > behaviour to just validate when statements (equivalently to must statements) > and not perform any automatically config deletion. I agree. In any case, protocol behaviour like this should not be a part of YANG specification. This is one of the things that need to be removed in 7950bis. Lada > > Thanks, > Rob > > > -----Original Message----- > From: netmod On Behalf Of Ladislav Lhotka > Sent: 07 August 2019 08:39 > To: Andy Bierman ; Fengchong (frank) < > frank.fengchong@huawei.com>; netmod@ietf.org; Zhangxiaoping (C) < > zhang.xiaoping@huawei.com>; liuzhiying > Subject: Re: [netmod] a question about 'when' > > Andy Bierman writes: > > > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka wrote: > > > > > "Fengchong (frank)" writes: > > > > > > > Hi all, > > > > > > > > I encounter a question about 'when', when I implement yang model > > > associated when condition. > > > > Yang model: > > > > > > > > leaf password-type { > > > > type enumeration { > > > > enum null; > > > > enum simple; > > > > enum cipher; > > > > } > > > > } > > > > > > > > leaf password-text { > > > > type string; > > > > when "../password-type != null"; > > > > } > > > > > > > > I config these two leafs as below: > > > > simple > > > > 123456 > > > > > > > > And I changed password-type to null, I get the config like below: > > > > null > > > > > > > > And then, I reconfig the password-type to simple, what data should > > > > be > > > returned? > > > > Is > > > > simple > > > > > > According to RFC 7950, sec. 8.2, the server deleted "password-text" > > > after you changed "password-type" to null but the original value > > > isn't recovered after you change the type back. > > > > > > This server behaviour means that a typo or similar trivial error may > > > have catastrophic consequences such as auto-deletion of entire > > > configuration subtrees. That's why our RESTCONF implementation > > > (jetconf) does something > > > else: it won't permit you to change "password-type" to null as long > > > as the "password-text" exists. > > > > > > > > It seems odd to optimize the server for client mistakes. > > This is just the principle of least embarrassment. The problem is that it is > not indicated in the data model that deleting or changing something may have > far-reaching consequences. > > > It is far more likely (99 to 1?) that the client knows what it is > > doing and expects the standard to be followed. Consider the burden on > > the client deleting all the "false-when" nodes manually. This is > > If it is a significant burden, then it's also quite likely that the client may > not be completely aware of what's going to be auto-deleted. > > > also inconsistent with the standard behavior for choice-stmt (new case > > deletes the old case automatically). > > This is quite different in that the impact is localized: one can easily see > that a given leaf is a case in a choice so that it cannot exist along with > another case. > > Lada > > > Lada > > > > > Andy > > > > > > > > Or > > > > > > > > simple > > > > 123456 > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Aug 7 07:14:51 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145012002E for ; Wed, 7 Aug 2019 07:14:49 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=No80j9hy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cswK6MFX 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 dbHyb-zw_Yat for ; Wed, 7 Aug 2019 07:14:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2025F120019 for ; Wed, 7 Aug 2019 07:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9156; q=dns/txt; s=iport; t=1565187287; x=1566396887; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=B+RaP9/KK1J11JpYO0igfD7Li+F2oinp6cL9shAQJ8A=; b=No80j9hyPdJWBQGV72p4lmYZCcp8GuFvziNU7W0WAvIT6VC+sX0i8qUn 4gdzyYkDncUG2xLYNkH8PqV7w+vPBKSPbBwyAfMmxDfBfjmIRtSVMXak8 RGS7hwvtRjYHoZaH80u/VtYZkg7g84VphSQWGPFek2ryT6Dot45zzctUp A=; IronPort-PHdr: =?us-ascii?q?9a23=3At+mhrBVSKqpiZswBbBLPcL0CxwDV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AABM2kpd/5xdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUQkLANtVSAECyoKhBSDRwOEUoZgTIIPlgKBW4EuFIEQA1Q?= =?us-ascii?q?JAQEBDAEBGA0IAgEBg3pFAheCOyM0CQ4BAwEBAQQBAQIBAQYEbYUnDIVKAQE?= =?us-ascii?q?BAQMBARALBhEMAQEsDAsEAgEIEQQBAQMCJgICAiULFQgIAgQBEggagwGBagM?= =?us-ascii?q?dAQIMn3kCgTiIYHGBMoJ6AQEFgTMBg1kYghQDBoEMKAGLYxeBQD+BEUaBNxd?= =?us-ascii?q?+PoJhAQGBLgESASEVgnQygiaMMTMDgiScJQkCghyGXY1hgjCHLoodhDeMaWS?= =?us-ascii?q?HWpAaAgQCBAUCDgEBBYFQOGdxcBU7gmyCQgkDF4NOhRSFPgFygSmLOoEiAYE?= =?us-ascii?q?gAQE?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="scan'208";a="314305080" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 14:14:46 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x77EEkZC016653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 14:14:46 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 09:14:45 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 09:14:44 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 09:14:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MDlY7NQACkXwZMmNSFikaDxL/xiFofGYY/yiFYkiF2JdsSuFGfZatR5RP0UxAQZTQ5tpHVwSw+EbYEw9+qNFTWspS7506YNRSgR0DQWw9WF6iuO/gtPmWHYqcp/lySIe5rEveDlp1uPLy3EKaY3nvfnsQgneXgJMkECbANZa/zClpGe1LrKyKkLQD7d5HR3DyNYcje/ghlWM4KZV2JAPRtSDAS5Lf+3Tc3ZOEgSJvpwlOemJeTTu8lfuGb3RdyW2G0OADOvVnyHfayJdsUMkJX66F0SoHA0nzpT7K/MFHhrIlF4ekZFbylsKIUeyirOxyzTNjUSktqyTIeAAI4dCpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B+RaP9/KK1J11JpYO0igfD7Li+F2oinp6cL9shAQJ8A=; b=QK4RSfV3mU+7mqLf4/LnVsvTAOv3ACug5aEs38HRJcivtQuyOIVQSMSoy+aO6GOg2OopqdHCtmspIcXMz3UKMxa+6LApzSrmZKkvjiJcCKOpfkIhK0GyMA6+mEZ6dQbzAXq9QvpUmuUMedmGQk0dHwrCbnJ5yJy4DE+cCSeX8fNqmJlyQrdq+jo0XdelFwu+5Ah7zQDmxEDSTX1LSoP1Cr8TxdEZCNnYx1IvIh0hS56s7ngICb+igZJze5H0AbXb32hP3+sSWJLMrcSFlkaaA5XQ3FwPTV2RX2X/0BLrlIAKntL+6R+nCLstd60JK0973F/XHCwVkH2uvXFdPCCNdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B+RaP9/KK1J11JpYO0igfD7Li+F2oinp6cL9shAQJ8A=; b=cswK6MFXvtrlm3NKSO9U1JSmHeuPIo9b/sn9ldaOyV53PwlKYT8Xd/SqBwJgzCOmQx4sOlvHD3YOUAKCw+VxSCKKNWMJTcP3KDL/4Iq2fvx6BsEV7WIrY190L4A6FAqdWIMhACiu6P+xi5IBdmiah+IW5bQx8/E2lU6oA+z+Stk= Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2647.namprd11.prod.outlook.com (52.135.227.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.19; Wed, 7 Aug 2019 14:14:43 +0000 Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428%4]) with mapi id 15.20.2136.018; Wed, 7 Aug 2019 14:14:43 +0000 From: "Rob Wilton (rwilton)" To: "Acee Lindem (acee)" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6bD086AgAmC0nCAH6jrgIABNoxQ Date: Wed, 7 Aug 2019 14:14:43 +0000 Message-ID: References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <80F2E6D2-8F6A-4EF4-9838-45AC48BE84E5@cisco.com> <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> In-Reply-To: <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35deb790-6a87-40e2-a9b9-08d71b41980f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2647; x-ms-traffictypediagnostic: BYAPR11MB2647: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(51444003)(189003)(199004)(51914003)(13464003)(74316002)(55016002)(110136005)(53546011)(6506007)(99286004)(102836004)(6436002)(305945005)(6246003)(66066001)(7736002)(8936002)(81166006)(81156014)(8676002)(7696005)(25786009)(316002)(66446008)(2906002)(3846002)(76116006)(9686003)(66556008)(66476007)(66946007)(6306002)(6116002)(76176011)(561944003)(2501003)(64756008)(229853002)(33656002)(52536014)(186003)(53936002)(26005)(11346002)(86362001)(476003)(446003)(486006)(14444005)(256004)(5024004)(71200400001)(71190400001)(14454004)(68736007)(5660300002)(966005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2647; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LM/yWbb0BHojW/8g1wDFrTFI2m5/BMzL/+mEtgNq7R5gfzPCOfUPC0A/UhNN9Ioo7EZeNUnG/yv90xw01k+S6ZNl9scrklaUArQ1oTA51Zp2BNLEl4f2iPlSHM6tjTdcoKZ2LmukfyBRq+lLDeDSZIYPncFAI/wVusZcsFxABx5W1RVXfs2vFWe/mbwxd7HqPoaKiKlJ/VWrgcYbIuEKGDkiwM6OskkouTxa16hca0F3D8XwebngaKyds5KRmrjwHkJmP8j8qqI5DiTW0eKICbulUyKgNYbxn3Ym7v0rzmkb41iy9boj07U4wzUHzFOo0W6zI3b37qtQ7iRlNEK4BHZ8C2EaYfFCnjrU5Z3Rgghja5ewDa8vFxWqttLWyAngING15sSad+zgx0eCWJtAs9z7gsUbq4KtRJQs+LnP680= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 35deb790-6a87-40e2-a9b9-08d71b41980f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 14:14:43.2772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2647 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 14:14:49 -0000 SGkgQWNlZSwNCg0KVGhhbmtzLiAgVGhpcyB3YXMgYWxzbyBkaXNjdXNzZWQgaW4gdGhlIE5FVE1P RCBXRyBtZWV0aW5nIChJIGtub3cgdGhhdCB5b3UgaGFkIGEgY29uZmxpY3QpLiAgDQoNCk15IHJl YWRpbmcgb2YgdGhlIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdGhhdCB0aGUgaGlzdG9ncmFt IHN0YXRpc3RpY3Mgc2hvdWxkIGJlIGRlZmVycmVkIGF0IHRoaXMgdGltZS4gIEluIHBhcnRpY3Vs YXIsIGl0IHNlZW1zIGxpa2UgaXQgd291bGQgdGFrZSBzb21lIHRpbWUvZWZmb3J0IHRvIGFncmVl IG9uIGV4YWN0bHkgaG93IHRoZXNlIGNvdW50ZXJzIHNob3VsZCBiZSBtb2RlbGxlZC4gIEkgYWxz byBzYWlkIHRoYXQgSSB3b3VsZCBjb250YWN0IHRoZSBJRUVFIDgwMi4zIFdHIGNoYWlyIHRvIHNl ZSBpZiB3ZSBjb3VsZCBwcm9ncmVzcyBhIGhpc3RvZ3JhbSBtb2RlbCB3aXRoaW4gdGhlIElFVEYu ICBJIGhhdmUgc2VudCBhbiBlbWFpbCBvdXQsIGJ1dCBub3QgaGVhcmQgYW55dGhpbmcgYmFjayB5 ZXQuDQoNClRoZXJlIHdhcyBjb25zZW5zdXMgaW4gdGhlIHJvb20gdG8gYWRkIGEgc3ViLWludGVy ZmFjZSBkZW11eCBkcm9wIGNvdW50ZXIgaW50byB0aGUgY3VycmVudCBtb2R1bGUuDQoNCkxvdSBh bHNvIHByb3Bvc2VkIHRoYXQgSSByZW5hbWUgImwyLW10dSIgdG8gc29tZXRoaW5nIGxpa2UgIm1h eC1mcmFtZS1zaXplIiBmb3IgY29uc2lzdGVuY3kgKEkgbmVlZCB0byBjaGVjayB0aGUgcmVjb3Jk aW5nKS4NCg0KSXQgYWxzbyBsb29rcyBsaWtlIEkgc2hvdWxkIGdlbmVyYXRlIGFuZCBhZGQgLXN0 YXRlIHRyZWVzIHRvIHRoZSBhcHBlbmRpeC4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZWUgTGluZGVtIChhY2VlKSANClNlbnQ6IDA1IEF1 Z3VzdCAyMDE5IDE4OjUyDQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28u Y29tPjsgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLW5ldG1vZC1p bnRmLWV4dC15YW5nLTA3DQoNCkhpIFJvYiwgDQpJdCBzZWVtcyB0aGVzZSBjb3VudGVycyBoYXZl IGJlZW4gY29uc2lkZXJlZCBhdCBncmVhdCBsZW5ndGguIEkgYWdyZWUgd2Ugc2hvdWxkIG1vdmUg Zm9yd2FyZCB3aXRoIHRoZSBtb2RlbCBhcyBpdCBpcyB0b2RheS4NClRoYW5rcywNCkFjZWUNCg0K 77u/T24gNy8xNy8xOSwgMTE6MzYgQU0sICJSb2IgV2lsdG9uIChyd2lsdG9uKSIgPHJ3aWx0b25A Y2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpIEFjZWUsDQogICAgDQogICAgVGhhbmtzIGZvciB0 aGUgcmV2aWV3LCBhbmQgYXBvbG9naWVzIGZvciB0aGUgZGVsYXllZCByZXBseS4NCiAgICANCiAg ICBSZWdhcmRpbmcgeW91ciBzdGF0cyBxdWVzdGlvbiwgdGhlcmUgd2FzIHNvbWUgZWZmb3J0IHRv IGhhbmRsZSB0aGlzIGFzIHBhcnQgb2YgZGVmaW5pbmcgdGhlIEV0aGVybmV0IGludGVyZmFjZSBZ QU5HIChJRUVFIDgwMi4zLjItMjAxOSkgKGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lh bmcvdHJlZS9tYXN0ZXIvc3RhbmRhcmQvaWVlZS9wdWJsaXNoZWQvODAyLjMpIHRoYXQgSSB3YXMg aW52b2x2ZWQgaW4gdGhlIGVhcmxpZXIgcGFydHMgb2YuICBQbGVhc2Ugc2VlIHRoZSBhdHRhY2hl ZCBYTFMgdGhhdCB3YXMgbXkgZWFybGllciBlZmZvcnQgdG8gcmF0aW9uYWxpemUgdGhlIGRpZmZl cmVudCBldGhlcm5ldCBpbnRlcmZhY2VzIGNvdW50ZXJzIGJldHdlZW4gUkZDIDcyMjMsIEV0aGVy bmV0IFlBTkcsIEV0aGVybGlrZSBNSUIsIFJNT04gTUlCcywgYW5kIHRoZSBjb3VudGVycyBleHBv c2VkIGluIHRoZSA4MDIuMyBjbGF1c2UgMzAgbWFuYWdlbWVudCBBUEkuDQogICAgDQogICAgRm9y IHBoeXNpY2FsIEV0aGVybmV0IGludGVyZmFjZXMgKGFuZCBhbnl0aGluZyB0aGF0IGxvb2tzIHZl cnkgc2ltaWxhciB0byBhIHBoeXNpY2FsIEV0aGVybmV0IGludGVyZmFjZSkgdGhlbiBJIHRoaW5r IHRoYXQgd2Ugc2hvdWxkIGJlIHdlbGwgY292ZXJlZCBieSB0aGUgY29tYmluYXRpb24gb2Ygd2hh dCBpcyBpbiBpZXRmLWludGVyZmFjZXMsIGFuZCBJRUVFIDgwMi4zLjIuDQogICAgDQogICAgVGhl cmUgYXJlIGFsc28gc29tZSBjb3VudGVycyB0aGF0IGFwcGx5IHRvIGFsbCBFdGhlcm5ldC1saWtl IGludGVyZmFjZXMgKHJlYWxseSBhbnl0aGluZyB1c2luZyBFdGhlcm5ldCBmcmFtaW5nLCBidXQg bm90IGFuIEV0aGVybmV0IHBoeXNpY2FsIGxheWVyKS4gIFRoZSBvbmx5IGNvdW50ZXIgY3VycmVu dGx5IGRlZmluZWQgaW4gdGhpcyBjYXRlZ29yeSBpcyBpbi1kcm9wLXVua25vd24tZGVzdC1tYWMt cGt0cyBpbiBpZXRmLWludGVyZmFjZXMtZXRoZXJuZXQtbGlrZS4gIEFyZ3VhYmx5IHdlIGNvdWxk IGFsc28gYWRkIGEgZHJvcCBjb3VudGVyIGZvciBmcmFtZXMgdGhhdCBjb3VsZCBub3QgYmUgZGVt dXhlZCB0byBhIHN1Yi1pbnRlcmZhY2UgYmVjYXVzZSBpdCBkaWRuJ3QgbWF0Y2ggYW55IG9mIHRo ZSBzdWItaW50ZXJmYWNlIG1hdGNoIGV4cHJlc3Npb25zLg0KICAgIA0KICAgIFRoZXJlIHdhcyBv bmUgc2V0IG9mIGNvdW50ZXJzIHRoYXQgODAyLjMuMiBkaWRuJ3Qgd2FudCB0byBpbmNsdWRlIGlu IHRoZWlyIFlBTkcgbW9kdWxlIHdoaWNoIHJlbGF0ZWQgdG8gdGhlIGhpc3RvZ3JhbSBmcmFtZSBz dGF0aXN0aWNzLiAgRS5nLiBjb3VudGVycyBsaWtlIHRoZSBmb2xsb3dpbmcgKHRha2VuIGZyb20g SU9TIFhSKToNCiAgICANCiAgICAgICAgSW5wdXQgcGt0cyA2NS0xMjcgYnl0ZXMgICAgID0gMA0K ICAgICAgICBJbnB1dCBwa3RzIDEyOC0yNTUgYnl0ZXMgICAgPSAwDQogICAgICAgIElucHV0IHBr dHMgMjU2LTUxMSBieXRlcyAgICA9IDANCiAgICAgICAgSW5wdXQgcGt0cyA1MTItMTAyMyBieXRl cyAgID0gMA0KICAgICAgICBJbnB1dCBwa3RzIDEwMjQtMTUxOCBieXRlcyAgPSAwDQogICAgICAg IElucHV0IHBrdHMgMTUxOS1NYXggYnl0ZXMgICA9IDANCiAgICANCiAgICAgICAgT3V0cHV0IHBr dHMgNjUtMTI3IGJ5dGVzICAgID0gMA0KICAgICAgICBPdXRwdXQgcGt0cyAxMjgtMjU1IGJ5dGVz ICAgPSAwDQogICAgICAgIE91dHB1dCBwa3RzIDI1Ni01MTEgYnl0ZXMgICA9IDANCiAgICAgICAg T3V0cHV0IHBrdHMgNTEyLTEwMjMgYnl0ZXMgID0gMA0KICAgICAgICBPdXRwdXQgcGt0cyAxMDI0 LTE1MTggYnl0ZXMgPSAwDQogICAgICAgIE91dHB1dCBwa3RzIDE1MTktTWF4IGJ5dGVzICA9IDAN CiAgICANCiAgICBUaGUgODAyLjMgWUFORyBXRyBoYWQgdHdvIGlzc3VlcyB3aXRoIGluY2x1ZGlu ZyBjb3VudGVycyBsaWtlIHRoZXNlOg0KICAgICgxKSBUaGV5IGRpZG4ndCByZWFsbHkgd2FudCB0 byBkZWZpbmUgaGlzdG9ncmFtIGNvdW50ZXIgdmFsdWVzIGZvciBNVFVzIHRoYXQgYXJlIGFib3Zl IHRoZSBvZmZpY2lhbGx5IHNhbmN0aW9uZWQgTVRVIG9mIDE1MTQvMTUxOCBpbiB0aGUgRXRoZXJu ZXQgc3BlY2lmaWNhdGlvbiwgZXZlbiB0aG91Z2ggYSBsb3Qgb2YgaGFyZHdhcmUgc3VwcG9ydHMg dXAgdG8gOUsrLg0KICAgICgyKSBUaGUgYnVja2V0IHJhbmdlcywgYXQgbGVhc3Qgb25jZSB5b3Ug Z2V0IHBhc3QgdGhlICI1MTItMTAyMyIgYnVja2V0LCBzZWVtIHRvIHNvbWV3aGF0IHZhcnkgYnkg QVNJQyB2ZW5kb3IuDQogICAgKDMpIElFRUUgODAyLjMgaGFzIGEgd2VsbCBkZWZpbmVkIGludGVy bmFsIG1hbmFnZW1lbnQgQVBJICg4MDIuMyBjbGF1c2UgMzApLCBhbmQgdGhlc2UgaGlzdG9ncmFt IGNvdW50ZXJzIGFyZSBub3QgY3VycmVudGx5IGRlZmluZWQgYXMgcGFydCBvZiB0aGF0IGludGVy bmFsIG1hbmFnZW1lbnQgQVBJLiAgRXh0ZW5kaW5nIHRoZSBpbnRlcm5hbCA4MDIuMyBtYW5hZ2Vt ZW50IEFQSSBzZWVtcyB0cmlja3kgZHVlIHRvIHBvaW50ICgxKSBhbmQgKDIpIGFib3ZlLg0KICAg IA0KICAgIFRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gaW4gdGhlIDgwMi4zIGRpc2N1c3Npb25zIHRo YXQgdGhlc2UgY291bnRlcnMgY291bGQgYmUgZGVmaW5lZCBpbiBhbiBJRVRGIFlBTkcgbW9kdWxl IChza2lydGluZyB0aGUgSUVFRSBjb25jZXJucyBhYm91dCBtYXhpbXVtIE1UVXMpLiAgVGhlIHBy b3Bvc2FsIHdhcyB0byBhbGxvdyB0aGUgb3BlcmF0aW9uYWwgZGF0YSB0byByZXR1cm4gYSBsaXN0 IG9mIGJ1Y2tldCBlbnRyaWVzLCB3aGVyZSBlYWNoIGVudHJ5IGRlZmluZXMgdGhlIGluY2x1c2l2 ZSByYW5nZSBvZiB0aGUgYnVja2V0LCBhbmQgYSBjb3VudCBvZiB0aGUgcGt0cyB0aGF0IG1hdGNo ZWQgdGhlIGJ1Y2tldCByYW5nZSAoaW4gZWl0aGVyIHRoZSBpbmdyZXNzIG9yIGVncmVzcyBkaXJl Y3Rpb24pLiAgVGhpcyBsaXN0IHdvdWxkIHNpdCBhbG9uZ3NpZGUgYSBSRUNPTU1FTkRBVElPTiBv ZiB3aGF0IGJ1Y2tldCBzaXplcyB0byB1c2UsIGJhc2ljYWxseSBkb3VibGluZyBlYWNoIHRpbWUg dXAgdG8gdGhlIE1UVSwgd2l0aCBzb21lIGNvbnNpZGVyYXRpb24gYXJvdW5kIHRoZSAxNTE0LzE1 MTgvMTUyMiBib3VuZGFyeSwgYnV0IGFsbG93aW5nIGZyZWVkb20gZm9yIGEgZGV2aWNlIHRvIGFj Y3VyYXRlbHkgcmV0dXJuIHRoZSBoaXN0b2dyYW0gcmFuZ2VzIGFjdHVhbGx5IHN1cHBvcnRlZCBi eSB0aGUgaGFyZHdhcmUuDQogICAgDQogICAgSG93ZXZlciwgSSdtIG5vdCBzdXJlIGl0IGlzIHdv cnRoIGRlbGF5aW5nIHRoZXNlIGRyYWZ0cyB0byBhZGQgdGhlc2UgY291bnRlcnMgaW4gbm93LCBw YXJ0aWN1bGFybHkgYmVjYXVzZSB0aGVyZSBhcmUgZGVwZW5kZW5jaWVzIG9uIHRoZW0uICBQb3Nz aWJseSBiZXN0IGRvbmUgYXMgZnV0dXJlIHdvcms/ICBEbyB5b3UsIG9yIGFueW9uZSBlbHNlIGlu IHRoZSBXRyBoYXZlIGFuIG9waW5pb24gb24gdGhpcz8NCiAgICANCiAgICBUaGFua3MsDQogICAg Um9iDQogICAgDQogICAgDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAg ICBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWNl ZSBMaW5kZW0gKGFjZWUpDQogICAgU2VudDogMTAgSnVseSAyMDE5IDE0OjA5DQogICAgVG86IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IG5ldG1vZEBpZXRmLm9yZw0KICAgIFN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLWludGYt ZXh0LXlhbmctMDcNCiAgICANCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhlIHN1YmplY3QgZG9jdW1l bnQgYW5kIHN1cHBvcnQgcHVibGljYXRpb24uIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQ6 DQogICAgDQogICAgICBQZXJoYXBzIGlldGYtaW50ZXJmYWNlLWV0aGVybmV0LWxpa2UgbW9kdWxl IGV0aGxpa2U6ZXRoZXJuZXQtbGlrZS9ldGhsaWtlOnN0YXRpc3RpY3MgY291bGQgaW5jbHVkZSBh IHN1YnNldCBvZiB0aGUgY291bnRlcnMgZnJvbSBSRkMgMzYzNS4gSSBzYXkgYSBzdWJzZXQgc2lu Y2Ugc29tZSBvZiB0aGVzZSBjb3VudGVycyBhcmUgYSBiaXQgYXJjaGFpYyBnaXZlbiB0aGUgc3Rh dGUgb2YgdGhlIHRlY2hub2xvZ3kgYW5kIGp1ZGdlbWVudCBzaG91bGQgYmUgYXBwbGllZCBvbiB3 aGljaCB0byBpbmNsdWRlLg0KICAgIA0KICAgICAgVGhhbmtzLA0KICAgIEFjZWUgDQogICAgDQog ICAgT24gNy85LzE5LCA4OjE2IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIg PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBrZW50K2lldGZAd2F0c2VuLm5l dD4gd3JvdGU6DQogICAgDQogICAgICAgIEFsbCwNCiAgICAgICAgDQogICAgICAgIFRoaXMgc3Rh cnRzIGEgdHdlbHZlLWRheSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1u ZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KICAgICAgICANCiAgICAgICAgVGhlIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGVuZHMgb24gSnVseSAyMSAodGhlIGRheSBiZWZvcmUgdGhlIE5FVE1PRCAx MDUgc2Vzc2lvbnMpLiAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QuDQogICAgICAgIA0KICAgICAgICBQb3NpdGl2ZSBjb21tZW50cywg ZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSEgIFRoaXMgaXMgdXNlZnVsIGFuZCBpbXBv cnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KICAgICAgICANCiAgICAgICAgVGhhbmsgeW91LA0K ICAgICAgICBORVRNT0QgQ2hhaXJzDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICAg ICAgbmV0bW9kQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQogICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAg IG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQogICAgDQoNCg== From nobody Wed Aug 7 08:30:00 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBC2120368 for ; Wed, 7 Aug 2019 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX2ua4XCAmeR for ; Wed, 7 Aug 2019 08:29:55 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 38DA61200C5 for ; Wed, 7 Aug 2019 08:29:55 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b29so57114443lfq.1 for ; Wed, 07 Aug 2019 08:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Bk8/dRnIrhdWhn1l3Ok6pZNO+ZKXJzzlXxL2mFzxyg=; b=RA20yHhjwYWSpQHnUkWDFDJAP41YEJZW9vl438khOzSGwoPCPgXtJ1AOHuvQvMQHOM dsksU48UvMu6FZirkxPIAJI5i4sSuHJz2n94Li0HBscQdVB9zCB67B3BTTsCrx7moDz+ gDUtCRylFnoU+H56LDKdp0nXR+FYx5+n0cv7N2AaeRwFQSpuQXW8RPuT3fYT9kBk/WIz zHVbh9ALujxqQLWjq7XI4lQTZJvyOiKBnLcftxb6czVPXiQsHjpIeA8OcAGqb69zb4eE ahfDLVHzUPTft/BC3sud7zDujknyKU1eqKmPcpx1KZkW6gez52Bczm6kQNRFNJ8ePXVf Fwug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Bk8/dRnIrhdWhn1l3Ok6pZNO+ZKXJzzlXxL2mFzxyg=; b=igi9w63Tzr9wVkJv8LU3CAdRnmdaT+k0Zhw42hFUYe/PP6Sh7v1RKtLxkHLT/92XWH nIEjW7qYIdVX/zp/EbZ+7wDpeBxJjmdXkwswfiV/0Q2V0GAITkeZRrZMmhsK2B+Vj/9W FXL8lUZrNE8Lr+gPMIw8AUg49hndoDVOgAOioiHhvpbYWqLPppbs0nslPJ0kJFoXH075 tcYVBn5XdPs072JhBDspjVQVq8KIXrZH63WjwSre1+IvNoizLfsbe4fY6YxA5+9+CJmz tWjS1AehfK7/v17Cue6kDL82HD3CQGjvpncb5PATeXwndAn3Vm7mkAeSOCyTw8p7yl4A zkPQ== X-Gm-Message-State: APjAAAU9hexNHGce2sUtmUonUONmXUs7WOuxCexO0PzzQrDjY0XyjHxP 9ynSV8Ym298rKZHgOZ0BWVcTNbiWJ4aP4zp9CBizDA== X-Google-Smtp-Source: APXvYqzcVJwiIbvziRy6ycK3JZjj8hL84A+4MxAyFD6LR6Iiunio8uIKEd/ubZetRkJpOnoXAhmhA4F9AwsFUx6JGoM= X-Received: by 2002:ac2:44ac:: with SMTP id c12mr6385957lfm.33.1565191793158; Wed, 07 Aug 2019 08:29:53 -0700 (PDT) MIME-Version: 1.0 References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 7 Aug 2019 08:29:41 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Ladislav Lhotka , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Content-Type: multipart/alternative; boundary="000000000000d64151058f889c73" Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 15:29:59 -0000 --000000000000d64151058f889c73 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) wrote: > I can see that 'when automatic deletion' processing can be useful if the > configuration is being manipulated by a human. E.g. if I delete a VRF then > all the configuration that references that VRF can magically disappear. > Assuming the server supports config rollback then even if I make a > catastrophic mistake, it isn't usually that hard to recover from. > > But for a fully automated client, then I agree with Lada, in that I see > the server side 'when automatic deletion' processing as unhelpful. The > client logically needs to know/understand the full configuration anyway, so > it should be able to generate the complete configuration change required to > update the server with a new valid configuration state. In these > scenarios, having the server perform 'when automatic deletion' processing > seems to increase the risk that that client and server views of the > configuration could end up out of sync. Some clients simplify the protocol > operations by always doing a config replace on every config change to > guarantee that the copy of the configuration on the server matches what is > in the client. > > For clients that exist somewhere between no automation and full > automation, then I can imagine that for some cases 'when automatic > deletion' processing might be useful, and other cases where it is unhelpful. > > I don't see the big distinction between types of clients. YANG has 2 mechanisms (must and leafref) that will cause an error instead of a silent deletion. The when-stmt is used to indicate that the subtree is not relevant to the model if the result is false. You can easily use must-stmt instead to cause the error behavior instead of deletion behavior. This should be part of the model design, not left up to server developers. Personally, I would have preferred that the 'when automatic deletion' > processing was controlled via an explicit protocol option, with the default > behaviour to just validate when statements (equivalently to must > statements) and not perform any automatically config deletion. > There has been nothing preventing anyone from augmenting the operations to turn off auto-deletion. Is this widely implemented? Implemented at all? > > Thanks, > Rob > > Andy > > -----Original Message----- > From: netmod On Behalf Of Ladislav Lhotka > Sent: 07 August 2019 08:39 > To: Andy Bierman ; Fengchong (frank) < > frank.fengchong@huawei.com>; netmod@ietf.org; Zhangxiaoping (C) < > zhang.xiaoping@huawei.com>; liuzhiying > Subject: Re: [netmod] a question about 'when' > > Andy Bierman writes: > > > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka wrote: > > > >> "Fengchong (frank)" writes: > >> > >> > Hi all, > >> > > >> > I encounter a question about 'when', when I implement yang model > >> associated when condition. > >> > > >> > Yang model: > >> > > >> > leaf password-type { > >> > type enumeration { > >> > enum null; > >> > enum simple; > >> > enum cipher; > >> > } > >> > } > >> > > >> > leaf password-text { > >> > type string; > >> > when "../password-type != null"; > >> > } > >> > > >> > I config these two leafs as below: > >> > simple > >> > 123456 > >> > > >> > And I changed password-type to null, I get the config like below: > >> > null > >> > > >> > And then, I reconfig the password-type to simple, what data should > >> > be > >> returned? > >> > > >> > Is > >> > simple > >> > >> According to RFC 7950, sec. 8.2, the server deleted "password-text" > >> after you changed "password-type" to null but the original value > >> isn't recovered after you change the type back. > >> > >> This server behaviour means that a typo or similar trivial error may > >> have catastrophic consequences such as auto-deletion of entire > >> configuration subtrees. That's why our RESTCONF implementation > >> (jetconf) does something > >> else: it won't permit you to change "password-type" to null as long > >> as the "password-text" exists. > >> > >> > > It seems odd to optimize the server for client mistakes. > > This is just the principle of least embarrassment. The problem is that it > is not indicated in the data model that deleting or changing something may > have far-reaching consequences. > > > It is far more likely (99 to 1?) that the client knows what it is > > doing and expects the standard to be followed. Consider the burden on > > the client deleting all the "false-when" nodes manually. This is > > If it is a significant burden, then it's also quite likely that the client > may not be completely aware of what's going to be auto-deleted. > > > also inconsistent with the standard behavior for choice-stmt (new case > > deletes the old case automatically). > > This is quite different in that the impact is localized: one can easily > see that a given leaf is a case in a choice so that it cannot exist along > with another case. > > Lada > > > > > Lada > >> > >> > > Andy > > > > > >> > > >> > Or > >> > > >> > simple > >> > 123456 > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka > >> Head, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000d64151058f889c73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 7, 2019 at 2:07 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:
I = can see that 'when automatic deletion' processing can be useful if = the configuration is being manipulated by a human.=C2=A0 E.g. if I delete a= VRF then all the configuration that references that VRF can magically disa= ppear.=C2=A0 Assuming the server supports config rollback then even if I ma= ke a catastrophic mistake, it isn't usually that hard to recover from.<= br>
But for a fully automated client, then I agree with Lada, in that I see the= server side 'when automatic deletion' processing as unhelpful.=C2= =A0 The client logically needs to know/understand the full configuration an= yway, so it should be able to generate the complete configuration change re= quired to update the server with a new valid configuration state.=C2=A0 In = these scenarios, having the server perform 'when automatic deletion'= ; processing seems to increase the risk that that client and server views o= f the configuration could end up out of sync.=C2=A0 Some clients simplify t= he protocol operations by always doing a config replace on every config cha= nge to guarantee that the copy of the configuration on the server matches w= hat is in the client.

For clients that exist somewhere between no automation and full automation,= then I can imagine that for some cases 'when automatic deletion' p= rocessing might be useful, and other cases where it is unhelpful.



=
The when-stmt is used to indicate that the subtree is not relevant to = the model if the result is false.
You can easily use must-stmt in= stead to cause the error behavior instead of deletion behavior.
T= his should be part of the model design, not left up to server developers.


Personally, I would have preferred that the 'when automatic deletion= 9; processing was controlled via an explicit protocol option, with the defa= ult behaviour to just validate when statements (equivalently to must statem= ents) and not perform any automatically config deletion.

There has been nothing preventing anyone from augmenting = the operations to turn off auto-deletion.
Is this widely implemen= ted?=C2=A0 Implemented at all?

=C2=A0

Thanks,
Rob


Andy
=C2=A0

-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
Sent: 07 August 2019 08:39
To: Andy Bierman <andy@yumaworks.com>; Fengchong (frank) <frank.fengchong@huawei.com>= ; netmod@ietf.org;= Zhangxiaoping (C) <zhang.xiaoping@huawei.com>; liuzhiying <liuzhiying@huawei.com>=
Subject: Re: [netmod] a question about 'when'

Andy Bierman <an= dy@yumaworks.com> writes:

> On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> "Fengchong (frank)" <frank.fengchong@huawei.com> writes:<= br> >>
>> > Hi all,
>> >
>> > I encounter a question about 'when', when I implement= yang model
>> associated when condition.
>> >
>> > Yang model:
>> >
>> > leaf password-type {
>> >=C2=A0 =C2=A0 type enumeration {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum null;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum simple;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum cipher;
>> >=C2=A0 =C2=A0 }
>> > }
>> >
>> > leaf password-text {
>> > type string;
>> > when "../password-type !=3D null";
>> > }
>> >
>> > I config these two leafs as below:
>> > <password-type>simple</password-type>
>> > <password-text>123456</password-text>
>> >
>> > And I changed password-type to null, I get the config like be= low:
>> > <password-type>null</password-type>
>> >
>> > And then, I reconfig the password-type to simple, what data s= hould
>> > be
>> returned?
>> >
>> > Is
>> >=C2=A0 =C2=A0<password-type>simple</password-type>=
>>
>> According to RFC 7950, sec. 8.2, the server deleted "password= -text"
>> after you changed "password-type" to null but the origin= al value
>> isn't recovered after you change the type back.
>>
>> This server behaviour means that a typo or similar trivial error m= ay
>> have catastrophic consequences such as auto-deletion of entire >> configuration subtrees. That's why our RESTCONF implementation=
>> (jetconf) does something
>> else: it won't permit you to change "password-type" = to null as long
>> as the "password-text" exists.
>>
>>
> It seems odd to optimize the server for client mistakes.

This is just the principle of least embarrassment. The problem is that it i= s not indicated in the data model that deleting or changing something may h= ave far-reaching consequences.

> It is far more likely (99 to 1?) that the client knows what it is
> doing and expects the standard to be followed.=C2=A0 Consider the burd= en on
> the client deleting all the "false-when" nodes manually. Thi= s is

If it is a significant burden, then it's also quite likely that the cli= ent may not be completely aware of what's going to be auto-deleted.

> also inconsistent with the standard behavior for choice-stmt (new case=
> deletes the old case automatically).

This is quite different in that the impact is localized: one can easily see= that a given leaf is a case in a choice so that it cannot exist along with= another case.

Lada

>
> Lada
>>
>>
> Andy
>
>
>> >
>> > Or
>> >
>> >=C2=A0 =C2=A0<password-type>simple</password-type>=
>> >=C2=A0 =C2=A0<password-text>123456</password-type>=
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/net= mod
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000d64151058f889c73-- From nobody Wed Aug 7 08:53:29 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E0412045F for ; Wed, 7 Aug 2019 08:53:19 -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 header.b=O67DxDw2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=09juY2Gl 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 gIrRTZqbWl5c for ; Wed, 7 Aug 2019 08:53:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFC1120475 for ; Wed, 7 Aug 2019 08:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33114; q=dns/txt; s=iport; t=1565193194; x=1566402794; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mvdusH39rimZ2psQW4Pi9wQJKitNmr9nTfBYdYFw9bQ=; b=O67DxDw2OI+krQX3SUdh0GLfF4x9TOeF6EH3xZ+8iK0TQmdP+hvgRnnT foZkHaS8/NMKjjgiE+NLXUjJKOfrk2WcqaNsChb6RU13cljqTQ5Tyq/G0 O7bYaQ86YCDTST4A9hzw8xdCfvMRH3LUMwJ0Nuc0Tk9SlKluFTlbMt3B6 E=; IronPort-PHdr: =?us-ascii?q?9a23=3AUH2UjB1G6OSoFswusmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAAu80pd/4cNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBFS8kLANtVSAECyoKhBSDRwOLM4Jbl12BLoE?= =?us-ascii?q?kA1QJAQEBDAEBGAEKCgIBAYN6RQIXgjsjNQgOAQQBAQQBAQMBCm2FJwyFSgE?= =?us-ascii?q?BAQECAQEBEBEKEwEBLAsBBAcEAgEIEQQBAQEYCAcDAgICJQsUCQgCBA4FCBq?= =?us-ascii?q?DAYEdTQMODwECDKAuAoE4iGBxgTKCegEBBYUSGIIUAwaBNAGLYxeBQD+BV4J?= =?us-ascii?q?MPoJhAQGBKiEYKwkZgjwygiZ4izOCLyARhQaCL5RwCQKCHJQ+gjCWAo8BlkA?= =?us-ascii?q?CBAIEBQIOAQEFgVICNIFYcBU7gmyCQoNxhRSFP3KBKYsrAiICB4EEAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="scan'208,217";a="306369732" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 15:53:13 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x77FrDvY004316 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 15:53:13 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 10:53:12 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 10:53:11 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 10:53:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nht4rfetNKya5cfO3sTLB2iiK/YInFL9Yrofzqawm/sNtjGlHJdWoTkv2MYJ0YjsZ7BqpGO1fg220h3sz9w4YMcEN8ns+26VDsofDEZ+5WZKCEAqQlB/GvsUXybTcLbyWFANOnq8B88sLYEGxvBZ4Jvbc6HYECrgVME8OqlVLKUIAeLEoTDN1sj57iR/n2Um1kXjmgk3lfnnZ/fOEXhE4xedWVwMSiW4enowqDq76fE5XHEyKPqDsGQVG9C1vJPDtPhJe3gtO8QBDkDeXSWMDEownYiNVJlvn4NkeRcr+9UDklUL2+625XqltjJlcwU3UbI8AQr63CUCxLFfnVAvog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mvdusH39rimZ2psQW4Pi9wQJKitNmr9nTfBYdYFw9bQ=; b=eFas/KHOxCziGnHZ0TxN4rhBt1KdnSVZ1ejwo7N+HXdqb0IYQrxcE7lAKUEiiTyo6adY6ZdxypfXIlkzs2vTigVSx1wBPYN7xd/DGT7navWvn/HWd40EbKv9joNnq0qQy5najikACyeRfFZq3qoC5icS1PCsrcxAy8DwvEh0pHvopAMNVY1EgenR+Vj4MLOq/EETOvG1KtoWARxXzyPX1s/fRrxGAS1k7uzbEb3HcgPw+qRSB+JBBDj4MmHJ/vIALMhiqnsmj736GwvJZXLgafViYNBwyuATCZxngmpkLd4pGporEaFlYBYsR4owzQTbIXYOi6J69j9OW5oYDs9LRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mvdusH39rimZ2psQW4Pi9wQJKitNmr9nTfBYdYFw9bQ=; b=09juY2GleOkQs4QmSvZPC5M2drSgb9ijLeug1LpmCKVb7rv7DalZGt021Fd2vbwh5uy8g8bAyZVGe9gKzOoNRCQeypS8pJ+uZ5uLu1KjBcilG6yzR4jn9zNONo0XTHCJ8dp7vdGK45I8uX04MiHhFySc/WvKLEMKf9U1ETiYclc= Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2789.namprd11.prod.outlook.com (52.135.228.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Wed, 7 Aug 2019 15:53:10 +0000 Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428%4]) with mapi id 15.20.2136.018; Wed, 7 Aug 2019 15:53:10 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: Ladislav Lhotka , "Fengchong (frank)" , "netmod@ietf.org" , "Zhangxiaoping (C)" , liuzhiying Thread-Topic: [netmod] a question about 'when' Thread-Index: AdVLPM5Xmpgaa94hSz6Z+hOvCeCLfwANi6kAAD2D/oAAIoPxAAABScmgAA8qoIAAAB/6IA== Date: Wed, 7 Aug 2019 15:53:10 +0000 Message-ID: References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c962e889-63f1-4024-7544-08d71b4f591b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2789; x-ms-traffictypediagnostic: BYAPR11MB2789: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(53754006)(199004)(52314003)(189003)(13464003)(51444003)(25786009)(53546011)(14444005)(68736007)(9326002)(6916009)(256004)(6246003)(8936002)(11346002)(186003)(446003)(81166006)(81156014)(8676002)(33656002)(486006)(26005)(14454004)(3846002)(966005)(476003)(99286004)(102836004)(5660300002)(76176011)(606006)(6116002)(54906003)(7736002)(7696005)(6506007)(478600001)(74316002)(76116006)(71200400001)(52536014)(66476007)(66556008)(64756008)(66446008)(66946007)(71190400001)(790700001)(53936002)(229853002)(6306002)(2906002)(316002)(54896002)(4326008)(236005)(86362001)(66066001)(6436002)(55016002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2789; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UjBYlzll/xA6M2qhqG7veaIowvYtZd2cEmzr+2i2juvoAJp5OS9Pgtg1+fhqd11x/jLQa+qFF2DIR1lrQK8M39KD9mle+4zECr8oWiFW2zu/GM3MVyhCu1lZFtwBqJT8wbqAX6MhuWpljXzbIDym/FuPVeCwnwGiUFroKmouYUwcEvNz5ukLnTN9d0nZeA08DaHery2Iq04SPPq4q4hmLpPdlxQXiBi5MvjG+AS9/XnAc4reYqIfBcZ/rz+cAz2X4uqTTa1a0NJ3bs2QVLdcp4yfE2eShvdVQrPs213YmbCur4xtnQR0QOQVgREoigHq0LXokYSc7PDeB6ML5xVzYf5rL5hS66npUXSM+hudLFauBqjNV9ac0XTM6JpydWK2RnoSEpauUeYNNVv+0ZPMAZTdj/E3evI+qI17atFyCW0= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB26317E5F1ED33289D07AC440B5D40BYAPR11MB2631namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c962e889-63f1-4024-7544-08d71b4f591b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 15:53:10.6393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 15:53:28 -0000 --_000_BYAPR11MB26317E5F1ED33289D07AC440B5D40BYAPR11MB2631namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50 OiAwNyBBdWd1c3QgMjAxOSAxNjozMA0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9u QGNpc2NvLmNvbT4NCkNjOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+OyBGZW5nY2hv bmcgKGZyYW5rKSA8ZnJhbmsuZmVuZ2Nob25nQGh1YXdlaS5jb20+OyBuZXRtb2RAaWV0Zi5vcmc7 IFpoYW5neGlhb3BpbmcgKEMpIDx6aGFuZy54aWFvcGluZ0BodWF3ZWkuY29tPjsgbGl1emhpeWlu ZyA8bGl1emhpeWluZ0BodWF3ZWkuY29tPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGEgcXVlc3Rp b24gYWJvdXQgJ3doZW4nDQoNCg0KDQpPbiBXZWQsIEF1ZyA3LCAyMDE5IGF0IDI6MDcgQU0gUm9i IFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2Nv LmNvbT4+IHdyb3RlOg0KSSBjYW4gc2VlIHRoYXQgJ3doZW4gYXV0b21hdGljIGRlbGV0aW9uJyBw cm9jZXNzaW5nIGNhbiBiZSB1c2VmdWwgaWYgdGhlIGNvbmZpZ3VyYXRpb24gaXMgYmVpbmcgbWFu aXB1bGF0ZWQgYnkgYSBodW1hbi4gIEUuZy4gaWYgSSBkZWxldGUgYSBWUkYgdGhlbiBhbGwgdGhl IGNvbmZpZ3VyYXRpb24gdGhhdCByZWZlcmVuY2VzIHRoYXQgVlJGIGNhbiBtYWdpY2FsbHkgZGlz YXBwZWFyLiAgQXNzdW1pbmcgdGhlIHNlcnZlciBzdXBwb3J0cyBjb25maWcgcm9sbGJhY2sgdGhl biBldmVuIGlmIEkgbWFrZSBhIGNhdGFzdHJvcGhpYyBtaXN0YWtlLCBpdCBpc24ndCB1c3VhbGx5 IHRoYXQgaGFyZCB0byByZWNvdmVyIGZyb20uDQoNCkJ1dCBmb3IgYSBmdWxseSBhdXRvbWF0ZWQg Y2xpZW50LCB0aGVuIEkgYWdyZWUgd2l0aCBMYWRhLCBpbiB0aGF0IEkgc2VlIHRoZSBzZXJ2ZXIg c2lkZSAnd2hlbiBhdXRvbWF0aWMgZGVsZXRpb24nIHByb2Nlc3NpbmcgYXMgdW5oZWxwZnVsLiAg VGhlIGNsaWVudCBsb2dpY2FsbHkgbmVlZHMgdG8ga25vdy91bmRlcnN0YW5kIHRoZSBmdWxsIGNv bmZpZ3VyYXRpb24gYW55d2F5LCBzbyBpdCBzaG91bGQgYmUgYWJsZSB0byBnZW5lcmF0ZSB0aGUg Y29tcGxldGUgY29uZmlndXJhdGlvbiBjaGFuZ2UgcmVxdWlyZWQgdG8gdXBkYXRlIHRoZSBzZXJ2 ZXIgd2l0aCBhIG5ldyB2YWxpZCBjb25maWd1cmF0aW9uIHN0YXRlLiAgSW4gdGhlc2Ugc2NlbmFy aW9zLCBoYXZpbmcgdGhlIHNlcnZlciBwZXJmb3JtICd3aGVuIGF1dG9tYXRpYyBkZWxldGlvbicg cHJvY2Vzc2luZyBzZWVtcyB0byBpbmNyZWFzZSB0aGUgcmlzayB0aGF0IHRoYXQgY2xpZW50IGFu ZCBzZXJ2ZXIgdmlld3Mgb2YgdGhlIGNvbmZpZ3VyYXRpb24gY291bGQgZW5kIHVwIG91dCBvZiBz eW5jLiAgU29tZSBjbGllbnRzIHNpbXBsaWZ5IHRoZSBwcm90b2NvbCBvcGVyYXRpb25zIGJ5IGFs d2F5cyBkb2luZyBhIGNvbmZpZyByZXBsYWNlIG9uIGV2ZXJ5IGNvbmZpZyBjaGFuZ2UgdG8gZ3Vh cmFudGVlIHRoYXQgdGhlIGNvcHkgb2YgdGhlIGNvbmZpZ3VyYXRpb24gb24gdGhlIHNlcnZlciBt YXRjaGVzIHdoYXQgaXMgaW4gdGhlIGNsaWVudC4NCg0KRm9yIGNsaWVudHMgdGhhdCBleGlzdCBz b21ld2hlcmUgYmV0d2VlbiBubyBhdXRvbWF0aW9uIGFuZCBmdWxsIGF1dG9tYXRpb24sIHRoZW4g SSBjYW4gaW1hZ2luZSB0aGF0IGZvciBzb21lIGNhc2VzICd3aGVuIGF1dG9tYXRpYyBkZWxldGlv bicgcHJvY2Vzc2luZyBtaWdodCBiZSB1c2VmdWwsIGFuZCBvdGhlciBjYXNlcyB3aGVyZSBpdCBp cyB1bmhlbHBmdWwuDQoNCg0KSSBkb24ndCBzZWUgdGhlIGJpZyBkaXN0aW5jdGlvbiBiZXR3ZWVu IHR5cGVzIG9mIGNsaWVudHMuDQpZQU5HIGhhcyAyIG1lY2hhbmlzbXMgKG11c3QgYW5kIGxlYWZy ZWYpIHRoYXQgd2lsbCBjYXVzZSBhbiBlcnJvciBpbnN0ZWFkIG9mIGEgc2lsZW50IGRlbGV0aW9u Lg0KVGhlIHdoZW4tc3RtdCBpcyB1c2VkIHRvIGluZGljYXRlIHRoYXQgdGhlIHN1YnRyZWUgaXMg bm90IHJlbGV2YW50IHRvIHRoZSBtb2RlbCBpZiB0aGUgcmVzdWx0IGlzIGZhbHNlLg0KW1JXXQ0K VGhlIGRlZmluaXRpb24gb2YgYSDigJx3aGVu4oCdIHN0YXRlbWVudCBpcyBmaW5lIChpLmUuIHRo ZSBzdWJ0cmVlIGJlY29tZXMgaW52YWxpZCBpZiB0aGUg4oCYd2hlbuKAmSBjaGVjayBmYWlscyku ICBNeSBvbmx5IGlzc3VlIGlzIHdpdGggdGhlIGF1dG9tYXRpYyBkZWxldGlvbiBiZWhhdmlvdXIg dGhhdCBJIHRoaW5rIGlzIHVuaGVscGZ1bCBhdCB0aW1lcy4NCg0KWW91IGNhbiBlYXNpbHkgdXNl IG11c3Qtc3RtdCBpbnN0ZWFkIHRvIGNhdXNlIHRoZSBlcnJvciBiZWhhdmlvciBpbnN0ZWFkIG9m IGRlbGV0aW9uIGJlaGF2aW9yLg0KVGhpcyBzaG91bGQgYmUgcGFydCBvZiB0aGUgbW9kZWwgZGVz aWduLCBub3QgbGVmdCB1cCB0byBzZXJ2ZXIgZGV2ZWxvcGVycy4NCltSV10NCkJ1dCBhcyBhIGNs aWVudCBJIHdvdWxkIG5vdCB3YW50IHRoZSBzZXJ2ZXIgdG8gc2lsZW50bHkgcmVtb3ZlIGNvbmZp Z3VyYXRpb24gYmVjYXVzZSBhIHdoZW4gY29uZGl0aW9uIGJlY2FtZSBmYWxzZS4gIEluc3RlYWQs IEkgd291bGQgcmF0aGVyIGRvIGl0IGV4cGxpY2l0bHkgYW5kIGhhdmUgdGhlIHNlcnZlciByZXR1 cm4gYW4gZXJyb3Igc28gdGhhdCBJIGNhbiBmaXggdGhlIGJlaGF2aW91ciBvZiB0aGUgY2xpZW50 LiAgSWYgdGhlIGNsaWVudCBpcyBhd2FyZSBvZiB0aGUgc2NoZW1hIHRoZW4gaXQgY2FuIGFsc28g cHJ1bmUgY29uZmlnIGFzc29jaWF0ZWQgd2l0aCBmYWlsZWQgd2hlbiBjb25kaXRpb25zIGlmIGl0 IHdhbnRzLg0KDQpVbHRpbWF0ZWx5LCBteSBhaW0gYXMgYSBjbGllbnQgaXMgdG8gZ2V0IGEgY29t cGxldGUgY29uZmlndXJhdGlvbiBpbiB0aGUgY2xpZW50IGRvd24gdG8gdGhlIHNlcnZlciwgYW5k IHRvIGJlIHN1cmUgdGhhdCB0aGUgdHdvIGFyZSBjb25zaXN0ZW50LiAgVGhlIOKAmHdoZW4gYXV0 b21hdGljIGRlbGV0aW9u4oCZIGJlaGF2aW91ciBkb2VzbuKAmXQgaGVscCB3aXRoIHRoYXQsIGl0 IG1ha2VzIGl0IHJpc2tpZXIuICBBcyBtZW50aW9uZWQgcHJldmlvdXNseSwgdGhpcyBjYW4gYmUg bWl0aWdhdGVkIGJ5IGFsd2F5cyBzZW5kaW5nIHRoZSBlbnRpcmUgY29uZmlndXJhdGlvbiBkb3du IGFzIGEgY29uZmlnIHJlcGxhY2UsIGF0IHdoaWNoIHBvaW50IEkgd291bGQgcHJlc3VtZSB0aGF0 IHRoZSDigJh3aGVu4oCZIHN0YXRlbWVudHMgYXJlIGV2YWx1YXRlZCBlcXVpdmFsZW50bHkgdG8g 4oCYbXVzdOKAmSBzdGF0ZW1lbnRzIGFueXdheSDigJMgYWx0aG91Z2ggSeKAmW0gbm90IHN1cmUg d2hldGhlciBSRkMgNzk1MCBpcyBjbGVhciBvbiB0aGlzLg0KDQpQZXJzb25hbGx5LCBJIHdvdWxk IGhhdmUgcHJlZmVycmVkIHRoYXQgdGhlICd3aGVuIGF1dG9tYXRpYyBkZWxldGlvbicgcHJvY2Vz c2luZyB3YXMgY29udHJvbGxlZCB2aWEgYW4gZXhwbGljaXQgcHJvdG9jb2wgb3B0aW9uLCB3aXRo IHRoZSBkZWZhdWx0IGJlaGF2aW91ciB0byBqdXN0IHZhbGlkYXRlIHdoZW4gc3RhdGVtZW50cyAo ZXF1aXZhbGVudGx5IHRvIG11c3Qgc3RhdGVtZW50cykgYW5kIG5vdCBwZXJmb3JtIGFueSBhdXRv bWF0aWNhbGx5IGNvbmZpZyBkZWxldGlvbi4NCg0KVGhlcmUgaGFzIGJlZW4gbm90aGluZyBwcmV2 ZW50aW5nIGFueW9uZSBmcm9tIGF1Z21lbnRpbmcgdGhlIG9wZXJhdGlvbnMgdG8gdHVybiBvZmYg YXV0by1kZWxldGlvbi4NCklzIHRoaXMgd2lkZWx5IGltcGxlbWVudGVkPyAgSW1wbGVtZW50ZWQg YXQgYWxsPw0KW1JXXQ0KSSB0aGluayB0aGF0IGl0IGlzIGFzIExhZGEgc3RhdGVkLCBzb21lIHNl cnZlcnMganVzdCBkb27igJl0IGNoZWNrIG11c3Qgb3Igd2hlbiBzdGF0ZW1lbnRzIGF0IGFsbCwg b3IgZG9u4oCZdCBwZXJmb3JtIHRoZSBhdXRvbWF0aWMgZGVsZXRpb24uICBJ4oCZbSBub3QgYWR2 b2NhdGluZyB0aGF0IGlzIGEgZ29vZCBvciB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uICBUaGV5IGp1 c3QgZG9u4oCZdCBjb21wbHkgdG8gdGhhdCBwYXJ0IG9mIHRoZSBSRkMuDQoNClRoYW5rcywNClJv Yg0KDQoNCg0KVGhhbmtzLA0KUm9iDQoNCkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTGFkaXNsYXYgTGhvdGthDQpTZW50OiAw NyBBdWd1c3QgMjAxOSAwODozOQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t PG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgRmVuZ2Nob25nIChmcmFuaykgPGZyYW5rLmZl bmdjaG9uZ0BodWF3ZWkuY29tPG1haWx0bzpmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbT4+OyBu ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IFpoYW5neGlhb3BpbmcgKEMp IDx6aGFuZy54aWFvcGluZ0BodWF3ZWkuY29tPG1haWx0bzp6aGFuZy54aWFvcGluZ0BodWF3ZWku Y29tPj47IGxpdXpoaXlpbmcgPGxpdXpoaXlpbmdAaHVhd2VpLmNvbTxtYWlsdG86bGl1emhpeWlu Z0BodWF3ZWkuY29tPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhIHF1ZXN0aW9uIGFib3V0ICd3 aGVuJw0KDQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1h d29ya3MuY29tPj4gd3JpdGVzOg0KDQo+IE9uIE1vbiwgQXVnIDUsIDIwMTkgYXQgMjo0OSBBTSBM YWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMuY3o+PiB3cm90 ZToNCj4NCj4+ICJGZW5nY2hvbmcgKGZyYW5rKSIgPGZyYW5rLmZlbmdjaG9uZ0BodWF3ZWkuY29t PG1haWx0bzpmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbT4+IHdyaXRlczoNCj4+DQo+PiA+IEhp IGFsbCwNCj4+ID4NCj4+ID4gSSBlbmNvdW50ZXIgYSBxdWVzdGlvbiBhYm91dCAnd2hlbicsIHdo ZW4gSSBpbXBsZW1lbnQgeWFuZyBtb2RlbA0KPj4gYXNzb2NpYXRlZCB3aGVuIGNvbmRpdGlvbi4N Cj4+ID4NCj4+ID4gWWFuZyBtb2RlbDoNCj4+ID4NCj4+ID4gbGVhZiBwYXNzd29yZC10eXBlIHsN Cj4+ID4gICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+PiA+ICAgICAgIGVudW0gbnVsbDsNCj4+ID4g ICAgICAgZW51bSBzaW1wbGU7DQo+PiA+ICAgICAgIGVudW0gY2lwaGVyOw0KPj4gPiAgICB9DQo+ PiA+IH0NCj4+ID4NCj4+ID4gbGVhZiBwYXNzd29yZC10ZXh0IHsNCj4+ID4gdHlwZSBzdHJpbmc7 DQo+PiA+IHdoZW4gIi4uL3Bhc3N3b3JkLXR5cGUgIT0gbnVsbCI7DQo+PiA+IH0NCj4+ID4NCj4+ ID4gSSBjb25maWcgdGhlc2UgdHdvIGxlYWZzIGFzIGJlbG93Og0KPj4gPiA8cGFzc3dvcmQtdHlw ZT5zaW1wbGU8L3Bhc3N3b3JkLXR5cGU+DQo+PiA+IDxwYXNzd29yZC10ZXh0PjEyMzQ1NjwvcGFz c3dvcmQtdGV4dD4NCj4+ID4NCj4+ID4gQW5kIEkgY2hhbmdlZCBwYXNzd29yZC10eXBlIHRvIG51 bGwsIEkgZ2V0IHRoZSBjb25maWcgbGlrZSBiZWxvdzoNCj4+ID4gPHBhc3N3b3JkLXR5cGU+bnVs bDwvcGFzc3dvcmQtdHlwZT4NCj4+ID4NCj4+ID4gQW5kIHRoZW4sIEkgcmVjb25maWcgdGhlIHBh c3N3b3JkLXR5cGUgdG8gc2ltcGxlLCB3aGF0IGRhdGEgc2hvdWxkDQo+PiA+IGJlDQo+PiByZXR1 cm5lZD8NCj4+ID4NCj4+ID4gSXMNCj4+ID4gICA8cGFzc3dvcmQtdHlwZT5zaW1wbGU8L3Bhc3N3 b3JkLXR5cGU+DQo+Pg0KPj4gQWNjb3JkaW5nIHRvIFJGQyA3OTUwLCBzZWMuIDguMiwgdGhlIHNl cnZlciBkZWxldGVkICJwYXNzd29yZC10ZXh0Ig0KPj4gYWZ0ZXIgeW91IGNoYW5nZWQgInBhc3N3 b3JkLXR5cGUiIHRvIG51bGwgYnV0IHRoZSBvcmlnaW5hbCB2YWx1ZQ0KPj4gaXNuJ3QgcmVjb3Zl cmVkIGFmdGVyIHlvdSBjaGFuZ2UgdGhlIHR5cGUgYmFjay4NCj4+DQo+PiBUaGlzIHNlcnZlciBi ZWhhdmlvdXIgbWVhbnMgdGhhdCBhIHR5cG8gb3Igc2ltaWxhciB0cml2aWFsIGVycm9yIG1heQ0K Pj4gaGF2ZSBjYXRhc3Ryb3BoaWMgY29uc2VxdWVuY2VzIHN1Y2ggYXMgYXV0by1kZWxldGlvbiBv ZiBlbnRpcmUNCj4+IGNvbmZpZ3VyYXRpb24gc3VidHJlZXMuIFRoYXQncyB3aHkgb3VyIFJFU1RD T05GIGltcGxlbWVudGF0aW9uDQo+PiAoamV0Y29uZikgZG9lcyBzb21ldGhpbmcNCj4+IGVsc2U6 IGl0IHdvbid0IHBlcm1pdCB5b3UgdG8gY2hhbmdlICJwYXNzd29yZC10eXBlIiB0byBudWxsIGFz IGxvbmcNCj4+IGFzIHRoZSAicGFzc3dvcmQtdGV4dCIgZXhpc3RzLg0KPj4NCj4+DQo+IEl0IHNl ZW1zIG9kZCB0byBvcHRpbWl6ZSB0aGUgc2VydmVyIGZvciBjbGllbnQgbWlzdGFrZXMuDQoNClRo aXMgaXMganVzdCB0aGUgcHJpbmNpcGxlIG9mIGxlYXN0IGVtYmFycmFzc21lbnQuIFRoZSBwcm9i bGVtIGlzIHRoYXQgaXQgaXMgbm90IGluZGljYXRlZCBpbiB0aGUgZGF0YSBtb2RlbCB0aGF0IGRl bGV0aW5nIG9yIGNoYW5naW5nIHNvbWV0aGluZyBtYXkgaGF2ZSBmYXItcmVhY2hpbmcgY29uc2Vx dWVuY2VzLg0KDQo+IEl0IGlzIGZhciBtb3JlIGxpa2VseSAoOTkgdG8gMT8pIHRoYXQgdGhlIGNs aWVudCBrbm93cyB3aGF0IGl0IGlzDQo+IGRvaW5nIGFuZCBleHBlY3RzIHRoZSBzdGFuZGFyZCB0 byBiZSBmb2xsb3dlZC4gIENvbnNpZGVyIHRoZSBidXJkZW4gb24NCj4gdGhlIGNsaWVudCBkZWxl dGluZyBhbGwgdGhlICJmYWxzZS13aGVuIiBub2RlcyBtYW51YWxseS4gVGhpcyBpcw0KDQpJZiBp dCBpcyBhIHNpZ25pZmljYW50IGJ1cmRlbiwgdGhlbiBpdCdzIGFsc28gcXVpdGUgbGlrZWx5IHRo YXQgdGhlIGNsaWVudCBtYXkgbm90IGJlIGNvbXBsZXRlbHkgYXdhcmUgb2Ygd2hhdCdzIGdvaW5n IHRvIGJlIGF1dG8tZGVsZXRlZC4NCg0KPiBhbHNvIGluY29uc2lzdGVudCB3aXRoIHRoZSBzdGFu ZGFyZCBiZWhhdmlvciBmb3IgY2hvaWNlLXN0bXQgKG5ldyBjYXNlDQo+IGRlbGV0ZXMgdGhlIG9s ZCBjYXNlIGF1dG9tYXRpY2FsbHkpLg0KDQpUaGlzIGlzIHF1aXRlIGRpZmZlcmVudCBpbiB0aGF0 IHRoZSBpbXBhY3QgaXMgbG9jYWxpemVkOiBvbmUgY2FuIGVhc2lseSBzZWUgdGhhdCBhIGdpdmVu IGxlYWYgaXMgYSBjYXNlIGluIGEgY2hvaWNlIHNvIHRoYXQgaXQgY2Fubm90IGV4aXN0IGFsb25n IHdpdGggYW5vdGhlciBjYXNlLg0KDQpMYWRhDQoNCj4NCj4gTGFkYQ0KPj4NCj4+DQo+IEFuZHkN Cj4NCj4NCj4+ID4NCj4+ID4gT3INCj4+ID4NCj4+ID4gICA8cGFzc3dvcmQtdHlwZT5zaW1wbGU8 L3Bhc3N3b3JkLXR5cGU+DQo+PiA+ICAgPHBhc3N3b3JkLXRleHQ+MTIzNDU2PC9wYXNzd29yZC10 eXBlPg0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPg0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KPj4NCj4+IC0tDQo+PiBMYWRpc2xhdiBMaG90a2ENCj4+IEhlYWQsIENaLk5J QyBMYWJzDQo+PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0NCkxhZGlzbGF2 IExob3RrYQ0KSGVhZCwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2 Nw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K --_000_BYAPR11MB26317E5F1ED33289D07AC440B5D40BYAPR11MB2631namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFuZHksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBCaWVybWFuICZs dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMDcgQXVndXN0IDIw MTkgMTY6MzA8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9u QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IExhZGlzbGF2IExob3RrYSAmbHQ7bGhvdGth QG5pYy5jeiZndDs7IEZlbmdjaG9uZyAoZnJhbmspICZsdDtmcmFuay5mZW5nY2hvbmdAaHVhd2Vp LmNvbSZndDs7IG5ldG1vZEBpZXRmLm9yZzsgWmhhbmd4aWFvcGluZyAoQykgJmx0O3poYW5nLnhp YW9waW5nQGh1YXdlaS5jb20mZ3Q7OyBsaXV6aGl5aW5nICZsdDtsaXV6aGl5aW5nQGh1YXdlaS5j b20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBhIHF1ZXN0aW9uIGFib3V0 ICd3aGVuJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFdlZCwgQXVnIDcs IDIwMTkgYXQgMjowNyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCkkgY2FuIHNlZSB0aGF0ICd3aGVuIGF1dG9tYXRpYyBkZWxldGlvbicgcHJvY2Vz c2luZyBjYW4gYmUgdXNlZnVsIGlmIHRoZSBjb25maWd1cmF0aW9uIGlzIGJlaW5nIG1hbmlwdWxh dGVkIGJ5IGEgaHVtYW4uJm5ic3A7IEUuZy4gaWYgSSBkZWxldGUgYSBWUkYgdGhlbiBhbGwgdGhl IGNvbmZpZ3VyYXRpb24gdGhhdCByZWZlcmVuY2VzIHRoYXQgVlJGIGNhbiBtYWdpY2FsbHkgZGlz YXBwZWFyLiZuYnNwOyBBc3N1bWluZyB0aGUgc2VydmVyIHN1cHBvcnRzIGNvbmZpZw0KIHJvbGxi YWNrIHRoZW4gZXZlbiBpZiBJIG1ha2UgYSBjYXRhc3Ryb3BoaWMgbWlzdGFrZSwgaXQgaXNuJ3Qg dXN1YWxseSB0aGF0IGhhcmQgdG8gcmVjb3ZlciBmcm9tLjxicj4NCjxicj4NCkJ1dCBmb3IgYSBm dWxseSBhdXRvbWF0ZWQgY2xpZW50LCB0aGVuIEkgYWdyZWUgd2l0aCBMYWRhLCBpbiB0aGF0IEkg c2VlIHRoZSBzZXJ2ZXIgc2lkZSAnd2hlbiBhdXRvbWF0aWMgZGVsZXRpb24nIHByb2Nlc3Npbmcg YXMgdW5oZWxwZnVsLiZuYnNwOyBUaGUgY2xpZW50IGxvZ2ljYWxseSBuZWVkcyB0byBrbm93L3Vu ZGVyc3RhbmQgdGhlIGZ1bGwgY29uZmlndXJhdGlvbiBhbnl3YXksIHNvIGl0IHNob3VsZCBiZSBh YmxlIHRvIGdlbmVyYXRlIHRoZSBjb21wbGV0ZQ0KIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHJlcXVp cmVkIHRvIHVwZGF0ZSB0aGUgc2VydmVyIHdpdGggYSBuZXcgdmFsaWQgY29uZmlndXJhdGlvbiBz dGF0ZS4mbmJzcDsgSW4gdGhlc2Ugc2NlbmFyaW9zLCBoYXZpbmcgdGhlIHNlcnZlciBwZXJmb3Jt ICd3aGVuIGF1dG9tYXRpYyBkZWxldGlvbicgcHJvY2Vzc2luZyBzZWVtcyB0byBpbmNyZWFzZSB0 aGUgcmlzayB0aGF0IHRoYXQgY2xpZW50IGFuZCBzZXJ2ZXIgdmlld3Mgb2YgdGhlIGNvbmZpZ3Vy YXRpb24gY291bGQNCiBlbmQgdXAgb3V0IG9mIHN5bmMuJm5ic3A7IFNvbWUgY2xpZW50cyBzaW1w bGlmeSB0aGUgcHJvdG9jb2wgb3BlcmF0aW9ucyBieSBhbHdheXMgZG9pbmcgYSBjb25maWcgcmVw bGFjZSBvbiBldmVyeSBjb25maWcgY2hhbmdlIHRvIGd1YXJhbnRlZSB0aGF0IHRoZSBjb3B5IG9m IHRoZSBjb25maWd1cmF0aW9uIG9uIHRoZSBzZXJ2ZXIgbWF0Y2hlcyB3aGF0IGlzIGluIHRoZSBj bGllbnQuPGJyPg0KPGJyPg0KRm9yIGNsaWVudHMgdGhhdCBleGlzdCBzb21ld2hlcmUgYmV0d2Vl biBubyBhdXRvbWF0aW9uIGFuZCBmdWxsIGF1dG9tYXRpb24sIHRoZW4gSSBjYW4gaW1hZ2luZSB0 aGF0IGZvciBzb21lIGNhc2VzICd3aGVuIGF1dG9tYXRpYyBkZWxldGlvbicgcHJvY2Vzc2luZyBt aWdodCBiZSB1c2VmdWwsIGFuZCBvdGhlciBjYXNlcyB3aGVyZSBpdCBpcyB1bmhlbHBmdWwuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgZG9uJ3Qgc2VlIHRoZSBiaWcgZGlzdGluY3Rp b24gYmV0d2VlbiB0eXBlcyBvZiBjbGllbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WUFORyBo YXMgMiBtZWNoYW5pc21zIChtdXN0IGFuZCBsZWFmcmVmKSB0aGF0IHdpbGwgY2F1c2UgYW4gZXJy b3IgaW5zdGVhZCBvZiBhIHNpbGVudCBkZWxldGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRo ZSB3aGVuLXN0bXQgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzdWJ0cmVlIGlzIG5vdCBy ZWxldmFudCB0byB0aGUgbW9kZWwgaWYgdGhlIHJlc3VsdCBpcyBmYWxzZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV108bzpwPjwvbzpwPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRlZmluaXRpb24gb2YgYSDigJx3aGVu4oCdIHN0 YXRlbWVudCBpcyBmaW5lIChpLmUuIHRoZSBzdWJ0cmVlIGJlY29tZXMgaW52YWxpZCBpZiB0aGUg 4oCYd2hlbuKAmSBjaGVjayBmYWlscykuJm5ic3A7IE15IG9ubHkgaXNzdWUgaXMgd2l0aCB0aGUg YXV0b21hdGljIGRlbGV0aW9uIGJlaGF2aW91ciB0aGF0IEkgdGhpbmsgaXMgdW5oZWxwZnVsIGF0 IHRpbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Zb3UgY2FuIGVhc2ls eSB1c2UgbXVzdC1zdG10IGluc3RlYWQgdG8gY2F1c2UgdGhlIGVycm9yIGJlaGF2aW9yIGluc3Rl YWQgb2YgZGVsZXRpb24gYmVoYXZpb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIHNob3Vs ZCBiZSBwYXJ0IG9mIHRoZSBtb2RlbCBkZXNpZ24sIG5vdCBsZWZ0IHVwIHRvIHNlcnZlciBkZXZl bG9wZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+W1JXXTxv OnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgYXMgYSBjbGll bnQgSSB3b3VsZCBub3Qgd2FudCB0aGUgc2VydmVyIHRvIHNpbGVudGx5IHJlbW92ZSBjb25maWd1 cmF0aW9uIGJlY2F1c2UgYSB3aGVuIGNvbmRpdGlvbiBiZWNhbWUgZmFsc2UuJm5ic3A7IEluc3Rl YWQsIEkgd291bGQgcmF0aGVyIGRvIGl0IGV4cGxpY2l0bHkgYW5kIGhhdmUgdGhlIHNlcnZlciBy ZXR1cm4gYW4gZXJyb3Igc28gdGhhdCBJIGNhbiBmaXggdGhlIGJlaGF2aW91ciBvZiB0aGUgY2xp ZW50LiZuYnNwOw0KIElmIHRoZSBjbGllbnQgaXMgYXdhcmUgb2YgdGhlIHNjaGVtYSB0aGVuIGl0 IGNhbiBhbHNvIHBydW5lIGNvbmZpZyBhc3NvY2lhdGVkIHdpdGggZmFpbGVkIHdoZW4gY29uZGl0 aW9ucyBpZiBpdCB3YW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VWx0aW1hdGVseSwgbXkg YWltIGFzIGEgY2xpZW50IGlzIHRvIGdldCBhIGNvbXBsZXRlIGNvbmZpZ3VyYXRpb24gaW4gdGhl IGNsaWVudCBkb3duIHRvIHRoZSBzZXJ2ZXIsIGFuZCB0byBiZSBzdXJlIHRoYXQgdGhlIHR3byBh cmUgY29uc2lzdGVudC4mbmJzcDsgVGhlIOKAmHdoZW4gYXV0b21hdGljIGRlbGV0aW9u4oCZIGJl aGF2aW91ciBkb2VzbuKAmXQgaGVscCB3aXRoIHRoYXQsIGl0IG1ha2VzIGl0IHJpc2tpZXIuJm5i c3A7IEFzIG1lbnRpb25lZA0KIHByZXZpb3VzbHksIHRoaXMgY2FuIGJlIG1pdGlnYXRlZCBieSBh bHdheXMgc2VuZGluZyB0aGUgZW50aXJlIGNvbmZpZ3VyYXRpb24gZG93biBhcyBhIGNvbmZpZyBy ZXBsYWNlLCBhdCB3aGljaCBwb2ludCBJIHdvdWxkIHByZXN1bWUgdGhhdCB0aGUg4oCYd2hlbuKA mSBzdGF0ZW1lbnRzIGFyZSBldmFsdWF0ZWQgZXF1aXZhbGVudGx5IHRvIOKAmG11c3TigJkgc3Rh dGVtZW50cyBhbnl3YXkg4oCTIGFsdGhvdWdoIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgUkZDIDc5 NTANCiBpcyBjbGVhciBvbiB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+UGVyc29uYWxseSwgSSB3b3VsZCBoYXZlIHByZWZlcnJlZCB0aGF0IHRoZSAnd2hlbiBhdXRv bWF0aWMgZGVsZXRpb24nIHByb2Nlc3Npbmcgd2FzIGNvbnRyb2xsZWQgdmlhIGFuIGV4cGxpY2l0 IHByb3RvY29sIG9wdGlvbiwgd2l0aCB0aGUgZGVmYXVsdCBiZWhhdmlvdXIgdG8ganVzdCB2YWxp ZGF0ZSB3aGVuIHN0YXRlbWVudHMgKGVxdWl2YWxlbnRseSB0byBtdXN0DQogc3RhdGVtZW50cykg YW5kIG5vdCBwZXJmb3JtIGFueSBhdXRvbWF0aWNhbGx5IGNvbmZpZyBkZWxldGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZXJl IGhhcyBiZWVuIG5vdGhpbmcgcHJldmVudGluZyBhbnlvbmUgZnJvbSBhdWdtZW50aW5nIHRoZSBv cGVyYXRpb25zIHRvIHR1cm4gb2ZmIGF1dG8tZGVsZXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5JcyB0aGlzIHdpZGVseSBpbXBsZW1lbnRlZD8mbmJzcDsgSW1wbGVtZW50ZWQgYXQgYWxsPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+W1JXXSA8bzpwPjwvbzpw PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IGl0IGlzIGFz IExhZGEgc3RhdGVkLCBzb21lIHNlcnZlcnMganVzdCBkb27igJl0IGNoZWNrIG11c3Qgb3Igd2hl biBzdGF0ZW1lbnRzIGF0IGFsbCwgb3IgZG9u4oCZdCBwZXJmb3JtIHRoZSBhdXRvbWF0aWMgZGVs ZXRpb24uJm5ic3A7IEnigJltIG5vdCBhZHZvY2F0aW5nIHRoYXQgaXMgYSBnb29kIG9yIHRoZSBy aWdodCB0aGluZyB0byBkby4mbmJzcDsgVGhleSBqdXN0IGRvbuKAmXQgY29tcGx5IHRvIHRoYXQg cGFydA0KIG9mIHRoZSBSRkMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8YnI+DQpUaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BbmR5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCkZyb206IG5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBPbiBCZWhhbGYgT2YgTGFkaXNsYXYgTGhvdGthPGJyPg0KU2VudDogMDcgQXVndXN0IDIw MTkgMDg6Mzk8YnI+DQpUbzogQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs7 IEZlbmdjaG9uZyAoZnJhbmspICZsdDs8YSBocmVmPSJtYWlsdG86ZnJhbmsuZmVuZ2Nob25nQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbTwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5l dG1vZEBpZXRmLm9yZzwvYT47IFpoYW5neGlhb3BpbmcgKEMpICZsdDs8YSBocmVmPSJtYWlsdG86 emhhbmcueGlhb3BpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnpoYW5nLnhpYW9waW5n QGh1YXdlaS5jb208L2E+Jmd0OzsgbGl1emhpeWluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpdXpo aXlpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpdXpoaXlpbmdAaHVhd2VpLmNvbTwv YT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGEgcXVlc3Rpb24gYWJvdXQgJ3doZW4n PGJyPg0KPGJyPg0KQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29y a3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JpdGVz Ojxicj4NCjxicj4NCiZndDsgT24gTW9uLCBBdWcgNSwgMjAxOSBhdCAyOjQ5IEFNIExhZGlzbGF2 IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdldD0iX2JsYW5r Ij5saG90a2FAbmljLmN6PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7ICZx dW90O0ZlbmdjaG9uZyAoZnJhbmspJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZnJhbmsuZmVu Z2Nob25nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmFuay5mZW5nY2hvbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyaXRlczo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgSGkg YWxsLDxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkgZW5jb3VudGVyIGEg cXVlc3Rpb24gYWJvdXQgJ3doZW4nLCB3aGVuIEkgaW1wbGVtZW50IHlhbmcgbW9kZWw8YnI+DQom Z3Q7Jmd0OyBhc3NvY2lhdGVkIHdoZW4gY29uZGl0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IFlhbmcgbW9kZWw6PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsgbGVhZiBwYXNzd29yZC10eXBlIHs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyB0eXBlIGVudW1lcmF0aW9uIHs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZW51bSBudWxsOzxicj4NCiZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtlbnVtIHNpbXBsZTs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZW51bSBjaXBoZXI7PGJyPg0KJmd0OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsg fTxicj4NCiZndDsmZ3Q7ICZndDsgfTxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7IGxlYWYgcGFzc3dvcmQtdGV4dCB7PGJyPg0KJmd0OyZndDsgJmd0OyB0eXBlIHN0cmluZzs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHdoZW4gJnF1b3Q7Li4vcGFzc3dvcmQtdHlwZSAhPSBudWxsJnF1 b3Q7Ozxicj4NCiZndDsmZ3Q7ICZndDsgfTxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IEkgY29uZmlnIHRoZXNlIHR3byBsZWFmcyBhcyBiZWxvdzo8YnI+DQomZ3Q7Jmd0OyAm Z3Q7ICZsdDtwYXNzd29yZC10eXBlJmd0O3NpbXBsZSZsdDsvcGFzc3dvcmQtdHlwZSZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7ICZsdDtwYXNzd29yZC10ZXh0Jmd0OzEyMzQ1NiZsdDsvcGFzc3dvcmQt dGV4dCZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBBbmQgSSBjaGFu Z2VkIHBhc3N3b3JkLXR5cGUgdG8gbnVsbCwgSSBnZXQgdGhlIGNvbmZpZyBsaWtlIGJlbG93Ojxi cj4NCiZndDsmZ3Q7ICZndDsgJmx0O3Bhc3N3b3JkLXR5cGUmZ3Q7bnVsbCZsdDsvcGFzc3dvcmQt dHlwZSZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBBbmQgdGhlbiwg SSByZWNvbmZpZyB0aGUgcGFzc3dvcmQtdHlwZSB0byBzaW1wbGUsIHdoYXQgZGF0YSBzaG91bGQg PGJyPg0KJmd0OyZndDsgJmd0OyBiZTxicj4NCiZndDsmZ3Q7IHJldHVybmVkPzxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IElzPGJyPg0KJmd0OyZndDsgJmd0OyZuYnNwOyAm bmJzcDsmbHQ7cGFzc3dvcmQtdHlwZSZndDtzaW1wbGUmbHQ7L3Bhc3N3b3JkLXR5cGUmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBY2NvcmRpbmcgdG8gUkZDIDc5NTAsIHNlYy4gOC4y LCB0aGUgc2VydmVyIGRlbGV0ZWQgJnF1b3Q7cGFzc3dvcmQtdGV4dCZxdW90OyA8YnI+DQomZ3Q7 Jmd0OyBhZnRlciB5b3UgY2hhbmdlZCAmcXVvdDtwYXNzd29yZC10eXBlJnF1b3Q7IHRvIG51bGwg YnV0IHRoZSBvcmlnaW5hbCB2YWx1ZSA8YnI+DQomZ3Q7Jmd0OyBpc24ndCByZWNvdmVyZWQgYWZ0 ZXIgeW91IGNoYW5nZSB0aGUgdHlwZSBiYWNrLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg VGhpcyBzZXJ2ZXIgYmVoYXZpb3VyIG1lYW5zIHRoYXQgYSB0eXBvIG9yIHNpbWlsYXIgdHJpdmlh bCBlcnJvciBtYXkgPGJyPg0KJmd0OyZndDsgaGF2ZSBjYXRhc3Ryb3BoaWMgY29uc2VxdWVuY2Vz IHN1Y2ggYXMgYXV0by1kZWxldGlvbiBvZiBlbnRpcmUgPGJyPg0KJmd0OyZndDsgY29uZmlndXJh dGlvbiBzdWJ0cmVlcy4gVGhhdCdzIHdoeSBvdXIgUkVTVENPTkYgaW1wbGVtZW50YXRpb24gPGJy Pg0KJmd0OyZndDsgKGpldGNvbmYpIGRvZXMgc29tZXRoaW5nPGJyPg0KJmd0OyZndDsgZWxzZTog aXQgd29uJ3QgcGVybWl0IHlvdSB0byBjaGFuZ2UgJnF1b3Q7cGFzc3dvcmQtdHlwZSZxdW90OyB0 byBudWxsIGFzIGxvbmcgPGJyPg0KJmd0OyZndDsgYXMgdGhlICZxdW90O3Bhc3N3b3JkLXRleHQm cXVvdDsgZXhpc3RzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IEl0IHNl ZW1zIG9kZCB0byBvcHRpbWl6ZSB0aGUgc2VydmVyIGZvciBjbGllbnQgbWlzdGFrZXMuPGJyPg0K PGJyPg0KVGhpcyBpcyBqdXN0IHRoZSBwcmluY2lwbGUgb2YgbGVhc3QgZW1iYXJyYXNzbWVudC4g VGhlIHByb2JsZW0gaXMgdGhhdCBpdCBpcyBub3QgaW5kaWNhdGVkIGluIHRoZSBkYXRhIG1vZGVs IHRoYXQgZGVsZXRpbmcgb3IgY2hhbmdpbmcgc29tZXRoaW5nIG1heSBoYXZlIGZhci1yZWFjaGlu ZyBjb25zZXF1ZW5jZXMuPGJyPg0KPGJyPg0KJmd0OyBJdCBpcyBmYXIgbW9yZSBsaWtlbHkgKDk5 IHRvIDE/KSB0aGF0IHRoZSBjbGllbnQga25vd3Mgd2hhdCBpdCBpcyA8YnI+DQomZ3Q7IGRvaW5n IGFuZCBleHBlY3RzIHRoZSBzdGFuZGFyZCB0byBiZSBmb2xsb3dlZC4mbmJzcDsgQ29uc2lkZXIg dGhlIGJ1cmRlbiBvbiA8YnI+DQomZ3Q7IHRoZSBjbGllbnQgZGVsZXRpbmcgYWxsIHRoZSAmcXVv dDtmYWxzZS13aGVuJnF1b3Q7IG5vZGVzIG1hbnVhbGx5LiBUaGlzIGlzPGJyPg0KPGJyPg0KSWYg aXQgaXMgYSBzaWduaWZpY2FudCBidXJkZW4sIHRoZW4gaXQncyBhbHNvIHF1aXRlIGxpa2VseSB0 aGF0IHRoZSBjbGllbnQgbWF5IG5vdCBiZSBjb21wbGV0ZWx5IGF3YXJlIG9mIHdoYXQncyBnb2lu ZyB0byBiZSBhdXRvLWRlbGV0ZWQuPGJyPg0KPGJyPg0KJmd0OyBhbHNvIGluY29uc2lzdGVudCB3 aXRoIHRoZSBzdGFuZGFyZCBiZWhhdmlvciBmb3IgY2hvaWNlLXN0bXQgKG5ldyBjYXNlIDxicj4N CiZndDsgZGVsZXRlcyB0aGUgb2xkIGNhc2UgYXV0b21hdGljYWxseSkuPGJyPg0KPGJyPg0KVGhp cyBpcyBxdWl0ZSBkaWZmZXJlbnQgaW4gdGhhdCB0aGUgaW1wYWN0IGlzIGxvY2FsaXplZDogb25l IGNhbiBlYXNpbHkgc2VlIHRoYXQgYSBnaXZlbiBsZWFmIGlzIGEgY2FzZSBpbiBhIGNob2ljZSBz byB0aGF0IGl0IGNhbm5vdCBleGlzdCBhbG9uZyB3aXRoIGFub3RoZXIgY2FzZS48YnI+DQo8YnI+ DQpMYWRhPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgTGFkYTxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7IEFuZHk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE9yPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7Jmx0O3Bhc3N3b3JkLXR5cGUmZ3Q7c2ltcGxlJmx0Oy9wYXNz d29yZC10eXBlJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jmx0O3Bhc3N3b3Jk LXRleHQmZ3Q7MTIzNDU2Jmx0Oy9wYXNzd29yZC10eXBlJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg LS08YnI+DQomZ3Q7Jmd0OyBMYWRpc2xhdiBMaG90a2E8YnI+DQomZ3Q7Jmd0OyBIZWFkLCBDWi5O SUMgTGFiczxicj4NCiZndDsmZ3Q7IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5l dG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2Q8L2E+PGJyPg0KPGJyPg0KLS08YnI+DQpMYWRpc2xhdiBMaG90a2E8YnI+DQpIZWFkLCBDWi5O SUMgTGFiczxicj4NClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nzxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9k IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BYAPR11MB26317E5F1ED33289D07AC440B5D40BYAPR11MB2631namp_-- From nobody Thu Aug 8 06:40:47 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A724120127; Thu, 8 Aug 2019 06:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ9Z0tRF8ZYZ; Thu, 8 Aug 2019 06:40:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD021201A2; Thu, 8 Aug 2019 06:40:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B85EBB800A7; Thu, 8 Aug 2019 06:40:02 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, lhotka@nic.cz X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ibagdona@gmail.com, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190808134002.B85EBB800A7@rfc-editor.org> Date: Thu, 8 Aug 2019 06:40:02 -0700 (PDT) Archived-At: Subject: [netmod] [Errata Verified] RFC8528 (5797) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 13:40:38 -0000 The following errata report has been verified for RFC8528, "YANG Schema Mount". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5797 -------------------------------------- Status: Verified Type: Editorial Reported by: Andy Bierman Date Reported: 2019-07-29 Verified by: Ignas Bagdonas (IESG) Section: A.2 Original Text ------------- { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "enabled": true, "ietf-logical-network-element:bind-lne-name": "eth0" } ] }, Corrected Text -------------- { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "enabled": true, "ietf-logical-network-element:bind-lne-name": "lne-1" } ] }, Notes ----- leafref is for an LNE name, not an interface name -------------------------------------- RFC8528 (draft-ietf-netmod-schema-mount-12) -------------------------------------- Title : YANG Schema Mount Publication Date : March 2019 Author(s) : M. Bjorklund, L. Lhotka Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Aug 9 03:24:46 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46DB12011A for ; Fri, 9 Aug 2019 03:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wvLJ6HZsVbm for ; Fri, 9 Aug 2019 03:24:43 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60118.outbound.protection.outlook.com [40.107.6.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B51120118 for ; Fri, 9 Aug 2019 03:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lE5UCm7rnXeG4dsDZH+p5WBglaOL3dySOO5zcAFAxwXAzM0Gl1hzmOJDABbRz/A2pdRUJIEcNk+A1KvJrWJJgeaHq9IVs+a6G1AXLh4E4sl3ux8YZA2Lj0dGc7IBo+fX0iQyhFuzbyjNobgIMk8Da6/E5rLFYVYiBTzER/wjImnXHYkQ/hgKxmdI8L8yxu22lKIViu1Dc7EZiC/eWm2Ns/xOMnozwJ7jOIfywCufzcxb1EFJV8r1+dTmwa8XgbR93Cd52ggx6A8499+vol6T+1I/vR8eH5mlET6QqYb8qJyiU0KNuaWpW9y6AJWTVKpTDJ25DrGajVxvV4neMuiceQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lUgHvGJd/4/ygf/ajWRtOQa7WcZqxmoTAlFc20JTuIo=; b=LvUlvBSI14Qmt9Usn1UnuUuWnZHqdPld4GJO++KzAzoTEe9/U43eKXaIWhen8cKgxxIyApuD9NRv+UwQ+isXlpHRZOjjSYLL+HswTVwyV097eXWO8HtRXuRGlSyLC/JvRFcnKAD8usm98X7KgnzNoJ0/cutaK6ArmPjT0RwoMiYK9XiAVzz8UV10oHwosLGBsDVncONTWmUp/hpstcwmtNEb1xebX4Vr6lXnrtv+bqXC+hfNNAK0p6W43g449+w534IruEiD2U6fLmnZGz3TyRsH7YZLQyXhOMuHGto3Gi6tK8nMlGUxasN2R9nxC8Dx5L5qMNNxjqeI/n2F4PiBoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lUgHvGJd/4/ygf/ajWRtOQa7WcZqxmoTAlFc20JTuIo=; b=kRnD/2+ypucS3MqKnwLg10o15KQvCLxPLBzLa9v3467b86vowmI0DMSWjAMYE15kslSBbzThLJP689W9xE9uVIvf9vac5VagsWkoORP8x1AKOsfW4WO7KJsUrJUxmt3qiZfei5zFBcHMpzcwC+OCoaNahVihmcKrGxs5MK8fY2I= Received: from AM6PR07MB6072.eurprd07.prod.outlook.com (20.178.95.153) by AM6PR07MB5875.eurprd07.prod.outlook.com (20.177.189.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.11; Fri, 9 Aug 2019 10:24:40 +0000 Received: from AM6PR07MB6072.eurprd07.prod.outlook.com ([fe80::61d0:220c:6e6f:16b8]) by AM6PR07MB6072.eurprd07.prod.outlook.com ([fe80::61d0:220c:6e6f:16b8%5]) with mapi id 15.20.2157.020; Fri, 9 Aug 2019 10:24:40 +0000 From: tom petch To: Kent Watsen , RFC Errata System CC: Andy Bierman , "netmod@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC8407 (5800) Thread-Index: AQHVTpymSvgmt35AXU6t0PMwj+XHvg== Date: Fri, 9 Aug 2019 10:24:40 +0000 Message-ID: <050601d54e9c$87e51660$4001a8c0@gateway.2wire.net> References: <20190731143642.93F8CB8159B@rfc-editor.org> <0100016c48bdd421-702f0715-fae8-47c8-aa69-28c7dc6af3d0-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::23) To AM6PR07MB6072.eurprd07.prod.outlook.com (2603:10a6:20b:9f::25) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2136cf5-6445-4e00-1c33-08d71cb3c94b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR07MB5875; x-ms-traffictypediagnostic: AM6PR07MB5875: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(136003)(366004)(376002)(189003)(199004)(13464003)(8676002)(81156014)(8936002)(50226002)(66946007)(81166006)(4326008)(66446008)(25786009)(66556008)(66476007)(478600001)(64756008)(4720700003)(966005)(14454004)(256004)(71200400001)(5660300002)(71190400001)(61296003)(446003)(26005)(186003)(14496001)(86362001)(53936002)(66066001)(486006)(476003)(6116002)(110136005)(316002)(7736002)(62236002)(44716002)(305945005)(54906003)(3846002)(229853002)(6246003)(102836004)(53546011)(6506007)(386003)(2906002)(44736005)(52116002)(81686011)(81816011)(76176011)(99286004)(6306002)(6486002)(6436002)(6512007)(1556002)(9686003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5875; H:AM6PR07MB6072.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lRS37+LwB83Lw0vjZkzE6ljDzqtspto1l/1P2Gx69sLO1/EmKwfTnK8u9EB1KOYZn2Tv8i/TjEW519kEfW1wO0Fg4WTVKO1HvZmQEhlZjst5INGY7uBsBw0IHAIKwFiVPE2HJ4C7oa0mLMUKD66Udm5iDHa14L6+9qwJCCtNKWTIHQmOB2vcnyw9N+tinm742DoloOV/s5eQl14wbkb1YFjMR36e+NkICbXMAAcs80IrPcxSKw5T33c7UTe8XrjP4png8SdNSaPYoVursvvChGwFRsJj/pZ5uUTkJ9nicyXGEURWtjsj2eJIdsxjcFUO1SNBdZaZVCa3dlNcoxccNNxVSyo8j2/k9ddSCF49VwCRXoh64MEq+FDmgDIdDn7qSMNDLmAqeXX6sBbYlZsQ62TcmSd4LQRsDtHbK6U36bQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <397BD86AD1AF1F4095939EF3AEEC57F4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2136cf5-6445-4e00-1c33-08d71cb3c94b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 10:24:40.0169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FzyNBjgpraoigjiCRYPQT4XceM7cIlVCZBKt4To3cOnzC8jXuAlKDEKs+3f79MOsftczDQGiS1kbfqS4MhCVgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5875 Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC8407 (5800) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 10:24:46 -0000 Andy As author of RFC8407, I wonder what your thoughts are on this. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "RFC Errata System" Cc: "Andy Bierman" ; "Ignas Bagdonas" ; "Warren Kumari" ; "Joel Jaeggli" ; "Lou Berger" ; "tom petch" ; Sent: Wednesday, July 31, 2019 4:54 PM Subject: Re: [Editorial Errata Reported] RFC8407 (5800) This errata should be accepted. Kent > On Jul 31, 2019, at 10:36 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC8407, > "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5800 > > -------------------------------------- > Type: Editorial > Reported by: tom Petch > > Section: appendix b > > Original Text > ------------- > "WG Web: > ..... > (http://trustee.ietf.org/license-info). > > > Corrected Text > -------------- > "WG Web: > ..... > (https://trustee.ietf.org/license-info). > > > Notes > ----- > Appendix A rightly says that these URL should have a scheme of https: > but Appendix B wrongly specifies http: > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8407 (draft-ietf-netmod-rfc6087bis-20) > -------------------------------------- > Title : Guidelines for Authors and Reviewers of Documents Containing YANG Data Models > Publication Date : October 2018 > Author(s) : A. Bierman > Category : BEST CURRENT PRACTICE > Source : Network Modeling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From nobody Fri Aug 9 04:03:13 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71ED120128 for ; Fri, 9 Aug 2019 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jHucMwwryAs for ; Fri, 9 Aug 2019 04:03:10 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 A34391200E0 for ; Fri, 9 Aug 2019 04:03:09 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t3so3167142ljj.12 for ; Fri, 09 Aug 2019 04:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NvwScnRagb22qufVAHyQnazOZ7vkaWYX6sRs2REUz4w=; b=i5udWLHH0/cJ8QdjWO/gVuChvgYAnZzRWdUAFjQmI3z7MZ/BoVee6kCMlRsiOnVUpE mZk2mW+aNlcCNIjbtsaniIjd2/GEMbW71LRSMb8qcS5inpDqH6nDWKhW12i2tunolDYU sgpCHCvt7CGCGt/hXmGg/4N+KOPChbyBXZ4pjfYJH9QyS2oN3B2m51+jzN+5Y/Pdg2su +yXyiRGhMv53XLEXItUUA0nAVFpRrPfqLnYXt4K3x3zmt61imI2nd9qnjHMJcTkX2Opf tP6unam+kPywUPvNb/NlQu6zwWx0dhg4ngtUXzLtCVI8h5Bj5LOBanU6uvEb2h25dwDF XY0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NvwScnRagb22qufVAHyQnazOZ7vkaWYX6sRs2REUz4w=; b=eF/tGA7WtKmMM9i2fWNSch+w/u8g74MKQiVkShsOSUkzuC1g6gC5+JIHGsdY3NTkgP JZROC86t+wUC12fr7TM0NDw+s6RHutbUGjcf0DRdNVDK+ibM3mSJyDU+UtOUp6qmQPob tJ8FkwV68orLSkUvESE7dpBO0L6c6FSNw1ephpM9Zy9lzfoFcQrGPg0ytBPQzZNawX5x 98H6A7FwCoY7/9gRwWW5v8N+xx+L7G0+MF1ooJy3XrQpxBvmPJBU6sCgYZZR2p1okHm6 r2PXpj4VAWdfVYqJtI8OiGhDERPp2VQsIpMGmLi+ZlRut29K896ZxI2J9Sh1AS8s+M0Q wMIg== X-Gm-Message-State: APjAAAWWCEapIyx40NPEzxO4HDnZ/MjsN/It2cBtEbVFvQGp9Pf1aMf5 yfnYtEvk68bWG23Cpgz+MjAXGY0HHnRbH+xr2XpqQA== X-Google-Smtp-Source: APXvYqzOJAzIj+smIqf3TqG7rxjiydCuzK7Dk1Sa0DrWzLfKJ6Qx/MMpV4CPlAURGwYoVQd0N+LXB9pK/JHQ+uyvp1k= X-Received: by 2002:a2e:86cc:: with SMTP id n12mr10855471ljj.146.1565348587792; Fri, 09 Aug 2019 04:03:07 -0700 (PDT) MIME-Version: 1.0 References: <20190731143642.93F8CB8159B@rfc-editor.org> <0100016c48bdd421-702f0715-fae8-47c8-aa69-28c7dc6af3d0-000000@email.amazonses.com> <050601d54e9c$87e51660$4001a8c0@gateway.2wire.net> In-Reply-To: <050601d54e9c$87e51660$4001a8c0@gateway.2wire.net> From: Andy Bierman Date: Fri, 9 Aug 2019 04:02:56 -0700 Message-ID: To: tom petch Cc: Kent Watsen , RFC Errata System , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000867f26058fad1e38" Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC8407 (5800) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 11:03:13 -0000 --000000000000867f26058fad1e38 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 9, 2019 at 3:24 AM tom petch wrote: > Andy > > As author of RFC8407, I wonder what your thoughts are on this. > > Not sure why this is a problem. The IETF decided to change http to https in its WEB pages so the template is being updated to reflect that. Tom Petch > > Andy > ----- Original Message ----- > From: "Kent Watsen" > To: "RFC Errata System" > Cc: "Andy Bierman" ; "Ignas Bagdonas" > ; "Warren Kumari" ; "Joel > Jaeggli" ; "Lou Berger" ; "tom > petch" ; > Sent: Wednesday, July 31, 2019 4:54 PM > Subject: Re: [Editorial Errata Reported] RFC8407 (5800) > > > This errata should be accepted. > > Kent > > > > On Jul 31, 2019, at 10:36 AM, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC8407, > > "Guidelines for Authors and Reviewers of Documents Containing YANG > Data Models". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5800 > > > > -------------------------------------- > > Type: Editorial > > Reported by: tom Petch > > > > Section: appendix b > > > > Original Text > > ------------- > > "WG Web: > > ..... > > (http://trustee.ietf.org/license-info). > > > > > > Corrected Text > > -------------- > > "WG Web: > > ..... > > (https://trustee.ietf.org/license-info). > > > > > > Notes > > ----- > > Appendix A rightly says that these URL should have a scheme of https: > > but Appendix B wrongly specifies http: > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8407 (draft-ietf-netmod-rfc6087bis-20) > > -------------------------------------- > > Title : Guidelines for Authors and Reviewers of > Documents Containing YANG Data Models > > Publication Date : October 2018 > > Author(s) : A. Bierman > > Category : BEST CURRENT PRACTICE > > Source : Network Modeling > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > --000000000000867f26058fad1e38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 9, 2019 at 3:24 AM tom pe= tch <daedulus@btconnect.com> wrote:
And= y

As author of RFC8407, I wonder what your thoughts are on this.


<= div>The IETF decided to change http to https in its WEB pages so the templa= te is being updated

Tom Petch


----- Original Message -----
From: "Kent Watsen" <kent+ietf@watsen.net>
To: "RFC Errata System" <rfc-editor@rfc-editor.org>
Cc: "Andy Bierman" <andy@yumaworks.com>; "Ignas Bagdonas"
<ibagdona@gmail.= com>; "Warren Kumari" <warren@kumari.net>; "Joel
Jaeggli" <joe= lja@bogus.com>; "Lou Berger" <lberger@labn.net>; "tom
petch" <daedulus@btconnect.com>; <netmod@ietf.org>
Sent: Wednesday, July 31, 2019 4:54 PM
Subject: Re: [Editorial Errata Reported] RFC8407 (5800)


This errata should be accepted.

Kent


> On Jul 31, 2019, at 10:36 AM, RFC Errata System
<rfc-edit= or@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC8407,
> "Guidelines for Authors and Reviewers of Documents Containing YAN= G
Data Models".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5800
>
> --------------------------------------
> Type: Editorial
> Reported by: tom Petch <daedulus@btconnect.com>
>
> Section: appendix b
>
> Original Text
> -------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"WG Web:=C2=A0 =C2=A0<http://datatracker.ietf.org/wg/your-wg-name/>
> .....
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (http://trustee.ietf.org/license= -info).
>
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"WG Web:=C2=A0 =C2=A0<https://datatracker.ietf.org/wg/your-wg-name/>
> .....
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (https://trustee.ietf.org/licen= se-info).
>
>
> Notes
> -----
> Appendix A rightly says that these URL should have a scheme of https:<= br> > but Appendix B wrongly specifies http:
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Guidelin= es for Authors and Reviewers of
Documents Containing YANG Data Models
> Publication Date=C2=A0 =C2=A0 : October 2018
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : BEST CURRENT PRACT= ICE
> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Model= ing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--000000000000867f26058fad1e38-- From nobody Fri Aug 9 05:08:06 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA8C120132 for ; Fri, 9 Aug 2019 05:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 gf_atiOZPi0K for ; Fri, 9 Aug 2019 05:08:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C874A120140 for ; Fri, 9 Aug 2019 05:08:00 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 9398218201CB; Fri, 9 Aug 2019 14:10:08 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 9B37518201C5; Fri, 9 Aug 2019 14:10:03 +0200 (CEST) From: Ladislav Lhotka To: "Rob Wilton \(rwilton\)" , Andy Bierman Cc: "Fengchong \(frank\)" , "netmod\@ietf.org" , "Zhangxiaoping \(C\)" , liuzhiying In-Reply-To: References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <8736ide87b.fsf@nic.cz> Mail-Followup-To: "Rob Wilton \(rwilton\)" , Andy Bierman , "Fengchong \(frank\)" , "netmod\@ietf.org" , "Zhangxiaoping \(C\)" , liuzhiying Date: Fri, 09 Aug 2019 14:07:54 +0200 Message-ID: <87mugiee3p.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] a question about 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 12:08:04 -0000 "Rob Wilton (rwilton)" writes: > Hi Andy, > > From: Andy Bierman > Sent: 07 August 2019 16:30 > To: Rob Wilton (rwilton) > Cc: Ladislav Lhotka ; Fengchong (frank) ; netmod@ietf.org; Zhangxiaoping (C) ;= liuzhiying > Subject: Re: [netmod] a question about 'when' > > > > On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) > wrote: > I can see that 'when automatic deletion' processing can be useful if the = configuration is being manipulated by a human. E.g. if I delete a VRF then= all the configuration that references that VRF can magically disappear. A= ssuming the server supports config rollback then even if I make a catastrop= hic mistake, it isn't usually that hard to recover from. > > But for a fully automated client, then I agree with Lada, in that I see t= he server side 'when automatic deletion' processing as unhelpful. The clie= nt logically needs to know/understand the full configuration anyway, so it = should be able to generate the complete configuration change required to up= date the server with a new valid configuration state. In these scenarios, = having the server perform 'when automatic deletion' processing seems to inc= rease the risk that that client and server views of the configuration could= end up out of sync. Some clients simplify the protocol operations by alwa= ys doing a config replace on every config change to guarantee that the copy= of the configuration on the server matches what is in the client. > > For clients that exist somewhere between no automation and full automatio= n, then I can imagine that for some cases 'when automatic deletion' process= ing might be useful, and other cases where it is unhelpful. > > > I don't see the big distinction between types of clients. > YANG has 2 mechanisms (must and leafref) that will cause an error instead= of a silent deletion. > The when-stmt is used to indicate that the subtree is not relevant to the= model if the result is false. > [RW] > The definition of a =E2=80=9Cwhen=E2=80=9D statement is fine (i.e. the su= btree becomes invalid if the =E2=80=98when=E2=80=99 check fails). My only = issue is with the automatic deletion behaviour that I think is unhelpful at= times. On the other hand, the "when" statement is so dangerous and tricky exactly = because it is so powerful. If it was restricted and its effects localized, = then the auto-delete behaviour could also be more generally acceptable. > > You can easily use must-stmt instead to cause the error behavior > instead of deletion behavior. This should be part of the model > design, not left up to server developers. > [RW] But as a client I would not want the server to silently remove > configuration because a when condition became false. Instead, I > would rather do it explicitly and have the server return an error so > that I can fix the behaviour of the client. If the client is aware > of the schema then it can also prune config associated with failed > when conditions if it wants. Yes, the same YANG module can be used with different setups and policies th= at may require different approaches. > > Ultimately, my aim as a client is to get a complete configuration in the = client down to the server, and to be sure that the two are consistent. The= =E2=80=98when automatic deletion=E2=80=99 behaviour doesn=E2=80=99t help w= ith that, it makes it riskier. As mentioned previously, this can be mitiga= ted by always sending the entire configuration down as a config replace, at= which point I would presume that the =E2=80=98when=E2=80=99 statements are= evaluated equivalently to =E2=80=98must=E2=80=99 statements anyway =E2=80= =93 although I=E2=80=99m not sure whether RFC 7950 is clear on this. > > Personally, I would have preferred that the 'when automatic deletion' pro= cessing was controlled via an explicit protocol option, with the default be= haviour to just validate when statements (equivalently to must statements) = and not perform any automatically config deletion. > > There has been nothing preventing anyone from augmenting the > operations to turn off auto-deletion. Is this widely implemented? > Implemented at all? [RW] I think that it is as Lada stated, some > servers just don=E2=80=99t check must or when statements at all, or don= =E2=80=99t > perform the automatic deletion. I=E2=80=99m not advocating that is a good > or the right thing to do. They just don=E2=80=99t comply to that part of > the RFC. Right, there is no reason why YANG couldn't be used with management protoco= ls that don't support server-side auto-deletion. In fact, it is already use= d in situations when there is no management protocol at all. Lada > > Thanks, > Rob > > > > Thanks, > Rob > > Andy > > > -----Original Message----- > From: netmod > On= Behalf Of Ladislav Lhotka > Sent: 07 August 2019 08:39 > To: Andy Bierman >; Fengcho= ng (frank) >;= netmod@ietf.org; Zhangxiaoping (C) >; liuzhiying > > Subject: Re: [netmod] a question about 'when' > > Andy Bierman > writes: > >> On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka > wrote: >> >>> "Fengchong (frank)" > writes: >>> >>> > Hi all, >>> > >>> > I encounter a question about 'when', when I implement yang model >>> associated when condition. >>> > >>> > Yang model: >>> > >>> > leaf password-type { >>> > type enumeration { >>> > enum null; >>> > enum simple; >>> > enum cipher; >>> > } >>> > } >>> > >>> > leaf password-text { >>> > type string; >>> > when "../password-type !=3D null"; >>> > } >>> > >>> > I config these two leafs as below: >>> > simple >>> > 123456 >>> > >>> > And I changed password-type to null, I get the config like below: >>> > null >>> > >>> > And then, I reconfig the password-type to simple, what data should >>> > be >>> returned? >>> > >>> > Is >>> > simple >>> >>> According to RFC 7950, sec. 8.2, the server deleted "password-text" >>> after you changed "password-type" to null but the original value >>> isn't recovered after you change the type back. >>> >>> This server behaviour means that a typo or similar trivial error may >>> have catastrophic consequences such as auto-deletion of entire >>> configuration subtrees. That's why our RESTCONF implementation >>> (jetconf) does something >>> else: it won't permit you to change "password-type" to null as long >>> as the "password-text" exists. >>> >>> >> It seems odd to optimize the server for client mistakes. > > This is just the principle of least embarrassment. The problem is that it= is not indicated in the data model that deleting or changing something may= have far-reaching consequences. > >> It is far more likely (99 to 1?) that the client knows what it is >> doing and expects the standard to be followed. Consider the burden on >> the client deleting all the "false-when" nodes manually. This is > > If it is a significant burden, then it's also quite likely that the clien= t may not be completely aware of what's going to be auto-deleted. > >> also inconsistent with the standard behavior for choice-stmt (new case >> deletes the old case automatically). > > This is quite different in that the impact is localized: one can easily s= ee that a given leaf is a case in a choice so that it cannot exist along wi= th another case. > > Lada > >> >> Lada >>> >>> >> Andy >> >> >>> > >>> > Or >>> > >>> > simple >>> > 123456 >>> > _______________________________________________ >>> > netmod mailing list >>> > netmod@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka >>> Head, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka=20 Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Sat Aug 10 07:24:00 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E254120089 for ; Sat, 10 Aug 2019 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDrMJ3Uj329S for ; Sat, 10 Aug 2019 07:23:56 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6103212001A for ; Sat, 10 Aug 2019 07:23:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 3DE3448035C4; Sat, 10 Aug 2019 16:23:54 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7kbZVjgS8ysW; Sat, 10 Aug 2019 16:23:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 10F5248035C3; Sat, 10 Aug 2019 16:23:54 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fPPMNJT55HST; Sat, 10 Aug 2019 16:23:53 +0200 (CEST) Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id A03194802AB0; Sat, 10 Aug 2019 16:23:53 +0200 (CEST) To: "Rob Wilton (rwilton)" , "Acee Lindem (acee)" , Kent Watsen , "netmod@ietf.org" , Lou Berger References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <80F2E6D2-8F6A-4EF4-9838-45AC48BE84E5@cisco.com> <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> From: Vladimir Vassilev Message-ID: Date: Sat, 10 Aug 2019 16:23:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 14:23:59 -0000 On 07/08/2019 16.14, Rob Wilton (rwilton) wrote: > Hi Acee, > > Thanks. This was also discussed in the NETMOD WG meeting (I know that = you had a conflict). > > My reading of the consensus in the room was that the histogram statisti= cs should be deferred at this time. In particular, it seems like it woul= d take some time/effort to agree on exactly how these counters should be = modelled. I also said that I would contact the IEEE 802.3 WG chair to se= e if we could progress a histogram model within the IETF. I have sent an= email out, but not heard anything back yet. > > There was consensus in the room to add a sub-interface demux drop count= er into the current module. > > Lou also proposed that I rename "l2-mtu" to something like "max-frame-s= ize" for consistency (I need to check the recording). I think avoiding the MTU confusion was the correct decision. The MTU=20 definition from RFC791 is consistently used in all RFCs known to me. In addition to renaming the leaf there is contradiction between the=20 description and range statements in draft-ietf-netmod-intf-ext-yang-07: ... =C2=A0=C2=A0=C2=A0=C2=A0 leaf l2-mtu { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if-feature "configurable-l2-mtu"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type uint16 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 range "64 .. 65535"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The maximum size of la= yer 2 frames that may be transmitted =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or received on th= e interface (excluding any FCS overhead). =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the case of Et= hernet interfaces it also excludes the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4-8 byte overhead= of any known (i.e. explicitly matched by =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a child sub-inter= face) 802.1Q VLAN tags."; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reference "RFC XXX, Section 3.5 Lay= er 2 MTU"; =C2=A0=C2=A0=C2=A0=C2=A0 } ... Obviously minimum Ethernet frame is 64 bytes when FCS bytes are=20 included. I also do not think there is consensus that 4-8 bytes should=20 be subtracted if there are sub-interfaces with VLAN encapsulation=20 configured since this complicates the logic. IMO There have been too few reviews of this work. I will go through the=20 draft and the relevant mailing list threads during the weekend and post=20 my review. /Vladimir > > It also looks like I should generate and add -state trees to the append= ix. > > Thanks, > Rob > > > -----Original Message----- > From: Acee Lindem (acee) > Sent: 05 August 2019 18:52 > To: Rob Wilton (rwilton) ; Kent Watsen ; netmod@ietf.org > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 > > Hi Rob, > It seems these counters have been considered at great length. I agree w= e should move forward with the model as it is today. > Thanks, > Acee > > =EF=BB=BFOn 7/17/19, 11:36 AM, "Rob Wilton (rwilton)" wrote: > > Hi Acee, > =20 > Thanks for the review, and apologies for the delayed reply. > =20 > Regarding your stats question, there was some effort to handle thi= s as part of defining the Ethernet interface YANG (IEEE 802.3.2-2019) (ht= tps://github.com/YangModels/yang/tree/master/standard/ieee/published/802.= 3) that I was involved in the earlier parts of. Please see the attached = XLS that was my earlier effort to rationalize the different ethernet inte= rfaces counters between RFC 7223, Ethernet YANG, Etherlike MIB, RMON MIBs= , and the counters exposed in the 802.3 clause 30 management API. > =20 > For physical Ethernet interfaces (and anything that looks very sim= ilar to a physical Ethernet interface) then I think that we should be wel= l covered by the combination of what is in ietf-interfaces, and IEEE 802.= 3.2. > =20 > There are also some counters that apply to all Ethernet-like inter= faces (really anything using Ethernet framing, but not an Ethernet physic= al layer). The only counter currently defined in this category is in-dro= p-unknown-dest-mac-pkts in ietf-interfaces-ethernet-like. Arguably we co= uld also add a drop counter for frames that could not be demuxed to a sub= -interface because it didn't match any of the sub-interface match express= ions. > =20 > There was one set of counters that 802.3.2 didn't want to include = in their YANG module which related to the histogram frame statistics. E.= g. counters like the following (taken from IOS XR): > =20 > Input pkts 65-127 bytes =3D 0 > Input pkts 128-255 bytes =3D 0 > Input pkts 256-511 bytes =3D 0 > Input pkts 512-1023 bytes =3D 0 > Input pkts 1024-1518 bytes =3D 0 > Input pkts 1519-Max bytes =3D 0 > =20 > Output pkts 65-127 bytes =3D 0 > Output pkts 128-255 bytes =3D 0 > Output pkts 256-511 bytes =3D 0 > Output pkts 512-1023 bytes =3D 0 > Output pkts 1024-1518 bytes =3D 0 > Output pkts 1519-Max bytes =3D 0 > =20 > The 802.3 YANG WG had two issues with including counters like thes= e: > (1) They didn't really want to define histogram counter values for= MTUs that are above the officially sanctioned MTU of 1514/1518 in the Et= hernet specification, even though a lot of hardware supports up to 9K+. > (2) The bucket ranges, at least once you get past the "512-1023" b= ucket, seem to somewhat vary by ASIC vendor. > (3) IEEE 802.3 has a well defined internal management API (802.3 c= lause 30), and these histogram counters are not currently defined as part= of that internal management API. Extending the internal 802.3 managemen= t API seems tricky due to point (1) and (2) above. > =20 > There was a suggestion in the 802.3 discussions that these counter= s could be defined in an IETF YANG module (skirting the IEEE concerns abo= ut maximum MTUs). The proposal was to allow the operational data to retu= rn a list of bucket entries, where each entry defines the inclusive range= of the bucket, and a count of the pkts that matched the bucket range (in= either the ingress or egress direction). This list would sit alongside = a RECOMMENDATION of what bucket sizes to use, basically doubling each tim= e up to the MTU, with some consideration around the 1514/1518/1522 bounda= ry, but allowing freedom for a device to accurately return the histogram = ranges actually supported by the hardware. > =20 > However, I'm not sure it is worth delaying these drafts to add the= se counters in now, particularly because there are dependencies on them. = Possibly best done as future work? Do you, or anyone else in the WG hav= e an opinion on this? > =20 > Thanks, > Rob > =20 > =20 > =20 > -----Original Message----- > From: netmod On Behalf Of Acee Lindem (a= cee) > Sent: 10 July 2019 14:09 > To: Kent Watsen ; netmod@ietf.org > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yan= g-07 > =20 > I have reviewed the subject document and support publication. I ha= ve the following comment: > =20 > Perhaps ietf-interface-ethernet-like module ethlike:ethernet-lik= e/ethlike:statistics could include a subset of the counters from RFC 3635= . I say a subset since some of these counters are a bit archaic given the= state of the technology and judgement should be applied on which to incl= ude. > =20 > Thanks, > Acee > =20 > On 7/9/19, 8:16 PM, "netmod on behalf of Kent Watsen" wrote: > =20 > All, > =20 > This starts a twelve-day working group last call for draft-iet= f-netmod-intf-ext-yang-07 > =20 > The working group last call ends on July 21 (the day before th= e NETMOD 105 sessions). Please send your comments to the working group m= ailing list. > =20 > Positive comments, e.g., "I've reviewed this document and beli= eve it is ready for publication", are welcome! This is useful and import= ant, even from authors. > =20 > Thank you, > NETMOD Chairs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > =20 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Aug 11 13:14:37 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54490120848 for ; Sun, 11 Aug 2019 13:14:36 -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 header.b=LQ2+BOA3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u16cprNA 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 VKQHKKTTlRaI for ; Sun, 11 Aug 2019 13:13:31 -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 2B5721202A0 for ; Sun, 11 Aug 2019 04:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13466; q=dns/txt; s=iport; t=1565524243; x=1566733843; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gNWRrhh20BJB9+L4R2wy2hBnc2L/UIlzHk2Ivqq/j8Q=; b=LQ2+BOA3kSEepM3aPgk7nhKqlvw3mk1h5CeyKKBKIAUcSiV/g4qmktHA MZG3RkZrGEyrTC9MBWkFBq9A/eVwSt0U9LBKtpdpQVpBKEB+AZ47ntt1Q 9FU+9RiQv58usom1CRTRflRntUhCZXKCcmdi3XVaX6LrQN+QkTuAUlAsj c=; IronPort-PHdr: =?us-ascii?q?9a23=3A3NdqtRW6+r9AIAxRrnuJU76hdknV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAABPAFBd/4QNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUQkLANtVSAECyqEHoNHA4RShj9Mgg+WB4FbgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEYDQgCAQGDekUCF4JKIzQJDgEEAQEEAQEEAQpthScMhUoBAQEEAQE?= =?us-ascii?q?QCwYRDAEBLAwLBAIBBgIRBAEBAQICJgICAiULFQgIAgQBEggagwGBagMdAQI?= =?us-ascii?q?Mjh6QYQKBOIhgc4EygnoBAQWBMwGDYxiCFAMGgQwoAYtjF4FAP4ERRoE3F34?= =?us-ascii?q?+gmEBAYEuARIBIQUQI4JRMoImjDczA4IknDoJAoIdhmONaoIwhy+KJIQ6jHF?= =?us-ascii?q?kh1+QJAIEAgQFAg4BAQWBUDhncXAVO4JsgkIJAxeDT4UUhT4BcoEpi1qCQwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.64,373,1559520000"; d="scan'208";a="612329902" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2019 11:50:41 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x7BBofRU009891 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 11 Aug 2019 11:50:41 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 11 Aug 2019 06:50:40 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 11 Aug 2019 06:50:40 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 11 Aug 2019 07:50:40 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pg9Zeefid8WDNnSyOKSV6xAbFA6itVYYdCA7kEsov/fy/nWwPxVfY5/eYuUV0fGf1JGXtktWsAQEthAaLqw4CzoG74lQFxPQbr/XSVBsfabRKw4VqWbWT6ofKkAbhEqpNw4bBXioLG1z/GJ0gBuLG3lEzGQqvgD1ytDbp47r6u3L9f/e5sDzHH7Q3PyWPudAOmFnyvCbaInkWmbCQSVeW25hiBmc1wlf6slu1YGXJCL90x7Zc5qv/x1cVd1Y6pQwXk1Pxlwu5LZKfv4Z5KDIzqXhZ3QUN2B4ALdD1XyD3MWJzXa5AJNro4ZrlKqvy/EPzcN3Q0bSX+qXLq1Wb8mkkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gNWRrhh20BJB9+L4R2wy2hBnc2L/UIlzHk2Ivqq/j8Q=; b=YlP3WUrVAcahoOrBrjVC3rY4lDcnYcH4EGJek3Zk+iftsTDFHbxGDdrS9tRiTJ29pC8FY+TO7TaxdNtjvcyjjEVqnsrK+qj+s9zT4rwD13pMWdJB/TFtWYL/aeN29Ri3GI3gUqMZ4o1DrPE+eyoyMLsLOOrh8jLf+dU3Cbb6GBY8y246lfiOtno7hCfk6By2LyMyejodmulebjd1RSxv6JiDOUc/ODjqa9VcETXnnKiLJ3g4png5mmga2dFtwWaql5O2MOoIRAc2pa7r7/La/zqNuT7QT4Y+MYz5cAW2iTu0XqtU02URJlcNbLZFUIVTGCNwMS38xLcMGnYUfvBkmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gNWRrhh20BJB9+L4R2wy2hBnc2L/UIlzHk2Ivqq/j8Q=; b=u16cprNAgtFTmcXzOnOFMx0QnRIiiHF4kXL4pdqLpYkahMfz70qwxGuCmHsP9zSranik8NtncDb/YfDaMj2o38NPvrE1dylIyWGTwBC68bQFBddCBLm5Ahm5P8QBMrGFQaeAOZlLGW6VvAf2e0OuSROjbmySC0ild4v6hkWrpiY= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3966.namprd11.prod.outlook.com (10.255.180.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15; Sun, 11 Aug 2019 11:50:38 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cdbc:df25:6a53:e38b]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cdbc:df25:6a53:e38b%5]) with mapi id 15.20.2157.022; Sun, 11 Aug 2019 11:50:38 +0000 From: "Rob Wilton (rwilton)" To: Vladimir Vassilev , "Acee Lindem (acee)" , Kent Watsen , "netmod@ietf.org" , Lou Berger Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6bD086AgAmC0nCAH6jrgIABNoxQgAZq+ICAAWO4IA== Date: Sun, 11 Aug 2019 11:50:38 +0000 Message-ID: References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <80F2E6D2-8F6A-4EF4-9838-45AC48BE84E5@cisco.com> <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [2001:420:c0c0:1006::2d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c96041c4-e777-4ead-7072-08d71e5220e1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3966; x-ms-traffictypediagnostic: MN2PR11MB3966: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(346002)(136003)(51444003)(52024003)(189003)(199004)(13464003)(51914003)(186003)(5660300002)(110136005)(52536014)(316002)(6116002)(305945005)(74316002)(2906002)(7736002)(33656002)(71190400001)(71200400001)(561944003)(8676002)(46003)(6506007)(478600001)(81156014)(66946007)(14454004)(7696005)(966005)(53546011)(6246003)(446003)(25786009)(11346002)(256004)(5024004)(14444005)(81166006)(76176011)(64756008)(66556008)(66476007)(8936002)(76116006)(55016002)(99286004)(66446008)(9686003)(102836004)(86362001)(6306002)(6436002)(2501003)(486006)(476003)(229853002)(53936002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3966; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4bPQFEs/WElg8atCa5LCvPQSSeJ3BVVjqeVQO7GEbI7Jzh4doiqz3Q0nPItUvfxhBlaFlsBkUMiymC3Yvc+XEPJdVQw54JtEUjCZe2fTnbYQ6V/A0O+vNtEduAKj0eZFTyza13Ygm1yPPuUEuO22HzUud3Rrehfhzkm0zybTKhU054tqnZ9PqTKGYtqUmqYU292crEWthHsz/6C+lcnj8/0U6UGAWsE3xvtM4XL7Rav1TYz8PapmDaoSVTwPc/ENL+b8l9dRgR/ZUnQmkB4B6HWx3wHpcrQxkbWMfujH2uD1+I3z1bOdMZXZDWPiAfZzHVitTpbhR6wnVnSXeUV43HKsnVziwicjxQ7QaGv+G7C4DB46zSm/8cYzAIoyvy1KEgkH6tYb8c48HDU9gLfSyB/HJN/KB4zZQP3mUN/bs+U= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c96041c4-e777-4ead-7072-08d71e5220e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2019 11:50:38.1622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DUA9y41ncAKXzxVpvdBbE7/KN4AMbGuv/wNTR/hqaPWMbBWuzh/0apOoRydMu/EicPl2aFBmrZiSpqVu4Uj7sw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3966 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 20:14:36 -0000 SGkgVmxhZGltaXIsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiANCg0KUmVnYXJkaW5nIGlu Y3JlYXNpbmcgdGhlIEwyIE1UVSBpZiA4MDIuMVEgdGFncyBhcmUgcHJlc2VudCwgdGhpcyBpcyBi ZWNhdXNlIG9mIGhvdyBJRUVFIDgwMi4zIGRlZmluZXMgdGhlIE1UVSBvZiBhbiBFdGhlcm5ldCBp bnRlcmZhY2UgKGF0IGxlYXN0IGZvciBhIHNpbmdsZSA4MDIuMVEgdGFnKS4NCg0KSWYgeW91IGhh dmUgYSBtaXggb2Ygc2luZ2xlIGFuZCBkb3VibGUgdGFnZ2VkIHN1Yi1pbnRlZmFjZXMsIGl0IGFs c28gbWVhbnMgdGhhdCB0aGUgSVAgTVRVIGZvciBhbGwgb2YgdGhvc2Ugc3ViLWludGVyZmFjZXMg Y2FuIGJlIHRoZSBzYW1lLg0KDQpFLmcuIGlmIHlvdSBzZXQgdGhlIEwyIE1UVSBvZiBhIHBoeXNp Y2FsIGludGVyZmFjZSB0byAxNTE0IChleGNsdWRpbmcgRkNTIGJ5dGVzKSB0aGVuIHRoZSBJUCBN VFUgZm9yIGVhY2ggb2YgdGhlIHN1Yi1pbnRlcmZhY2VzIHdvdWxkIGJlIDE1MDAgYnl0ZXMgcmVn YXJkbGVzcyBvZiB3aGV0aGVyIHRoZXkgYXJlIGNvbmZpZ3VyZWQgdG8gbWF0Y2ggc2luZ2xlIG9y IGRvdWJsZSBWTEFOIHRhZ3MuDQoNCkNvbnZlcnNlbHksIGlmIHlvdSBoYXZlIGEgc3RyaWN0IEwy IE1UVSB0aGF0IGRvZXNuJ3QgaGF2ZSB0aGlzIGZsZXhpYmlsaXR5IHRoZW4gYSBzaW5nbGUgdGFn Z2VkIHN1Yi1pbnRlcmZhY2Ugd291bGQgZW5kIHVwIHdpdGggYW4gSVAgTVRVIG9mIDE0OTYsIGFu ZCBhIGRvdWJsZSB0YWdnZWQgc3ViLWludGVyZmFjZSB3b3VsZCBlbmQgdXAgd2l0aCBhbiBJUCBN VFUgb2YgMTQ5MiwgY29tcGxpY2F0aW5nIEwzIGNvbmZpZ3VyYXRpb24uDQoNCkJUVywgSSdsbCBi ZSBvbiBQVE8gZm9yIGEgd2Vlaywgc28gcGxlYXNlIGV4cGVjdCBhIGRlbGF5IGluIHJlc3BvbnNl Lg0KDQpUaGFua3MsDQpSb2INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VmxhZGltaXIgVmFzc2lsZXYgPHZsYWRpbWlyQHRyYW5zcGFja2V0LmNvbT4gDQpTZW50OiAxMCBB dWd1c3QgMjAxOSAxNToyNA0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2Nv LmNvbT47IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+OyBLZW50IFdhdHNlbiA8 a2VudCtpZXRmQHdhdHNlbi5uZXQ+OyBuZXRtb2RAaWV0Zi5vcmc7IExvdSBCZXJnZXIgPGxiZXJn ZXJAbGFibi5uZXQ+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1p ZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTA3DQoNCg0KT24gMDcvMDgvMjAxOSAxNi4xNCwgUm9i IFdpbHRvbiAocndpbHRvbikgd3JvdGU6DQo+IEhpIEFjZWUsDQo+DQo+IFRoYW5rcy4gIFRoaXMg d2FzIGFsc28gZGlzY3Vzc2VkIGluIHRoZSBORVRNT0QgV0cgbWVldGluZyAoSSBrbm93IHRoYXQg eW91IGhhZCBhIGNvbmZsaWN0KS4NCj4NCj4gTXkgcmVhZGluZyBvZiB0aGUgY29uc2Vuc3VzIGlu IHRoZSByb29tIHdhcyB0aGF0IHRoZSBoaXN0b2dyYW0gc3RhdGlzdGljcyBzaG91bGQgYmUgZGVm ZXJyZWQgYXQgdGhpcyB0aW1lLiAgSW4gcGFydGljdWxhciwgaXQgc2VlbXMgbGlrZSBpdCB3b3Vs ZCB0YWtlIHNvbWUgdGltZS9lZmZvcnQgdG8gYWdyZWUgb24gZXhhY3RseSBob3cgdGhlc2UgY291 bnRlcnMgc2hvdWxkIGJlIG1vZGVsbGVkLiAgSSBhbHNvIHNhaWQgdGhhdCBJIHdvdWxkIGNvbnRh Y3QgdGhlIElFRUUgODAyLjMgV0cgY2hhaXIgdG8gc2VlIGlmIHdlIGNvdWxkIHByb2dyZXNzIGEg aGlzdG9ncmFtIG1vZGVsIHdpdGhpbiB0aGUgSUVURi4gIEkgaGF2ZSBzZW50IGFuIGVtYWlsIG91 dCwgYnV0IG5vdCBoZWFyZCBhbnl0aGluZyBiYWNrIHlldC4NCj4NCj4gVGhlcmUgd2FzIGNvbnNl bnN1cyBpbiB0aGUgcm9vbSB0byBhZGQgYSBzdWItaW50ZXJmYWNlIGRlbXV4IGRyb3AgY291bnRl ciBpbnRvIHRoZSBjdXJyZW50IG1vZHVsZS4NCj4NCj4gTG91IGFsc28gcHJvcG9zZWQgdGhhdCBJ IHJlbmFtZSAibDItbXR1IiB0byBzb21ldGhpbmcgbGlrZSAibWF4LWZyYW1lLXNpemUiIGZvciBj b25zaXN0ZW5jeSAoSSBuZWVkIHRvIGNoZWNrIHRoZSByZWNvcmRpbmcpLg0KSSB0aGluayBhdm9p ZGluZyB0aGUgTVRVIGNvbmZ1c2lvbiB3YXMgdGhlIGNvcnJlY3QgZGVjaXNpb24uIFRoZSBNVFUg ZGVmaW5pdGlvbiBmcm9tIFJGQzc5MSBpcyBjb25zaXN0ZW50bHkgdXNlZCBpbiBhbGwgUkZDcyBr bm93biB0byBtZS4NCg0KSW4gYWRkaXRpb24gdG8gcmVuYW1pbmcgdGhlIGxlYWYgdGhlcmUgaXMg Y29udHJhZGljdGlvbiBiZXR3ZWVuIHRoZSBkZXNjcmlwdGlvbiBhbmQgcmFuZ2Ugc3RhdGVtZW50 cyBpbiBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTA3Og0KDQo8Q09ERSBCRUdJTlM+ DQoNCi4uLg0KDQogwqDCoMKgwqAgbGVhZiBsMi1tdHUgew0KIMKgwqDCoMKgwqDCoCBpZi1mZWF0 dXJlICJjb25maWd1cmFibGUtbDItbXR1IjsNCiDCoMKgwqDCoMKgwqAgdHlwZSB1aW50MTYgew0K IMKgwqDCoMKgwqDCoMKgwqAgcmFuZ2UgIjY0IC4uIDY1NTM1IjsNCiDCoMKgwqDCoMKgwqAgfQ0K IMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbg0KIMKgwqDCoMKgwqDCoMKgwqAgIlRoZSBtYXhpbXVt IHNpemUgb2YgbGF5ZXIgMiBmcmFtZXMgdGhhdCBtYXkgYmUgdHJhbnNtaXR0ZWQNCiDCoMKgwqDC oMKgwqDCoMKgwqAgb3IgcmVjZWl2ZWQgb24gdGhlIGludGVyZmFjZSAoZXhjbHVkaW5nIGFueSBG Q1Mgb3ZlcmhlYWQpLg0KIMKgwqDCoMKgwqDCoMKgwqDCoCBJbiB0aGUgY2FzZSBvZiBFdGhlcm5l dCBpbnRlcmZhY2VzIGl0IGFsc28gZXhjbHVkZXMgdGhlDQogwqDCoMKgwqDCoMKgwqDCoMKgIDQt OCBieXRlIG92ZXJoZWFkIG9mIGFueSBrbm93biAoaS5lLiBleHBsaWNpdGx5IG1hdGNoZWQgYnkN CiDCoMKgwqDCoMKgwqDCoMKgwqAgYSBjaGlsZCBzdWItaW50ZXJmYWNlKSA4MDIuMVEgVkxBTiB0 YWdzLiI7DQogwqDCoMKgwqDCoMKgIHJlZmVyZW5jZSAiUkZDIFhYWCwgU2VjdGlvbiAzLjUgTGF5 ZXIgMiBNVFUiOw0KIMKgwqDCoMKgIH0NCg0KLi4uDQoNCjxDT0RFIEVORFM+DQoNCk9idmlvdXNs eSBtaW5pbXVtIEV0aGVybmV0IGZyYW1lIGlzIDY0IGJ5dGVzIHdoZW4gRkNTIGJ5dGVzIGFyZSBp bmNsdWRlZC4gSSBhbHNvIGRvIG5vdCB0aGluayB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCA0LTgg Ynl0ZXMgc2hvdWxkIGJlIHN1YnRyYWN0ZWQgaWYgdGhlcmUgYXJlIHN1Yi1pbnRlcmZhY2VzIHdp dGggVkxBTiBlbmNhcHN1bGF0aW9uIGNvbmZpZ3VyZWQgc2luY2UgdGhpcyBjb21wbGljYXRlcyB0 aGUgbG9naWMuDQoNCklNTyBUaGVyZSBoYXZlIGJlZW4gdG9vIGZldyByZXZpZXdzIG9mIHRoaXMg d29yay4gSSB3aWxsIGdvIHRocm91Z2ggdGhlIGRyYWZ0IGFuZCB0aGUgcmVsZXZhbnQgbWFpbGlu ZyBsaXN0IHRocmVhZHMgZHVyaW5nIHRoZSB3ZWVrZW5kIGFuZCBwb3N0IG15IHJldmlldy4NCg0K L1ZsYWRpbWlyDQo+DQo+IEl0IGFsc28gbG9va3MgbGlrZSBJIHNob3VsZCBnZW5lcmF0ZSBhbmQg YWRkIC1zdGF0ZSB0cmVlcyB0byB0aGUgYXBwZW5kaXguDQo+DQo+IFRoYW5rcywNCj4gUm9iDQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFjZWUgTGluZGVtIChh Y2VlKQ0KPiBTZW50OiAwNSBBdWd1c3QgMjAxOSAxODo1Mg0KPiBUbzogUm9iIFdpbHRvbiAocndp bHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgS2VudCBXYXRzZW4gDQo+IDxrZW50K2lldGZAd2F0 c2VuLm5ldD47IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFz dCBDYWxsOiBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTA3DQo+DQo+IEhpIFJvYiwN Cj4gSXQgc2VlbXMgdGhlc2UgY291bnRlcnMgaGF2ZSBiZWVuIGNvbnNpZGVyZWQgYXQgZ3JlYXQg bGVuZ3RoLiBJIGFncmVlIHdlIHNob3VsZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgbW9kZWwgYXMg aXQgaXMgdG9kYXkuDQo+IFRoYW5rcywNCj4gQWNlZQ0KPg0KPiDvu79PbiA3LzE3LzE5LCAxMToz NiBBTSwgIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0K Pg0KPiAgICAgIEhpIEFjZWUsDQo+ICAgICAgDQo+ICAgICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3 LCBhbmQgYXBvbG9naWVzIGZvciB0aGUgZGVsYXllZCByZXBseS4NCj4gICAgICANCj4gICAgICBS ZWdhcmRpbmcgeW91ciBzdGF0cyBxdWVzdGlvbiwgdGhlcmUgd2FzIHNvbWUgZWZmb3J0IHRvIGhh bmRsZSB0aGlzIGFzIHBhcnQgb2YgZGVmaW5pbmcgdGhlIEV0aGVybmV0IGludGVyZmFjZSBZQU5H IChJRUVFIDgwMi4zLjItMjAxOSkgKGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcv dHJlZS9tYXN0ZXIvc3RhbmRhcmQvaWVlZS9wdWJsaXNoZWQvODAyLjMpIHRoYXQgSSB3YXMgaW52 b2x2ZWQgaW4gdGhlIGVhcmxpZXIgcGFydHMgb2YuICBQbGVhc2Ugc2VlIHRoZSBhdHRhY2hlZCBY TFMgdGhhdCB3YXMgbXkgZWFybGllciBlZmZvcnQgdG8gcmF0aW9uYWxpemUgdGhlIGRpZmZlcmVu dCBldGhlcm5ldCBpbnRlcmZhY2VzIGNvdW50ZXJzIGJldHdlZW4gUkZDIDcyMjMsIEV0aGVybmV0 IFlBTkcsIEV0aGVybGlrZSBNSUIsIFJNT04gTUlCcywgYW5kIHRoZSBjb3VudGVycyBleHBvc2Vk IGluIHRoZSA4MDIuMyBjbGF1c2UgMzAgbWFuYWdlbWVudCBBUEkuDQo+ICAgICAgDQo+ICAgICAg Rm9yIHBoeXNpY2FsIEV0aGVybmV0IGludGVyZmFjZXMgKGFuZCBhbnl0aGluZyB0aGF0IGxvb2tz IHZlcnkgc2ltaWxhciB0byBhIHBoeXNpY2FsIEV0aGVybmV0IGludGVyZmFjZSkgdGhlbiBJIHRo aW5rIHRoYXQgd2Ugc2hvdWxkIGJlIHdlbGwgY292ZXJlZCBieSB0aGUgY29tYmluYXRpb24gb2Yg d2hhdCBpcyBpbiBpZXRmLWludGVyZmFjZXMsIGFuZCBJRUVFIDgwMi4zLjIuDQo+ICAgICAgDQo+ ICAgICAgVGhlcmUgYXJlIGFsc28gc29tZSBjb3VudGVycyB0aGF0IGFwcGx5IHRvIGFsbCBFdGhl cm5ldC1saWtlIGludGVyZmFjZXMgKHJlYWxseSBhbnl0aGluZyB1c2luZyBFdGhlcm5ldCBmcmFt aW5nLCBidXQgbm90IGFuIEV0aGVybmV0IHBoeXNpY2FsIGxheWVyKS4gIFRoZSBvbmx5IGNvdW50 ZXIgY3VycmVudGx5IGRlZmluZWQgaW4gdGhpcyBjYXRlZ29yeSBpcyBpbi1kcm9wLXVua25vd24t ZGVzdC1tYWMtcGt0cyBpbiBpZXRmLWludGVyZmFjZXMtZXRoZXJuZXQtbGlrZS4gIEFyZ3VhYmx5 IHdlIGNvdWxkIGFsc28gYWRkIGEgZHJvcCBjb3VudGVyIGZvciBmcmFtZXMgdGhhdCBjb3VsZCBu b3QgYmUgZGVtdXhlZCB0byBhIHN1Yi1pbnRlcmZhY2UgYmVjYXVzZSBpdCBkaWRuJ3QgbWF0Y2gg YW55IG9mIHRoZSBzdWItaW50ZXJmYWNlIG1hdGNoIGV4cHJlc3Npb25zLg0KPiAgICAgIA0KPiAg ICAgIFRoZXJlIHdhcyBvbmUgc2V0IG9mIGNvdW50ZXJzIHRoYXQgODAyLjMuMiBkaWRuJ3Qgd2Fu dCB0byBpbmNsdWRlIGluIHRoZWlyIFlBTkcgbW9kdWxlIHdoaWNoIHJlbGF0ZWQgdG8gdGhlIGhp c3RvZ3JhbSBmcmFtZSBzdGF0aXN0aWNzLiAgRS5nLiBjb3VudGVycyBsaWtlIHRoZSBmb2xsb3dp bmcgKHRha2VuIGZyb20gSU9TIFhSKToNCj4gICAgICANCj4gICAgICAgICAgSW5wdXQgcGt0cyA2 NS0xMjcgYnl0ZXMgICAgID0gMA0KPiAgICAgICAgICBJbnB1dCBwa3RzIDEyOC0yNTUgYnl0ZXMg ICAgPSAwDQo+ICAgICAgICAgIElucHV0IHBrdHMgMjU2LTUxMSBieXRlcyAgICA9IDANCj4gICAg ICAgICAgSW5wdXQgcGt0cyA1MTItMTAyMyBieXRlcyAgID0gMA0KPiAgICAgICAgICBJbnB1dCBw a3RzIDEwMjQtMTUxOCBieXRlcyAgPSAwDQo+ICAgICAgICAgIElucHV0IHBrdHMgMTUxOS1NYXgg Ynl0ZXMgICA9IDANCj4gICAgICANCj4gICAgICAgICAgT3V0cHV0IHBrdHMgNjUtMTI3IGJ5dGVz ICAgID0gMA0KPiAgICAgICAgICBPdXRwdXQgcGt0cyAxMjgtMjU1IGJ5dGVzICAgPSAwDQo+ICAg ICAgICAgIE91dHB1dCBwa3RzIDI1Ni01MTEgYnl0ZXMgICA9IDANCj4gICAgICAgICAgT3V0cHV0 IHBrdHMgNTEyLTEwMjMgYnl0ZXMgID0gMA0KPiAgICAgICAgICBPdXRwdXQgcGt0cyAxMDI0LTE1 MTggYnl0ZXMgPSAwDQo+ICAgICAgICAgIE91dHB1dCBwa3RzIDE1MTktTWF4IGJ5dGVzICA9IDAN Cj4gICAgICANCj4gICAgICBUaGUgODAyLjMgWUFORyBXRyBoYWQgdHdvIGlzc3VlcyB3aXRoIGlu Y2x1ZGluZyBjb3VudGVycyBsaWtlIHRoZXNlOg0KPiAgICAgICgxKSBUaGV5IGRpZG4ndCByZWFs bHkgd2FudCB0byBkZWZpbmUgaGlzdG9ncmFtIGNvdW50ZXIgdmFsdWVzIGZvciBNVFVzIHRoYXQg YXJlIGFib3ZlIHRoZSBvZmZpY2lhbGx5IHNhbmN0aW9uZWQgTVRVIG9mIDE1MTQvMTUxOCBpbiB0 aGUgRXRoZXJuZXQgc3BlY2lmaWNhdGlvbiwgZXZlbiB0aG91Z2ggYSBsb3Qgb2YgaGFyZHdhcmUg c3VwcG9ydHMgdXAgdG8gOUsrLg0KPiAgICAgICgyKSBUaGUgYnVja2V0IHJhbmdlcywgYXQgbGVh c3Qgb25jZSB5b3UgZ2V0IHBhc3QgdGhlICI1MTItMTAyMyIgYnVja2V0LCBzZWVtIHRvIHNvbWV3 aGF0IHZhcnkgYnkgQVNJQyB2ZW5kb3IuDQo+ICAgICAgKDMpIElFRUUgODAyLjMgaGFzIGEgd2Vs bCBkZWZpbmVkIGludGVybmFsIG1hbmFnZW1lbnQgQVBJICg4MDIuMyBjbGF1c2UgMzApLCBhbmQg dGhlc2UgaGlzdG9ncmFtIGNvdW50ZXJzIGFyZSBub3QgY3VycmVudGx5IGRlZmluZWQgYXMgcGFy dCBvZiB0aGF0IGludGVybmFsIG1hbmFnZW1lbnQgQVBJLiAgRXh0ZW5kaW5nIHRoZSBpbnRlcm5h bCA4MDIuMyBtYW5hZ2VtZW50IEFQSSBzZWVtcyB0cmlja3kgZHVlIHRvIHBvaW50ICgxKSBhbmQg KDIpIGFib3ZlLg0KPiAgICAgIA0KPiAgICAgIFRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gaW4gdGhl IDgwMi4zIGRpc2N1c3Npb25zIHRoYXQgdGhlc2UgY291bnRlcnMgY291bGQgYmUgZGVmaW5lZCBp biBhbiBJRVRGIFlBTkcgbW9kdWxlIChza2lydGluZyB0aGUgSUVFRSBjb25jZXJucyBhYm91dCBt YXhpbXVtIE1UVXMpLiAgVGhlIHByb3Bvc2FsIHdhcyB0byBhbGxvdyB0aGUgb3BlcmF0aW9uYWwg ZGF0YSB0byByZXR1cm4gYSBsaXN0IG9mIGJ1Y2tldCBlbnRyaWVzLCB3aGVyZSBlYWNoIGVudHJ5 IGRlZmluZXMgdGhlIGluY2x1c2l2ZSByYW5nZSBvZiB0aGUgYnVja2V0LCBhbmQgYSBjb3VudCBv ZiB0aGUgcGt0cyB0aGF0IG1hdGNoZWQgdGhlIGJ1Y2tldCByYW5nZSAoaW4gZWl0aGVyIHRoZSBp bmdyZXNzIG9yIGVncmVzcyBkaXJlY3Rpb24pLiAgVGhpcyBsaXN0IHdvdWxkIHNpdCBhbG9uZ3Np ZGUgYSBSRUNPTU1FTkRBVElPTiBvZiB3aGF0IGJ1Y2tldCBzaXplcyB0byB1c2UsIGJhc2ljYWxs eSBkb3VibGluZyBlYWNoIHRpbWUgdXAgdG8gdGhlIE1UVSwgd2l0aCBzb21lIGNvbnNpZGVyYXRp b24gYXJvdW5kIHRoZSAxNTE0LzE1MTgvMTUyMiBib3VuZGFyeSwgYnV0IGFsbG93aW5nIGZyZWVk b20gZm9yIGEgZGV2aWNlIHRvIGFjY3VyYXRlbHkgcmV0dXJuIHRoZSBoaXN0b2dyYW0gcmFuZ2Vz IGFjdHVhbGx5IHN1cHBvcnRlZCBieSB0aGUgaGFyZHdhcmUuDQo+ICAgICAgDQo+ICAgICAgSG93 ZXZlciwgSSdtIG5vdCBzdXJlIGl0IGlzIHdvcnRoIGRlbGF5aW5nIHRoZXNlIGRyYWZ0cyB0byBh ZGQgdGhlc2UgY291bnRlcnMgaW4gbm93LCBwYXJ0aWN1bGFybHkgYmVjYXVzZSB0aGVyZSBhcmUg ZGVwZW5kZW5jaWVzIG9uIHRoZW0uICBQb3NzaWJseSBiZXN0IGRvbmUgYXMgZnV0dXJlIHdvcms/ ICBEbyB5b3UsIG9yIGFueW9uZSBlbHNlIGluIHRoZSBXRyBoYXZlIGFuIG9waW5pb24gb24gdGhp cz8NCj4gICAgICANCj4gICAgICBUaGFua3MsDQo+ICAgICAgUm9iDQo+ICAgICAgDQo+ICAgICAg DQo+ICAgICAgDQo+ICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgICBGcm9t OiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWNlZSBMaW5k ZW0gKGFjZWUpDQo+ICAgICAgU2VudDogMTAgSnVseSAyMDE5IDE0OjA5DQo+ICAgICAgVG86IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IG5ldG1vZEBpZXRmLm9yZw0KPiAgICAg IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGw6IA0KPiBkcmFmdC1pZXRmLW5ldG1v ZC1pbnRmLWV4dC15YW5nLTA3DQo+ICAgICAgDQo+ICAgICAgSSBoYXZlIHJldmlld2VkIHRoZSBz dWJqZWN0IGRvY3VtZW50IGFuZCBzdXBwb3J0IHB1YmxpY2F0aW9uLiBJIGhhdmUgdGhlIGZvbGxv d2luZyBjb21tZW50Og0KPiAgICAgIA0KPiAgICAgICAgUGVyaGFwcyBpZXRmLWludGVyZmFjZS1l dGhlcm5ldC1saWtlIG1vZHVsZSBldGhsaWtlOmV0aGVybmV0LWxpa2UvZXRobGlrZTpzdGF0aXN0 aWNzIGNvdWxkIGluY2x1ZGUgYSBzdWJzZXQgb2YgdGhlIGNvdW50ZXJzIGZyb20gUkZDIDM2MzUu IEkgc2F5IGEgc3Vic2V0IHNpbmNlIHNvbWUgb2YgdGhlc2UgY291bnRlcnMgYXJlIGEgYml0IGFy Y2hhaWMgZ2l2ZW4gdGhlIHN0YXRlIG9mIHRoZSB0ZWNobm9sb2d5IGFuZCBqdWRnZW1lbnQgc2hv dWxkIGJlIGFwcGxpZWQgb24gd2hpY2ggdG8gaW5jbHVkZS4NCj4gICAgICANCj4gICAgICAgIFRo YW5rcywNCj4gICAgICBBY2VlDQo+ICAgICAgDQo+ICAgICAgT24gNy85LzE5LCA4OjE2IFBNLCAi bmV0bW9kIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+ICAgICAgDQo+ICAg ICAgICAgIEFsbCwNCj4gICAgICAgICAgDQo+ICAgICAgICAgIFRoaXMgc3RhcnRzIGEgdHdlbHZl LWRheSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgDQo+IGRyYWZ0LWlldGYtbmV0bW9kLWlu dGYtZXh0LXlhbmctMDcNCj4gICAgICAgICAgDQo+ICAgICAgICAgIFRoZSB3b3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBlbmRzIG9uIEp1bHkgMjEgKHRoZSBkYXkgYmVmb3JlIHRoZSBORVRNT0QgMTA1 IHNlc3Npb25zKS4gIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0Lg0KPiAgICAgICAgICANCj4gICAgICAgICAgUG9zaXRpdmUgY29tbWVu dHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMg cmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhICBUaGlzIGlzIHVzZWZ1bCBhbmQg aW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4gICAgICAgICAgDQo+ICAgICAgICAgIFRo YW5rIHlvdSwNCj4gICAgICAgICAgTkVUTU9EIENoYWlycw0KPiAgICAgICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgICBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+ICAgICAgICAgIG5ldG1vZEBpZXRmLm9yZw0KPiAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiAgICAgICAgICANCj4g ICAgICANCj4gICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gICAgICBuZXRtb2RAaWV0Zi5vcmcN Cj4gICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiAg ICAgIA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Mon Aug 12 01:25:23 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6E120A2F for ; Mon, 12 Aug 2019 01:25:21 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSm9kTMkiRYF for ; Mon, 12 Aug 2019 01:24:19 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853ED120E57 for ; Sun, 11 Aug 2019 10:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 3BCC648035CE; Sun, 11 Aug 2019 19:55:58 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Omk62S_Dt2ZS; Sun, 11 Aug 2019 19:55:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0BCB948035C0; Sun, 11 Aug 2019 19:55:58 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nwjMJnn34GhG; Sun, 11 Aug 2019 19:55:57 +0200 (CEST) Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id CBC614803564; Sun, 11 Aug 2019 19:55:57 +0200 (CEST) To: "Rob Wilton (rwilton)" , "Acee Lindem (acee)" , Kent Watsen , "netmod@ietf.org" , Lou Berger References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <80F2E6D2-8F6A-4EF4-9838-45AC48BE84E5@cisco.com> <897E77D0-5EB6-4C05-BED2-F1DB3D26948B@cisco.com> From: Vladimir Vassilev Message-ID: Date: Sun, 11 Aug 2019 19:55:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 08:25:21 -0000 On 11/08/2019 13.50, Rob Wilton (rwilton) wrote: > Hi Vladimir, > > Thanks for the comments. > > Regarding increasing the L2 MTU if 802.1Q tags are present, this is bec= ause of how IEEE 802.3 defines the MTU of an Ethernet interface (at least= for a single 802.1Q tag). Where does IEEE 802.3 define "MTU of an Ethernet interface" (me being=20 positive IEEE 802.3 or 802.1Q do not use MTU definition at all)? > > If you have a mix of single and double tagged sub-intefaces, it also me= ans that the IP MTU for all of those sub-interfaces can be the same. > > E.g. if you set the L2 MTU of a physical interface to 1514 (excluding F= CS bytes) then the IP MTU for each of the sub-interfaces would be 1500 by= tes regardless of whether they are configured to match single or double V= LAN tags. > > Conversely, if you have a strict L2 MTU that doesn't have this flexibil= ity then a single tagged sub-interface would end up with an IP MTU of 149= 6, and a double tagged sub-interface would end up with an IP MTU of 1492,= complicating L3 configuration. The problem can become very complicated=C2=A0 if we introduce new definit= ion=20 of MTU (I still do not agree L2 MTU is a thing). Why the ifMtu object from IF-MIB is not mapped to config false=20 /ietf-interfaces:interfaces/interface/ietf-interfaces-common:mtu in=20 ietf-intefaces-common.yang and instead we need something else? From RFC 2863: ifMtu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface." ::=3D { ifEntry 4 } IMO this sounds as useful today as it did before. From RFC 8343 "4.=C2=A0 Relationship to the IF-MIB": The ifMtu object from the IF-MIB is not mapped to the "ietf-interfaces" module. It is expected that interface-type- specific YANG modules provide interface-type-specific MTU leafs by augmenting the "ietf-interfaces" model. I am aware of that text too but I do not agree mapping ifMtu which is=20 interface type independent to /interfaces/interface/mtu is not necessay=20 and can be replaced by introducing "interface-type-specific MTU leafs". Vladimir > > BTW, I'll be on PTO for a week, so please expect a delay in response. > > Thanks, > Rob > From nobody Mon Aug 12 04:35:07 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7330120B7D; Mon, 12 Aug 2019 04:34: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: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <156560969560.19877.12629057093556996837@ietfa.amsl.com> Date: Mon, 12 Aug 2019 04:34:55 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 11:34:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-04.txt Pages : 25 Date : 2019-08-12 Abstract: There is a need to document data defined in YANG models when a live server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a operation/request) and decorates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-04 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-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 Mon Aug 12 14:45:46 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48054120147 for ; Mon, 12 Aug 2019 14:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0jdScqmojUBS for ; Mon, 12 Aug 2019 14:45:41 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50085.outbound.protection.outlook.com [40.107.5.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB5D120F0F for ; Mon, 12 Aug 2019 05:03:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3guh/7+6o3uS3k0CSnegKMJXBP6jfB5vOFj5NC5skcyaEtAIU6yxMdaIixR4rMD4vxTkK/Nx06+9zAYwiexjCImUQcNtVHm55iCkHTDC3oNf0lvBfCZvFLYGX8jJgAmvcN8CvJGqwboq9fQ0yGRsUqstfOCc3Pnk70RTkfZAlul8cJfKZ0VPJpqaQ4vOMxmOeAiEO9ZNXtXSYLT2DJVjppFqNmnlvpIuYO3OoIvUdhd52e0H5d3vxDAZx5OhQbh34Odu/gbEQvecDmNSmNynK9e63c0yCO80pQizKJIXv4ocXWK4+Yn8tWQnFXBsLqDjHa+23AspQMliMa62HKxcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2pPx1XhJWJstYtWPZ9O/rthaGSJFaCICjhnmBNlid9M=; b=GPXsLeki20b9dShU9GY6yWOvQk2UVI1ZiBHzblsEALdysmSsbMtuz167rX0iVpiRr+4NEgqOXYuvqxPouro17xg2MW9MOn8FxZNINFkPCm4wGO0Mn6LXA3GVKaXt41zIco+8hO+P1GMmCAaPlcHO2+bFxfevvWPOKqxczli0b3h9qTfvizNbv+5+Uq6YyO6iiQxrY2REMNytM2i7eDGD0uSCQ9AfE/Nl3ufcKecFAqebOie+W7Z1UvEvrSNrSXI4BgOLN+b98TExFTKYp/GE43hKzK1CMPeWMG6rY36gXIrLzZVInPGXyjsdpSf1YCilLPjAkAESTZ3Hvt8tPbJlgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2pPx1XhJWJstYtWPZ9O/rthaGSJFaCICjhnmBNlid9M=; b=WRtbR6emLMOPhzF5W6ZtXMRUHxTi5Oq6YubJXY2PKZAKamUMgCyXAfui9tAJFLkgQCYQEHtAF9vs2OuawodQ9XHm8sjTIPiaslwtpCUoYjSZQJfKMlguHehQcx2ESWKUgHmr+e/Cf4g7qjKzfa9ggJU8sCThDxN+pDp0VFz/AKc= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2862.eurprd07.prod.outlook.com (10.173.73.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.15; Mon, 12 Aug 2019 12:03:18 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a%11]) with mapi id 15.20.2178.013; Mon, 12 Aug 2019 12:03:18 +0000 From: =?iso-8859-2?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-04.txt Thread-Index: AQHVUQIUHuy7NsGIQUmzBbXRY7F6DKb3aRZQ Date: Mon, 12 Aug 2019 12:03:18 +0000 Message-ID: References: <156560969560.19877.12629057093556996837@ietfa.amsl.com> In-Reply-To: <156560969560.19877.12629057093556996837@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a21958a-b777-4b41-59b3-08d71f1d108f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2862; x-ms-traffictypediagnostic: VI1PR0701MB2862: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(13464003)(189003)(199004)(74316002)(25786009)(33656002)(7736002)(6246003)(53936002)(52536014)(305945005)(5660300002)(81166006)(2351001)(1730700003)(81156014)(8676002)(8936002)(9686003)(99286004)(6306002)(2906002)(5640700003)(6436002)(2501003)(229853002)(55016002)(6916009)(45776006)(256004)(66446008)(64756008)(14444005)(478600001)(476003)(486006)(86362001)(966005)(66556008)(66946007)(11346002)(76116006)(66476007)(66616009)(446003)(316002)(14454004)(26005)(6506007)(53546011)(7696005)(76176011)(3846002)(6116002)(66574012)(102836004)(186003)(66066001)(71190400001)(71200400001)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2862; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QIQw4d6tcHBOXEYhH7W0LfZfcZBNDCsQHqVb03OZ4k4OjgdtAHSBehbqGkVtPWZDPBscenq4gR6/MFF0IphvIVvl5fuslurceVG5rr7lg0LbxqdndZY3Y9hoDMY0laouQp/QdE50OhzLYayFfZ/EllIEZ9+FMM/yEd9sdQWZVk44SQRLyGHIzWtAdlIPMTMG3E/H5IwkLTD7WOKXNiW4Burz3M1QR6U9XT2evL3JhgeikQvzvP75CB1qQu0VGBdTZbB2JSb1HNL0rTRoUGoUxjBLvSsuPkH07x8NBFQpsusaSz6RAosJTYKTDOuo4kHJuk5VVqwzT5NRftiBKNkmerCoiJOosUYxw25vVy+iQanqJZu4GOE6DnXyHZDItnnLHAnu1pTITz3ubRsOBaPXp0+KuoAi0jCrQtLhcB9JC5A= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01D55116.B09D3200" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a21958a-b777-4b41-59b3-08d71f1d108f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2019 12:03:18.7467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jRmwWO5s/rKJoetq0ANWKmzrBcCEy0o2R3o17sxUJm0quP99PCVudP5vrZK9ANpqS4cuNc92MsMMyB3cig3mdiMkjFFSxvZDCexCjc+27zU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2862 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:45:44 -0000 ------=_NextPart_000_0048_01D55116.B09D3200 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, Changes v03 - v04 o removed entity-tag and last-modified timestamp (metadata = definitions) o Added simplified-inline method of content-schema specification AFAIK this addresses all comment from IETF105 and the mails afterwards. regards Balazs -----Original Message----- From: netmod On Behalf Of = internet-drafts@ietf.org Sent: 2019. augusztus 12., h=E9tf=F5 13:35 To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-04.txt Pages : 25 Date : 2019-08-12 Abstract: There is a need to document data defined in YANG models when a live server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a operation/request) and decorates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-for= mat / There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-0= 4 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-fil= e-f ormat-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-instance-file-= forma t-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/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0048_01D55116.B09D3200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDgxMjEyMDMxN1owIwYJKoZIhvcNAQkEMRYEFKQQz+OhjGGAUmoHCRHJdioTCDK+MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQB8QBeBusXmykXONMCYv3gvmy6iCgmnriSp9CmWYJslWvs3wcEx973m jzjOsC2WuQZIASEmluwwwQPjpKx7pLmH62qPCkyWSD3J+jHQd8rIyH2uab633+dg64prvESnn7gP wecEhp/tDeo0q+QhaAcf/Y5ot+mAMSF0BGc8/Yzs2jo2MSCwg9/WFsusa4sS+/q2tuDpF4wPwZ5t PGk/urwp6pmwnXPlt095W7yagi2v6Qg6Lu3G85XmkkQPhsyMyleYiGpVyw8aEjtmzOzEH9i4ZNBJ ++zW2fJj+7Yy+Jmr0WxWlXgZ/Wt8mzcSx52JoolZScNFnFOP5HrNHWzqNhwhAAAAAAAA ------=_NextPart_000_0048_01D55116.B09D3200-- From nobody Mon Aug 12 14:45:57 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E054D120B8F for ; Mon, 12 Aug 2019 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 e0Fn24hcjW1T for ; Mon, 12 Aug 2019 14:45:53 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50072.outbound.protection.outlook.com [40.107.5.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3738D120F12 for ; Mon, 12 Aug 2019 05:05:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fwlMsUfdSZgnjr0NCosOe/y66RwcrEMr4OWl7kBJGEuw/6oCVse7w5wfBN88ofP+u/Ih/Cd8y5MKiZe5/L+AY9wlTIQWWWaxtgqgIYlFeL+6zfs4hgEQ5PwYnLFcU22QYg8sqkR4P4cQyrXH7rksHURM8C/i3tvvJ8XKP4/3wv3e5NUTECbdjTGoKJiAP889u2ZHQbLxeMb5hoe/f+PbB6v0wyH2JmxQIvMHGESAVH/BqCJ6a0SpfLdcfTB+Ke1ltH/hyLcQFZUNpV8+dTjOjljBxNixU7o8XwSK5DggE453rwgnl5/G7kkOSh0iW2oKZNNujCurwKfBpa8Bg5P1kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R79Nwjzl5cZyZRPG6hNX8rrUTnweU7QsIvFSBPKIL1s=; b=ifm+LdpAbuz5N8kYe3raGQVFd6XUIuUhGkS2GnDCw7q1o/1kRBJXBJeeEVW0awzoum9ismgvIh0oHzp4myxrxMxPfhDs/8nc+h20mjxtUzQf5o5xBvSSxI5I8nE5N7Yopw34aI4u+UJu3ND3iyz4SzZQ1W6mISWJZhp/N6EXw95/lMD8to/YVguzBnNnQss3MlYvRWTH2+gTKgYw54P1Jdiz10yxTeU95niofBTSTx/h9vvtlJF4+102agem+nm/B/hA+9z2Ttt71NKzQvUo6NlhlRrOw62zFlioL8hwMiY0MepyqEn0IlA4ww/QtPyRe3AMsdMVjfZlVyXlBUYACw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R79Nwjzl5cZyZRPG6hNX8rrUTnweU7QsIvFSBPKIL1s=; b=lc+d/gozTW/n3hJgdp2+PzNGyKolD9IR8o+3wWP9Bhv4hs0ITbnIPAk/FiWjbWQl2FiOcf61w4CvNdGSo3RPCvCnfz7uAaa6DPifL1cT7yKCrutY3XeWn6OKaDpxi08C5awLiDK7rncXxtBTXWiWTQKZsIfAmnUTq+GUvq64uFw= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2862.eurprd07.prod.outlook.com (10.173.73.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.15; Mon, 12 Aug 2019 12:05:24 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a%11]) with mapi id 15.20.2178.013; Mon, 12 Aug 2019 12:05:24 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSYo5A5Xk/YY0W911YNjxwP0qb3nuxA Date: Mon, 12 Aug 2019 12:05:24 +0000 Message-ID: References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> In-Reply-To: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5464ce7a-556c-4800-ba97-08d71f1d5ba4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2862; x-ms-traffictypediagnostic: VI1PR0701MB2862: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(13464003)(189003)(199004)(74316002)(25786009)(33656002)(4744005)(7736002)(6246003)(53936002)(52536014)(305945005)(5660300002)(81166006)(81156014)(8676002)(8936002)(9686003)(99286004)(6306002)(2906002)(6436002)(2501003)(229853002)(55016002)(45776006)(256004)(66446008)(64756008)(14444005)(478600001)(476003)(486006)(86362001)(966005)(66556008)(66946007)(11346002)(76116006)(66476007)(66616009)(446003)(316002)(14454004)(110136005)(26005)(6506007)(53546011)(7696005)(76176011)(3846002)(6116002)(66574012)(102836004)(186003)(66066001)(71190400001)(71200400001)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2862; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fD+FDcAk9MmQNsqQ7Araqt7joAi+N69NZANIHXIWYT9dif5VD4KqciFzbC35Mptl4kZX3n34XQiq9g4EOW/v2YXtKoF35Nwy9huM4U2GvZC3+JPR5jkeQsHKdRBEbBZRSj6J8bP7YTOyOYpxOPTYKZpOf0jLom16A2gl/+2J16alkvZ1H2do93y57ANm3/dWJLDQHSUqO+I84+VR4XERtVtw8DAQK9qA9OR74BVOxZ36avu0UBwl2/nEaHhDSxGBIFbeHp32ALPX8H4JirTs59k+1j1LKYlfIHGrhh9AgzLaZpmAyKwssVq4fyrxVtOHWWka0RCD0pSyLxf0H+fhRKIwee3ANFPJ7NguVnkvI34mgMEi5TeWu/IBOjzWilAXx3MoUS89J56Go5c5w9A4H6eNVFKV21SAIkud1NHVBro= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004C_01D55116.FBE11420" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5464ce7a-556c-4800-ba97-08d71f1d5ba4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2019 12:05:24.6630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tRF+xwrj68ocMFecHLyjqMXDTvHXo3/+T+uPr7/bIOJ9XcDeaFPThGz2z5ZpyxVI/PXXSuJFJJ6bSE0Fd0xggL71rxZTAvbFAEjRkFlFE08= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2862 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:45:55 -0000 ------=_NextPart_000_004C_01D55116.FBE11420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed the subject document and support publication.=20 Regards Balazs -----Original Message----- From: netmod On Behalf Of Kent Watsen Sent: 2019. j=FAlius 10., szerda 2:15 To: netmod@ietf.org Subject: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 All, This starts a twelve-day working group last call for draft-ietf-netmod-intf-ext-yang-07 The working group last call ends on July 21 (the day before the NETMOD = 105 sessions). Please send your comments to the working group mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, NETMOD Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_004C_01D55116.FBE11420 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDgxMjEyMDUyM1owIwYJKoZIhvcNAQkEMRYEFPITPwj6u/VcKlPeT/r/bu6ECXCnMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQA0oEP1PL1LvIgB7IaBXz95b7CF3W14ENXR/Btki5MwPCQt9ZyEjmsF c94ptBDtE2IAtDVZGSA85e2Zxcv8y8ihWQZfnzW9lL9IWVwRppk4yjCKQmg9jBD0IcrL+hIb6YwE A3Set7E+oirdYyOWghTkjgd/7IdDRy4OawMbsAPXm5WzpI1VsTjdVfISuHj75OHzsxWD8wq+RgsW NRCEzm3sE0yry/BQSzgirugoa+vo93lCQumR9Hh/fBLAiwYIrV/WP/hEZ5qqoqbU5clNrmyOi7ki AUDPjm+E0Kb8/54iVVINAsM+VPe62/C467RLtYKaw2YwF++kRKHpXhFfpXUuAAAAAAAA ------=_NextPart_000_004C_01D55116.FBE11420-- From nobody Mon Aug 12 14:50:24 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860FC120B9C for ; Mon, 12 Aug 2019 14:50:22 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=mg-soft.si Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h96nfvN1kTTY for ; Mon, 12 Aug 2019 14:50:19 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4952E121615 for ; Mon, 12 Aug 2019 06:04:58 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 0140AC417623 for ; Mon, 12 Aug 2019 15:04:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 0140AC417623 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1565615095; bh=yn3ob8tSIzBPGtBK++FtL/DRtfYNffqDHKDH4bwuVp0=; h=To:From:Subject:Date:From; b=FGF8gfoJ2lCgjPoG8I0WYxgpW6TeOsM4jszqqB9D6bZqJcAsRulcIWVELSrUrX1pe wnOO7NhbXMCxpE7iJfiADFWtDrbZb2j9EKT6jDR6tUCpN2hTIz3T9KNlDI/BlLwEei 8ZZOqyb3JdQtmVJdL3ptMT3rkYgBVLyB/zPrjpK5OE8O6Vqohk2dXnYNJqeG9s5zAR WOFCmQA4D6fC4bgDCWemdEF1rxZa7Mnf6PyLs3xiF7Q8U/qLx9Usj5mZk4FYPvZpra iP367BEGgxZI157paO75G2ubIHpIguptF0CT9Wld1k6S3Zei+mNqT0IfygyXcUKOS8 Smvz5W4U7QRHg== To: NETMOD Working Group From: Jernej Tuljak Message-ID: <8e19f280-5b63-c2d4-003b-e5e5370e9ea1@mg-soft.si> Date: Mon, 12 Aug 2019 15:04:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FD25C403F70B60B2C9595A39" Content-Language: en-US Archived-At: Subject: [netmod] RFC8526 and 'derived-from-or-self(datastore, "ds:operational")' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:50:23 -0000 This is a multi-part message in MIME format. --------------FD25C403F70B60B2C9595A39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm trying to determine who is at fault, our YANG validator implementation or the module ietf-netconf-nmda in RFC8526 . There is a "when" expression at line 193 within this module when 'derived-from-or-self(datastore, "ds:operational") '; which is under this pseudo-branch within the module: / get-data ("rpc") / input ("input") / origin-filters ("choice"). Our implementation claims that the initial context node of the expression does not contain a "datastore" child, resulting in a warning for this expression, which seemed like an obvious bug at first, but does not anymore. The accessible tree for this expression is built using the following bullet in Section 6.4.1: o If the XPath expression is defined in a substatement to an "input" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance, all state data in the server, and the running configuration datastore. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's input parameters as children. "origin-filters" for which the "when" expression is defined is clearly a substatement to an "input" statement in an "rpc" statement. Pseudo- accessible tree below (matches what our implementation does).     +- get-data         +- datastore         +- // other data node siblings of datastore     +- // top-level data nodes of all modules The initial context node is determined by using the following bullet in Section 7.21.5: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the node with the "when" statement that is also a data node. If no such node exists, the context node is the root node. The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the nodes added by the "uses", "choice", or "case" statement. The "when" statement in question is clearly a child of a "choice" statement without a data node ancestor. Neither "input" nor "rpc" represent data nodes, as per Terminology section: o data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, anydata, and anyxml. To our implementation this means that the initial context node is the root node of the accessible tree, not the node that represents the "rpc". Therefore the expression is attempting to refer to a node that is undefined. It is expecting when 'derived-from-or-self(get-data/datastore, "ds:operational") '; or something along those lines instead. Either way, something doesn't add up between RFC7950 and RFC8526. There is a suspicious verified RFC7950 errata (https://www.rfc-editor.org/errata/eid4794) dealing with initial context nodes under augments, but there's nothing for the UCC ("uses", "choice", "case") corner case. Perhaps there should be? Should Section 7.21.5 say NEW: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the node with the "when" statement that is also a data node, rpc, action or notification. If no such node exists, the context node is the root node. The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the nodes added by the "uses", "choice", or "case" statement. OLD: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the node with the "when" statement that is also a data node. If no such node exists, the context node is the root node. The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the nodes added by the "uses", "choice", or "case" statement. ? Jernej --------------FD25C403F70B60B2C9595A39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I'm trying to determine who is at fault, our YANG validator implementation or the module ietf-netconf-nmda in RFC8526 .

There is a "when" expression at line 193 within this module

when 'derived-from-or-self(datastore, "ds:operational") ';

which is under this pseudo-branch within the module: / get-data ("rpc") / input ("input") / origin-filters ("choice").

Our implementation claims that the initial context node of the expression does not contain a "datastore" child, resulting in a warning for this expression, which seemed like an obvious bug at first, but does not anymore.

The accessible tree for this expression is built using the following bullet in Section 6.4.1:

   o  If the XPath expression is defined in a substatement to an "input"
      statement in an "rpc" or "action" statement, the accessible tree
      is the RPC or action operation instance, all state data in the
      server, and the running configuration datastore.  The root node
      has top-level data nodes in all modules as children.
      Additionally, for an RPC, the root node also has the node
      representing the RPC operation being defined as a child.  The node
      representing the operation being defined has the operation's input
      parameters as children.

"origin-filters" for which the "when" expression is defined is clearly a substatement to an "input" statement in an "rpc" statement. Pseudo- accessible tree below (matches what our implementation does).

<root>
    +- get-data
        +- datastore
        +- // other data node siblings of datastore
    +- // top-level data nodes of all modules

The initial context node is determined by using the following bullet in Section 7.21.5:

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the node with the "when" statement that is also a data
      node.  If no such node exists, the context node is the root node.
      The accessible tree is tentatively altered during the processing
      of the XPath expression by removing all instances (if any) of the
      nodes added by the "uses", "choice", or "case" statement.

The "when" statement in question is clearly a child of a "choice" statement without a data node ancestor. Neither "input" nor "rpc" represent data nodes, as per Terminology section:

   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, anydata, and
      anyxml.

To our implementation this means that the initial context node is the root node of the accessible tree, not the node that represents the "rpc". Therefore the expression is attempting to refer to a node that is undefined. It is expecting

when 'derived-from-or-self(get-data/datastore, "ds:operational") ';

or something along those lines instead.

Either way, something doesn't add up between RFC7950 and RFC8526.

There is a suspicious verified RFC7950 errata (https://www.rfc-editor.org/errata/eid4794) dealing with initial context nodes under augments, but there's nothing for the UCC ("uses", "choice", "case") corner case. Perhaps there should be? Should Section 7.21.5 say

NEW:
   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the node with the "when" statement that is also a data
      node, rpc, action or notification.  If no such node exists, the
      context node is the root node. The accessible tree is tentatively
      altered during the processing of the XPath expression by removing
      all instances (if any) of the nodes added by the "uses",
      "choice", or "case" statement.
OLD:
   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the node with the "when" statement that is also a data
      node.  If no such node exists, the context node is the root node.
      The accessible tree is tentatively altered during the processing
      of the XPath expression by removing all instances (if any) of the
      nodes added by the "uses", "choice", or "case" statement.
?

Jernej

--------------FD25C403F70B60B2C9595A39-- From nobody Mon Aug 12 21:41:04 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C348120088; Mon, 12 Aug 2019 21:40:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-artwork-folding.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roni Even Message-ID: <156567125017.20459.17306464775264462092@ietfa.amsl.com> Date: Mon, 12 Aug 2019 21:40:50 -0700 Archived-At: Subject: [netmod] Genart last call review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 04:40:50 -0000 Reviewer: Roni Even 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-netmod-artwork-folding-?? Reviewer: Roni Even Review Date: 2019-08-12 IETF LC End Date: 2019-08-13 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as a BCP Major issues: Minor issues: Nits/editorial comments: From nobody Tue Aug 13 02:47:36 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802B512008F for ; Tue, 13 Aug 2019 02:47:34 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb7WgnEtes_y for ; Tue, 13 Aug 2019 02:47:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7F1200F1 for ; Tue, 13 Aug 2019 02:47:32 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id C27DE1AE0983; Tue, 13 Aug 2019 11:47:29 +0200 (CEST) Date: Tue, 13 Aug 2019 11:47:28 +0200 (CEST) Message-Id: <20190813.114728.2262411490998285952.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <8e19f280-5b63-c2d4-003b-e5e5370e9ea1@mg-soft.si> References: <8e19f280-5b63-c2d4-003b-e5e5370e9ea1@mg-soft.si> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] RFC8526 and 'derived-from-or-self(datastore, "ds:operational")' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 09:47:35 -0000 Hi, Jernej Tuljak wrote: > Hi, > = > I'm trying to determine who is at fault, our YANG validator > implementation or the module ietf-netconf-nmda in RFC8526 . > = > There is a "when" expression at line 193 within this module > = > when 'derived-from-or-self(datastore, "ds:operational") '; > = > which is under this pseudo-branch within the module: / get-data > ("rpc") / input ("input") / origin-filters ("choice"). > = > Our implementation claims that the initial context node of the > expression does not contain a "datastore" child, resulting in a > warning for this expression, which seemed like an obvious bug at > first, but does not anymore. > = > The accessible tree for this expression is built using the following > bullet in Section 6.4.1: > = > o If the XPath expression is defined in a substatement to an "inp= ut" > statement in an "rpc" or "action" statement, the accessible tre= e > is the RPC or action operation instance, all state data in the > server, and the running configuration datastore. The root node= > has top-level data nodes in all modules as children. > Additionally, for an RPC, the root node also has the node > representing the RPC operation being defined as a child. The n= ode > representing the operation being defined has the operation's in= put > parameters as children. > = > = > "origin-filters" for which the "when" expression is defined is clearl= y > a substatement to an "input" statement in an "rpc" statement. Pseudo-= > accessible tree below (matches what our implementation does). > = > > =A0=A0=A0 +- get-data > =A0=A0=A0=A0=A0=A0=A0 +- datastore > =A0=A0=A0=A0=A0=A0=A0 +- // other data node siblings of datastore > =A0=A0=A0 +- // top-level data nodes of all modules > = > The initial context node is determined by using the following bullet > in Section 7.21.5: > = > o If the "when" statement is a child of a "uses", "choice", or > "case" statement, then the context node is the closest ancestor= > node to the node with the "when" statement that is also a data > node. If no such node exists, the context node is the root nod= e. > The accessible tree is tentatively altered during the processin= g > of the XPath expression by removing all instances (if any) of t= he > nodes added by the "uses", "choice", or "case" statement. > = > = > The "when" statement in question is clearly a child of a "choice" > statement without a data node ancestor. Neither "input" nor "rpc" > represent data nodes, as per Terminology section: > = > o data node: A node in the schema tree that can be instantiated i= n a > data tree. One of container, leaf, leaf-list, list, anydata, a= nd > anyxml. > = > = > To our implementation this means that the initial context node is the= > root node of the accessible tree, not the node that represents the > "rpc". Therefore the expression is attempting to refer to a node that= > is undefined. It is expecting > = > when 'derived-from-or-self(get-data/datastore, "ds:operational") '; > = > or something along those lines instead. > = > Either way, something doesn't add up between RFC7950 and RFC8526. > = > There is a suspicious verified RFC7950 errata > (https://www.rfc-editor.org/errata/eid4794) dealing with initial > context nodes under augments, but there's nothing for the UCC ("uses"= , > "choice", "case") corner case. Perhaps there should be? Should Sectio= n > 7.21.5 say > = > NEW: > = > o If the "when" statement is a child of a "uses", "choice", or > "case" statement, then the context node is the closest ancestor= > node to the node with the "when" statement that is also a data > node, rpc, action or notification. If no such node exists, the= > context node is the root node. The accessible tree is tentative= ly > altered during the processing of the XPath expression by removi= ng > all instances (if any) of the nodes added by the "uses", > "choice", or "case" statement. > = > OLD: > = > o If the "when" statement is a child of a "uses", "choice", or > "case" statement, then the context node is the closest ancestor= > node to the node with the "when" statement that is also a data > node. If no such node exists, the context node is the root nod= e. > The accessible tree is tentatively altered during the processin= g > of the XPath expression by removing all instances (if any) of t= he > nodes added by the "uses", "choice", or "case" statement. > = > ? I think this matches the intent. As you note above, since the accessible tree is: =A0=A0=A0 +- get-data =A0=A0=A0=A0=A0=A0=A0 +- datastore =A0=A0=A0=A0=A0=A0=A0 +- // other data node siblings of datastore =A0=A0=A0 +- // top-level data nodes of all modules the context node for the "when" statement in the "choice" is supposed to be "get-data". This also makes it consistent with augment: augment /get-data/input { choice origin-filters { when 'derived-from-or-self(datastore, "ds:operational")'; ... } } /martin From nobody Tue Aug 13 04:26:19 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398D12011B for ; Tue, 13 Aug 2019 04:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLMT5VCA1GHw for ; Tue, 13 Aug 2019 04:26:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274EF12011A for ; Tue, 13 Aug 2019 04:26:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 82CE8B80E16; Tue, 13 Aug 2019 04:26:13 -0700 (PDT) To: mbj@tail-f.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jernej.tuljak@mg-soft.si, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190813112613.82CE8B80E16@rfc-editor.org> Date: Tue, 13 Aug 2019 04:26:13 -0700 (PDT) Archived-At: Subject: [netmod] [Technical Errata Reported] RFC7950 (5807) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 11:26:18 -0000 The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5807 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 7.21.5. Original Text ------------- o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the node with the "when" statement that is also a data node. If no such node exists, the context node is the root node. The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the nodes added by the "uses", "choice", or "case" statement. Corrected Text -------------- o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the node with the "when" statement that is also a data node, rpc, action or notification. If no such node exists, the context node is the root node. The accessible tree is tentatively altered during the processing of the XPath expression by removing all instances (if any) of the nodes added by the "uses", "choice", or "case" statement. Notes ----- Similar to verified errata 4794 (https://www.rfc-editor.org/errata/eid4794) but covers the "uses", "choice" and "case" corner case (instead of "augment"). If the node for which the "when" statement is defined is within an rpc, action or notification, the context node also needs to be inside that rpc, action or notification. There are published IETF modules, which rely on this to be true, such as "ietf-netconf-nmda@2019-01-07" in RFC8526 (https://tools.ietf.org/html/rfc8526) at schema node id "/ncds:get-data/ncds:input/ncds:origin-filters". Original text assigns the context node to the root node, if no data node ancestor is found. "rpc", "action" and "notification" are not data nodes and are represented by nodes that are descendants of the root node, as described in Section 6.4.1. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7950 (draft-ietf-netmod-rfc6020bis-14) -------------------------------------- Title : The YANG 1.1 Data Modeling Language Publication Date : August 2016 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Aug 13 08:32:45 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A46B120808; Tue, 13 Aug 2019 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ericsson.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 SUTTjXIcQGEE; Tue, 13 Aug 2019 08:32:32 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10088.outbound.protection.outlook.com [40.107.1.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF03120815; Tue, 13 Aug 2019 08:32:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TkhIwjmECpZ4sq/Sq8RY4W2zF/5qFvNLqZ/G2NaQAhcngHBl1pyO2DgNnpJD0pb0XTMawhRXw7r0OuInMUXoDQnRVp2FMg0K1eOA7MYPWzrKztGfWKY0NxxiRYWoPR5aoB/g/kukBt9otzdB1lL8DmGATJxRzTI0mDUoSp/6NwnOwEkjk7+bY4KQ15A8hGVId/TuWQjSBgQyfxm3XW/HocXbKxPqJP8840sbzsiDoBMpJc/NN7VOWP/nAf6ZtIPJQQtD/YTSW9NQBZ7CD3Ypu8LJzA+opTY/INqIpdf4YmLeX30dxbkXwBwOMmFX5tXWz6PCn4hp+fywTnYeKnkM3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iXYft2F9wTRKo6SSoJDgh9IDIOD1dcWKKisU2fIzrno=; b=BFaVojcHOG6YDyBI0jgV3eJbQWGbnod2FjsobO7yHtpl/+y3Bwsl2U8wX3i7fjlID2sHxLpAfZ7tvPVJGwA4JPHhawpIL7WOT1XRQO+c+gi0NebmAWYRws7dc7P3iXMbC0fnaFAP53fwA0ltz9fw5Z/bQBI107cxa1z+RxoZLic/dusvlf7FKBs2fu70vB75M6VQgSgQkvFYDFh9+AeY+4n6tebqBfQo7FGCX1uEBmSYLjrQkUM5YMJdfHocLnMzShvPdBtSxMFCLC3QThkh0MIzrlSnTEL58GLwHLH3hxTNNGSPWCZ/ofhhB1CESJMi3kkUD3X0dkoKxT4EkUTCpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iXYft2F9wTRKo6SSoJDgh9IDIOD1dcWKKisU2fIzrno=; b=moyrwQGAAIdynWjsEVqvwwgp7f16ifWDL4enMwRwwtM+KxwsucaJKZPvgT2OF0LGo+RuWcR0b/fCMUUfN5VKGhhYZT/H2c83RdVm/NbH3pZdlsFr6zM1VdK1ObxuUG8pgvVFzP/Yu719hy9FBAIpRnRuPqyhKLi5hAE7eIPX4rw= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2526.eurprd07.prod.outlook.com (10.168.140.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.15; Tue, 13 Aug 2019 15:32:27 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a%11]) with mapi id 15.20.2178.013; Tue, 13 Aug 2019 15:32:27 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netconf@ietf.org" , "'netmod@ietf.org'" Thread-Topic: Problems with lint validation Thread-Index: AdVR6w7gJOr4Q+xuS/iX1rjiqeQGGQ== Date: Tue, 13 Aug 2019 15:32:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 461c11c8-a2be-4f94-e0b4-08d72003728e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2526; x-ms-traffictypediagnostic: VI1PR0701MB2526: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(396003)(39860400002)(376002)(366004)(199004)(189003)(66616009)(7696005)(52536014)(25786009)(66446008)(450100002)(486006)(53936002)(8676002)(476003)(26005)(2906002)(186003)(316002)(45776006)(110136005)(66556008)(66476007)(76116006)(99286004)(66946007)(99936001)(64756008)(3480700005)(6506007)(5660300002)(236005)(102836004)(14444005)(2501003)(33656002)(54896002)(9326002)(9686003)(14454004)(55016002)(86362001)(6436002)(81156014)(478600001)(8936002)(256004)(66066001)(71200400001)(71190400001)(7736002)(6116002)(790700001)(3846002)(6306002)(81166006)(74316002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2526; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DGDr6dy9b61khIJac7UQJfr3CnOEnTfwa4MTWeIGKTywDN8O0pba3Wq/0vqlA1Q9jh1XSviRbhLpbIq7NlRqqfNybGK290/x++F2lueSLl//MVNzJIs3I9Z+k+jCzceBN7ZgHt3y/1Iwf8STF4tE67kHGx+527fudvlJLgrLBcs+DX/5hXsNw5ePSvcjXXJVSTf6f8yP1se0TJGn3fiDV3d8JI9MAZWzUfJ1jsFHbkLve2BgebmbD3r/OO5Nw/bJJdZwzK7xWh28A6+MwxmPr4U1STs+tcLFuKlSdS5NXM2Hd8Oi29f0n99PZ5hiczRzg0uo2fiwkL7TzyGA7VeCIXlO+VxXXuFLLhSbaG5s7v5ERVneq50cjSnyxwb0A6po99y5cLGriiXWINrNPacxl3OTWxTy6kooiYH7dF7324c= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0053_01D551FD.12F1CD30" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 461c11c8-a2be-4f94-e0b4-08d72003728e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 15:32:27.3992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iu2/AegwuuBRvH9BsFe4XyLH8wCRW84T4gL8o9SNhUY7U42dqGcuxrisfmdrspqTudTrgEy20psDMKMIAOw4PVKQddhGKNUC7UncAZwBnHU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2526 Archived-At: Subject: [netmod] Problems with lint validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 15:32:36 -0000 ------=_NextPart_000_0053_01D551FD.12F1CD30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0054_01D551FD.12F1CD30" ------=_NextPart_001_0054_01D551FD.12F1CD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I validated my model ietf-notification-capabilities@2019-08-13.yang with yangvalidator.com. My model seems fine, but I got a lot of errors from lint: yanglint Validation err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/str eam) err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/str eam) err : Invalid value "subscription-policy" of "uses". (/ietf-subscribed-notifications:subscriptions/subscription/subscription-poli cy) err : Copying data from grouping failed. (/ietf-subscribed-notifications:subscriptions/subscription/subscription-poli cy) err : Module "ietf-subscribed-notifications" parsing failed. err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" failed. err : Module "ietf-yang-push" parsing failed. err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" failed. err : Module "ietf-notification-capabilities" parsing failed. At least some of these are not really errors. (pyang, confdc accepts them) E.g. the first error is not true because the leafref has require-instance false. It would be nice if this could be corrected. I got the same messages from the draft submission tool too. Regards Balazs ------=_NextPart_001_0054_01D551FD.12F1CD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I validated = my model ietf-notif= ication-capabilities@2019-08-13.yang with yangvalidator.com. My = model seems fine, but I got a lot of errors from lint:

 

yanglint = Validation

err : The leafref = leaf is config but refers to a non-config leaf. = (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/= stream)

err : The leafref = leaf is config but refers to a non-config leaf. = (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/= stream)

err : Invalid value = "subscription-policy" of "uses". = (/ietf-subscribed-notifications:subscriptions/subscription/subscription-p= olicy)

err : Copying data = from grouping failed. = (/ietf-subscribed-notifications:subscriptions/subscription/subscription-p= olicy)

err : Module = "ietf-subscribed-notifications" parsing = failed.

err : Importing = "ietf-subscribed-notifications" module into = "ietf-yang-push" failed.

err : Module "ietf-yang-push" parsing = failed.

err : Importing = "ietf-yang-push" module into = "ietf-notification-capabilities" = failed.

err : Module = "ietf-notification-capabilities" parsing = failed.

 

At least = some of these are not really errors. (pyang, confdc accepts = them)

E.g.=A0 the first error is not = true because the leafref has require-instance false.

 

It would be = nice if this could be corrected. I got the same messages from the draft = submission tool too.

 

Regards = Balazs

------=_NextPart_001_0054_01D551FD.12F1CD30-- ------=_NextPart_000_0053_01D551FD.12F1CD30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDgxMzE1MzIyNlowIwYJKoZIhvcNAQkEMRYEFPvaHDC7jPkMnmeAZbPz+l5LGGLBMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAc4XgGTjTjVeQ2vdTpbBsnsONexNuWyO0bm3gPHa/pWvw5uPUXoaUk FWx1zohEpfqWQ651XD5tf5Js/U3cdBG5Fn/X5Y8qLFLwQMEP6vVFfookgSYD/JCtSnS3xAs9bJiN PvBeauW9ODL4VMZ/GR3oTHlAE7Bf5roQmbP/HiUNqI9eykCLpUvCpFfR80TmNMy8Zmo5tQdysBU/ YWXx4fZqiJRTGo/R4MiLdbEE3UFUp+U81EA1fWguGz464+MkpoLm/fPHrFICL8UwmwykORNAiBD1 mga6u7EKOj0MUDOb/Ge+h6vIquSUWUaIaYtnMugforgQ1xoqcym6o+BloZ3yAAAAAAAA ------=_NextPart_000_0053_01D551FD.12F1CD30-- From nobody Tue Aug 13 09:05:29 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F0A12020A for ; Tue, 13 Aug 2019 09:05:28 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emWpAhsm8Sb6 for ; Tue, 13 Aug 2019 09:05:26 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED391200FA for ; Tue, 13 Aug 2019 09:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 961A348036AB; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PilWJwiU0u6T; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6FCAF48036AC; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oFXN3GcIE-tF; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id 4547248036A9; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) To: Kent Watsen , "netmod@ietf.org" References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> From: Vladimir Vassilev Message-ID: Date: Tue, 13 Aug 2019 18:05:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 16:05:28 -0000 I have reviewed the draft. I have the following (19) IMO useful proposals= : 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the=20 oper-status debouncing/dampening functionality currently in=20 ietf-interfaces-common.yang. 2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"=20 definition can be replaced with direct reference to the oper-status leaf=20 (which is what is actually targeted by the algorithm) "Operational=20 status transition debouncing". 3. "timer-running" and "suppressed" leafs are both "config false" and=20 have "default" statements. Although this is valid YANG I do not think=20 the "default" statements are intended. 4. Dedicated module (ietf-if-loopback.yang) for the loopback=20 functionality currently in ietf-interfaces-common.yang. 5. Less verbose loopback identities. With dedicated module the=20 (loopback-* identities can be shortened skipping the prefix). 6. The draft introduces "loopback-internal", "loopback-line" and=20 "loopback-connector" loopback identities. What is confusing is that=20 "internal loopback" is historically the opposite of "external loopback"=20 which is a loopback with a connector. I think terminology already in use=20 like "near-end" and "far-end" is less confusing. 7. I am not sure standardizing the "loopback-connector" identity is=20 justified. All usecases of connecting a loopback connector I can think=20 of require the system to not be aware there is special external loopback=20 connector on the interface. 8. Some interfaces that implement "loopback-internal" do not implement=20 "loopback-line" - e.g. classical ethernetCsmacd (Carrier-sense multiple=20 access with collision detection) has a physical layer that by design can=20 not implement such loopback. Maybe introducing a dedicated feature to=20 enable the "loopback-line" is a good idea. 9. Appropriate entry in the "11. Security Considerations" noting the=20 possibility of DoS attacks and broadcast traffic storms resulting from=20 loopbacks: OLD: =C2=A0=C2=A0 The following leaf could cause the interface to go down, an= d stop =C2=A0=C2=A0 processing any ingress or egress traffic on the interface: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback NEW: =C2=A0=C2=A0 The following leaf could cause the interface to go down, an= d stop =C2=A0=C2=A0 processing any ingress or egress traffic on the interface. = It could =C2=A0=C2=A0 cause broadcast traffic storms. =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback 10. Introducing config true "forwarding-mode" leaf breaks clients that=20 support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs=20 e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by=20 introducing this new module with a new leaf they know nothing about. I=20 support this leaf as config false. If NETCONF was not transactional a=20 global leaf enabling the forwarding configuration would be a feature.=20 But NETCONF is transactional. 11. The "forwarding-mode" leaf has the following set of identities=20 {optical-layer, l2-forwarding, network-layer}. We could make the=20 identity names shorter and consistent. l1,l2,l3 or=20 physical,data-link,network. 12. I do not agree we need this text. Normally NETCONF devices should=20 accept transactions to any valid configuration: OLD: =C2=A0=C2=A0 ... =C2=A0=C2=A0 Normally devices will not allow the parent-interface leaf t= o be =C2=A0=C2=A0 changed after the interfce has been created.=C2=A0 If an im= plementation =C2=A0=C2=A0 did allow the parent-interface leaf to be changed then it c= ould cause =C2=A0=C2=A0 all traffic on the affected interface to be dropped.=C2=A0 = The affected =C2=A0=C2=A0 leaf is: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface =C2=A0=C2=A0 ... NEW: =C2=A0=C2=A0 ... =C2=A0=C2=A0 Changing the parent-interface leaf could cause =C2=A0=C2=A0 all traffic on the affected interface to be dropped. =C2=A0=C2=A0 The affected leaf is: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface =C2=A0=C2=A0 ... 13. The in-drop-unknown-dest-mac-pkts changes the behavior of the=20 in-unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not agree=20 any discarded packets in the forwarding process should be subtracted=20 from the interface counters. Here is the current description: OLD: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 For consistency, frames counted against this drop =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 counters are also counted against the IETF interfaces =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 statistics.=C2=A0 In particular, they are included in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 in-octets and in-discards, but are not included in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 in-unicast-pkts, in-multicast-pkts or in-broadcast-pkt= s, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 because they are not delivered to a higher layer. NEW: =C2=A0=C2=A0=C2=A0=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 implementation of this counter does not =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 change the behavior of the counters defined in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 IETF interfaces statistics. 14. I propose the in-pkts and out-pkts counters standardized too.=20 https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ietf-= interfaces-ext.yang.=20 And yes someone forgot to update the boilerplate text. 15. I propose that new "ietf-interfaces-common:in-discards-overflow"=20 counter is added. Currently the "ietf-interfaces:in-discards" can=20 contain both discards like the ones accumulated in=20 in-drop-unknown-dest-mac-pkts and discards caused by overflows=20 (performance related loss of packets like freeing buffer space in=20 devices that in certain cases are forwarding slower then the line=20 speed). Turns out knowing if device is discarding (loosing) packets due=20 to performance shortage and discarding (filtering) unwanted packets are=20 two different events that one needs to differentiate between are=20 currently in the same in-discards counter. We can fix that with the=20 introduction of in-discards-overflow counter. 16. We can replace=20 "ietf-interfaces-ethernet-like:in-drop-unknown-dest-mac-pkts" with=20 (in-discards - in-discards-overflow) for MAC Bridges or any other=20 Ethernet interface plus save us the introduction of technology specific=20 similar counters for the rest of the Bridges and non-Ethernet interfaces. 17. I have separately posted my arguments against introduction of leaf=20 named l2-mtu and the need of a config false leaf that has similar=20 semantics as the ifMtu object from IF-MIB. 18. Some references to relevant IEEE standards and IEEE maintained YANG=20 modules should be added (in the scope of ietf-interfaces-ethernet-like).=20 Also a few lines explaining the policy change and why none of the=20 RFC3635 managed objects are part of the new=20 ietf-interfaces-ethernet-like YANG module. 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of=20 ietf-interfaces-common.yang and ietf-interfaces-ethernet-like.yang.=20 Setting a shorter naming precedent for future modules augmenting=20 ietf-interfaces. /Vladimir On 10/07/2019 02.15, Kent Watsen wrote: > All, > > This starts a twelve-day working group last call for draft-ietf-netmod-= intf-ext-yang-07 > > The working group last call ends on July 21 (the day before the NETMOD = 105 sessions). Please send your comments to the working group mailing li= st. > > Positive comments, e.g., "I've reviewed this document and believe it is= ready for publication", are welcome! This is useful and important, even= from authors. > > Thank you, > NETMOD Chairs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Aug 13 10:24:22 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A141200D6; Tue, 13 Aug 2019 10:24:13 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mhl9qFYh; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=BZt1K6KS 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 nhIhu7C0Hkkx; Tue, 13 Aug 2019 10:24:10 -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 6086C1200B1; Tue, 13 Aug 2019 10:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22028; q=dns/txt; s=iport; t=1565717050; x=1566926650; h=from:to:subject:date:message-id:mime-version; bh=CkcB1AZVGaeesqIC/jYThCzBx5/WzwmefkEG2UzzTa4=; b=mhl9qFYhPIXdAn8q2lBWn4wHqYhxJUmO8vqIpHZNxFPLVf6XP2JngCdD H9TeRkyG+SD0XdnYmA1yXGS/fhlvyxyQIXISl4NNfBTfFBBsjemD5E7sn pvEH2qUSW/0ObTIWcAtag/wHVr2Q39A2b8VH87SJ3dYSPLcyaCcGiZ51N Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A/85hjBcinSyOUQiA0N7RhYOZlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AAA08VJd/5tdJa1mHQEBBQEHBQG?= =?us-ascii?q?BUwgBCwGBFS9QA21VIAQLKoQeg0cDhFKGPUyBaiWHOotOhFqBLhSBEANUCQE?= =?us-ascii?q?BAQwBASMKAgEBg3pFAheCZCM0CQ4BBAEBBAEBBAEKbYUnDIVKAQMDEhEdAQE?= =?us-ascii?q?4EQEIEQMBAg4aAwIEMBQJCgQBEg4UgwABgWoDHQECDKIVAoE4iGBzgTKCegE?= =?us-ascii?q?BBYEyAQMDCwJAAYJ6GIINBwmBNAGEc4Z1F4FAP4E4DBOCFzU+gmECAgEBgSo?= =?us-ascii?q?BEgEPMBaCVTKCJowyCgmCTYUOgQANgSKGUo4tCQKCHYMwglNgjU8bgx2VII1?= =?us-ascii?q?VhhyBQ5AkAgQCBAUCDgEBBYFQOGdxcBVlAYJBCYI5g3KFFIU/coEpi2sNFwe?= =?us-ascii?q?CJQEB?= X-IronPort-AV: E=Sophos;i="5.64,382,1559520000"; d="scan'208,217";a="306256160" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2019 17:24:09 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7DHO8Uf010088 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Aug 2019 17:24:09 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 13 Aug 2019 12:24:08 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 13 Aug 2019 12:24:08 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 13 Aug 2019 13:24:07 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GNCVJ4t2kZQf4yF7w0HYNCrMmlzPmpPU18w7Dw7lsYIOzLmt+PksKAkr8kwsYiPBadjNhDcmlDIMmaDpY5cHarvwDReZWttVd8B5MqrCuUaa7q/OIITuJXRFHn7+qGAsLlH0vYEqBzq69OFkEMGVuQpVFBw0jGqdj0f6/wkfOTg26xSIEF53HIWnuUYm9IwWCVzjdDpMO0Wp6Ws48S4jdTK/Bt0Ga9mphPCs0PN09gY4TX8jnXy/RzIvdfBpqtSlvL9qsTemOUJ6VdHL2Gs0NYftQOEXTwbOMEB11hYsTPdnVJQ3PcZf6BrcR0HlYtdnlkMZc+qvxEw49GZYP7QGyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j1NT2scPqbnJ5al9EUShaTi0wi2kFpgYl/FQDcS2OZU=; b=QstKkMAZGUFAFCW9Ec/PIqASw5kN5TxJgb3uDrgOHyb9qn/lrI4QGyE9XVqrnom5BG2nPERuSQr+8O4Y9b9/ZHtvTF+TkGx9iJdUkyKdIZRFo6lCMjdGgpTm7RnfCFhBS6jnglIv5n/UU5SPkL2SdNvovA4BwP7jvk5OxZU3nn+iZlwwVyBhSdHw4qclRIW4x9hktPaVJxeLwbQfv/4OfPuIu/8nc2s4moH3SRC7waHnhGzDK2SjRUt14YFpHwWGUig8DRI5AwVHYv7IQTg6/m0MvJO4612QeRHKPvs22R4wds5frShqUUpXwv2mt5ln8+tvdnHL5vLueMLwUp1Y6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j1NT2scPqbnJ5al9EUShaTi0wi2kFpgYl/FQDcS2OZU=; b=BZt1K6KSsr+bCXYzwnkZsjzCVlNV13FTN5TMuPizpUTnLwzfYkVgZLL764mO+9qlzDDkjboRoB5Y1X72ZDl2XF7UA8yiM8dikBw0BXej92JG/Y8Bh+3wown6msdnQdnYcX1FgIfJRBDIogYUd7eyulD0pgnhbY4nTKET9ln35HE= Received: from MN2PR11MB4157.namprd11.prod.outlook.com (20.179.150.223) by MN2PR11MB4301.namprd11.prod.outlook.com (52.135.36.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.23; Tue, 13 Aug 2019 17:24:06 +0000 Received: from MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::80bb:d4b:bc47:7daf]) by MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::80bb:d4b:bc47:7daf%3]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 17:24:06 +0000 From: "Reshad Rahman (rrahman)" To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" , "'netmod@ietf.org'" Thread-Topic: [netmod] Problems with lint validation Thread-Index: AQHVUfvoskOeY98d+0aVvNALs4BcMw== Date: Tue, 13 Aug 2019 17:24:05 +0000 Message-ID: <15D146FD-FD7A-451C-8655-C6BC1987CC22@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:6900:eb73:e481:aee6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17b65882-c2ed-4c6b-fadf-08d720130b4c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:MN2PR11MB4301; x-ms-traffictypediagnostic: MN2PR11MB4301: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(189003)(199004)(66574012)(99936001)(66476007)(33656002)(14444005)(36756003)(6486002)(86362001)(478600001)(76116006)(54896002)(25786009)(14454004)(6306002)(6512007)(6436002)(5024004)(66556008)(229853002)(256004)(66446008)(64756008)(66616009)(6246003)(99286004)(66946007)(486006)(53546011)(71200400001)(81156014)(81166006)(8676002)(46003)(6506007)(476003)(6116002)(2501003)(2906002)(7736002)(102836004)(5660300002)(110136005)(58126008)(316002)(236005)(53936002)(2616005)(8936002)(71190400001)(186003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4301; H:MN2PR11MB4157.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YBCFbUStiCbY7xTRdXiKWw3a3DO+vTUyRWNaQvN5VKkk2U4qBflyHn9MN1UMqQiYeaI11wRdbxkXO2egh8cyozzaGV3T8XzqyX2C5t80gn5HS9Uk01EGeG71/QhCnbvaTU2ZJlxub8NCGsrHTMCD3vde9aR2P70o6Mh2yk+minOQm9TIRceYkb2TWtLRDyizGZNJo/24CrRjWEC982/LZRGqdz/igxc4rLShbRODb5gV/2t9D9zfDd7j2Wf+NcrcatB6M92jFX+DRDSj03FR7jAJZkDdV3LwAIFEI40epcJnXUUsMbqWxlGchB3vao8+ztu3WjoIlQ2ijh9raAUVBiNrG5RKY+m9ug3uIIzivd3qU/gx4vXU3/TPInw/24EfQjSlI4bMZ3eDihvH5l2zw9y1EhPfx68j/rFKyqq7Vkk= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_15D146FDFD7A451C8655C6BC1987CC22ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 17b65882-c2ed-4c6b-fadf-08d720130b4c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 17:24:05.9877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xMKqJenwKJQQrmD9jorBtN8vNRcFRs+74HTLfXVcMUIydQNQYCBEIvp5AWTlRhxUjHOD1YtgH5RmY1HwTi8Gaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4301 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netmod] Problems with lint validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 17:24:13 -0000 --_004_15D146FDFD7A451C8655C6BC1987CC22ciscocom_ Content-Type: multipart/alternative; boundary="_000_15D146FDFD7A451C8655C6BC1987CC22ciscocom_" --_000_15D146FDFD7A451C8655C6BC1987CC22ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFsYXpzLCB3ZSByYW4gaW50byB0aGUgc2FtZSBpc3N1ZSBsYXN0IHllYXIuIElmIHlvdSBsb29r IGF0IHRoZSB0aWNrZXQgaW4gdGhlIGF0dGFjaGVkIGVtYWlsLCB5YW5nbGludCBoYXMgYSBmaXgg Zm9yIHRoZSBub24tY29uZmlnIGxlYWYgaXNzdWUgYnV0IE9wZW5TVVNFIGRvZXNu4oCZdCBoYXZl IGEgdmVyc2lvbiBvZiBsaWJ5YW5nIHdpdGggdGhlIGZpeC4NCg0KUmVnYXJkcywNClJlc2hhZC4N Cg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJh bMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPg0KRGF0ZTogVHVlc2Rh eSwgQXVndXN0IDEzLCAyMDE5IGF0IDExOjMzIEFNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxu ZXRjb25mQGlldGYub3JnPiwgIiduZXRtb2RAaWV0Zi5vcmcnIiA8bmV0bW9kQGlldGYub3JnPg0K U3ViamVjdDogW25ldG1vZF0gUHJvYmxlbXMgd2l0aCBsaW50IHZhbGlkYXRpb24NCg0KSGVsbG8s DQpJIHZhbGlkYXRlZCBteSBtb2RlbCBpZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXNAMjAx OS0wOC0xMy55YW5nPG1haWx0bzppZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXNAMjAxOS0w OC0xMy55YW5nPiB3aXRoIHlhbmd2YWxpZGF0b3IuY29tLiBNeSBtb2RlbCBzZWVtcyBmaW5lLCBi dXQgSSBnb3QgYSBsb3Qgb2YgZXJyb3JzIGZyb20gbGludDoNCg0KeWFuZ2xpbnQgVmFsaWRhdGlv bg0KZXJyIDogVGhlIGxlYWZyZWYgbGVhZiBpcyBjb25maWcgYnV0IHJlZmVycyB0byBhIG5vbi1j b25maWcgbGVhZi4gKC9pZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczpzdWJzY3JpcHRpb25z L3N1YnNjcmlwdGlvbi90YXJnZXQvc3RyZWFtL3N0cmVhbSkNCmVyciA6IFRoZSBsZWFmcmVmIGxl YWYgaXMgY29uZmlnIGJ1dCByZWZlcnMgdG8gYSBub24tY29uZmlnIGxlYWYuICgvaWV0Zi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnM6c3Vic2NyaXB0aW9ucy9zdWJzY3JpcHRpb24vdGFyZ2V0L3N0 cmVhbS9zdHJlYW0pDQplcnIgOiBJbnZhbGlkIHZhbHVlICJzdWJzY3JpcHRpb24tcG9saWN5IiBv ZiAidXNlcyIuICgvaWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6c3Vic2NyaXB0aW9ucy9z dWJzY3JpcHRpb24vc3Vic2NyaXB0aW9uLXBvbGljeSkNCmVyciA6IENvcHlpbmcgZGF0YSBmcm9t IGdyb3VwaW5nIGZhaWxlZC4gKC9pZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczpzdWJzY3Jp cHRpb25zL3N1YnNjcmlwdGlvbi9zdWJzY3JpcHRpb24tcG9saWN5KQ0KZXJyIDogTW9kdWxlICJp ZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyIgcGFyc2luZyBmYWlsZWQuDQplcnIgOiBJbXBv cnRpbmcgImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIiBtb2R1bGUgaW50byAiaWV0Zi15 YW5nLXB1c2giIGZhaWxlZC4NCmVyciA6IE1vZHVsZSAiaWV0Zi15YW5nLXB1c2giIHBhcnNpbmcg ZmFpbGVkLg0KZXJyIDogSW1wb3J0aW5nICJpZXRmLXlhbmctcHVzaCIgbW9kdWxlIGludG8gImll dGYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcyIgZmFpbGVkLg0KZXJyIDogTW9kdWxlICJpZXRm LW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMiIHBhcnNpbmcgZmFpbGVkLg0KDQpBdCBsZWFzdCBz b21lIG9mIHRoZXNlIGFyZSBub3QgcmVhbGx5IGVycm9ycy4gKHB5YW5nLCBjb25mZGMgYWNjZXB0 cyB0aGVtKQ0KRS5nLiAgdGhlIGZpcnN0IGVycm9yIGlzIG5vdCB0cnVlIGJlY2F1c2UgdGhlIGxl YWZyZWYgaGFzIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UuDQoNCkl0IHdvdWxkIGJlIG5pY2UgaWYg dGhpcyBjb3VsZCBiZSBjb3JyZWN0ZWQuIEkgZ290IHRoZSBzYW1lIG1lc3NhZ2VzIGZyb20gdGhl IGRyYWZ0IHN1Ym1pc3Npb24gdG9vbCB0b28uDQoNClJlZ2FyZHMgQmFsYXpzDQo= --_000_15D146FDFD7A451C8655C6BC1987CC22ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4ED4D22499C90D49850B6E87F9868229@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpo Mw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENo YXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox My41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI ZWFkaW5nIDMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6 IkhlYWRpbmcgMyI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC13 ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJhbGF6cywgd2UgcmFu IGludG8gdGhlIHNhbWUgaXNzdWUgbGFzdCB5ZWFyLiBJZiB5b3UgbG9vayBhdCB0aGUgdGlja2V0 IGluIHRoZSBhdHRhY2hlZCBlbWFpbCwgeWFuZ2xpbnQgaGFzIGEgZml4IGZvciB0aGUgbm9uLWNv bmZpZyBsZWFmIGlzc3VlIGJ1dCBPcGVuU1VTRSBkb2VzbuKAmXQgaGF2ZSBhIHZlcnNpb24gb2Yg bGlieWFuZyB3aXRoIHRoZSBmaXguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5S ZXNoYWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+bmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZyZndDsgb24gYmVoYWxmIG9mIEJhbMOhenMgTGVuZ3llbCAmbHQ7YmFsYXpzLmxlbmd5ZWxA ZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBBdWd1c3QgMTMsIDIw MTkgYXQgMTE6MzMgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVv dDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDsnbmV0bW9kQGlldGYub3JnJyZxdW90 OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0bW9kXSBQ cm9ibGVtcyB3aXRoIGxpbnQgdmFsaWRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdmFsaWRhdGVkIG15IG1vZGVsIDxhIGhyZWY9Im1haWx0bzppZXRmLW5v dGlmaWNhdGlvbi1jYXBhYmlsaXRpZXNAMjAxOS0wOC0xMy55YW5nIj4NCmlldGYtbm90aWZpY2F0 aW9uLWNhcGFiaWxpdGllc0AyMDE5LTA4LTEzLnlhbmc8L2E+IHdpdGggeWFuZ3ZhbGlkYXRvci5j b20uIE15IG1vZGVsIHNlZW1zIGZpbmUsIGJ1dCBJIGdvdCBhIGxvdCBvZiBlcnJvcnMgZnJvbSBs aW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0Ij55YW5nbGludCBWYWxpZGF0aW9uPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5lcnIgOiBUaGUgbGVhZnJlZiBsZWFmIGlzIGNv bmZpZyBidXQgcmVmZXJzIHRvIGEgbm9uLWNvbmZpZyBsZWFmLiAoL2lldGYtc3Vic2NyaWJlZC1u b3RpZmljYXRpb25zOnN1YnNjcmlwdGlvbnMvc3Vic2NyaXB0aW9uL3RhcmdldC9zdHJlYW0vc3Ry ZWFtKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5lcnIgOiBUaGUgbGVhZnJlZiBsZWFmIGlzIGNvbmZpZyBidXQgcmVmZXJzIHRvIGEgbm9uLWNv bmZpZyBsZWFmLiAoL2lldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOnN1YnNjcmlwdGlvbnMv c3Vic2NyaXB0aW9uL3RhcmdldC9zdHJlYW0vc3RyZWFtKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5lcnIgOiBJbnZhbGlkIHZhbHVlICZxdW90 O3N1YnNjcmlwdGlvbi1wb2xpY3kmcXVvdDsgb2YgJnF1b3Q7dXNlcyZxdW90Oy4gKC9pZXRmLXN1 YnNjcmliZWQtbm90aWZpY2F0aW9uczpzdWJzY3JpcHRpb25zL3N1YnNjcmlwdGlvbi9zdWJzY3Jp cHRpb24tcG9saWN5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5lcnIgOiBDb3B5aW5nIGRhdGEgZnJvbSBncm91cGluZyBmYWlsZWQuICgvaWV0 Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6c3Vic2NyaXB0aW9ucy9zdWJzY3JpcHRpb24vc3Vi c2NyaXB0aW9uLXBvbGljeSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+ZXJyIDogTW9kdWxlICZxdW90O2lldGYtc3Vic2NyaWJlZC1ub3RpZmlj YXRpb25zJnF1b3Q7IHBhcnNpbmcgZmFpbGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5lcnIgOiBJbXBvcnRpbmcgJnF1b3Q7aWV0Zi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnMmcXVvdDsgbW9kdWxlIGludG8gJnF1b3Q7aWV0Zi15YW5nLXB1 c2gmcXVvdDsgZmFpbGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5lcnIgOiBNb2R1bGUgJnF1b3Q7aWV0Zi15YW5nLXB1c2gmcXVvdDsgcGFy c2luZyBmYWlsZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPmVyciA6IEltcG9ydGluZyAmcXVvdDtpZXRmLXlhbmctcHVzaCZxdW90OyBtb2R1 bGUgaW50byAmcXVvdDtpZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMmcXVvdDsgZmFpbGVk Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5l cnIgOiBNb2R1bGUgJnF1b3Q7aWV0Zi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzJnF1b3Q7IHBh cnNpbmcgZmFpbGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgbGVhc3Qgc29t ZSBvZiB0aGVzZSBhcmUgbm90IHJlYWxseSBlcnJvcnMuIChweWFuZywgY29uZmRjIGFjY2VwdHMg dGhlbSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkUuZy4mbmJzcDsgdGhl IGZpcnN0IGVycm9yIGlzIG5vdCB0cnVlIGJlY2F1c2UgdGhlIGxlYWZyZWYgaGFzIHJlcXVpcmUt aW5zdGFuY2UgZmFsc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIG5pY2Ug aWYgdGhpcyBjb3VsZCBiZSBjb3JyZWN0ZWQuIEkgZ290IHRoZSBzYW1lIG1lc3NhZ2VzIGZyb20g dGhlIGRyYWZ0IHN1Ym1pc3Npb24gdG9vbCB0b28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMgQmFsYXpzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_15D146FDFD7A451C8655C6BC1987CC22ciscocom_-- --_004_15D146FDFD7A451C8655C6BC1987CC22ciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 13 Aug 2019 17:24:05 GMT"; modification-date="Tue, 13 Aug 2019 17:24:05 GMT" Content-ID: <1980670F921C8240AFD03B500FFE14DD@namprd11.prod.outlook.com> Received: from xch-aln-003.cisco.com (173.36.7.13) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Mailbox Transport; Wed, 19 Dec 2018 15:33:04 -0600 Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 15:33:03 -0600 Received: from rcdn-iport-9.cisco.com (173.37.86.80) by mail.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 19 Dec 2018 15:33:03 -0600 Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 21:33:02 +0000 Received: from alln-inbound-c.cisco.com (alln-inbound-c.cisco.com [173.37.147.233]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id wBJLWw4j023109 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 19 Dec 2018 21:33:02 GMT Received-SPF: None (alln-inbound-c.cisco.com: no sender authenticity information available from domain of trac@tools.ietf.org) identity=mailfrom; client-ip=2001:1900:3001:11::3d; receiver=alln-inbound-c.cisco.com; envelope-from="trac@tools.ietf.org"; x-sender="trac@tools.ietf.org"; x-conformance=spf_only Received-SPF: None (alln-inbound-c.cisco.com: no sender authenticity information available from domain of postmaster@durif.tools.ietf.org) identity=helo; client-ip=2001:1900:3001:11::3d; receiver=alln-inbound-c.cisco.com; envelope-from="trac@tools.ietf.org"; x-sender="postmaster@durif.tools.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-c.cisco.com; dkim=none (message not signed) header.i=none; spf=None smtp.mailfrom=trac@tools.ietf.org; spf=None smtp.helo=postmaster@durif.tools.ietf.org; dmarc=fail (p=none dis=none) d=ietf.org X-from-outside-Cisco: 2001:1900:3001:11::3d IronPort-PHdr: =?us-ascii?q?9a23=3A4ArSlxS058eFy99j5+CyU70JV9psv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa69bRaN2/xhgRfzUJnB7Loc0qyK6/CmATRIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfbB/IA+qoQnNq8IbnZZsJqEtxx?= =?us-ascii?q?XTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM3?= =?us-ascii?q?0u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xy?= =?us-ascii?q?mp4qF2QxHqlSgHLSY0/27LhcJ/jKxbuBWvqQJxzY7OfY+bN+Fzfr/fcN4AWW?= =?us-ascii?q?ZMRNpdWi5HD4ihb4UPFe0BPeNAooXzplsBswe+BQexC+z01zRIh2T23bYn0+?= =?us-ascii?q?s/DArGwBYgEMgSv3TXstr1LqkeWv2ywanU1zXMde9Z1Czh6IjPdRAhpeqMUa?= =?us-ascii?q?hxccXP1UkvGRnJjlKKqYzqJj6Y0PkGvWac7+plT+2vimgnphl+ojiu2scsip?= =?us-ascii?q?TJiZkPxl/Y8iV5xZ45JdymR05nb96oCpxQtzuVN4ZwX8gsQHlotT4kxrEapZ?= =?us-ascii?q?K3YS0HxIkjyhLDd/CKdoaF7g7/WOqMJDp0mW9pdbe6ihu87EetzPD3WNOu31?= =?us-ascii?q?ZQtCVFl8HBtnAT2BzX7ciKUuZy/lq72TaO2QDf8P1EIUczlarfMJ4t2L8wmY?= =?us-ascii?q?QPsUTNBCP2n1/2jKCOekUl/Oin9fjnb634qpOAK4N4lwTzPrkql8CjHeg1Nw?= =?us-ascii?q?YDU3SH9eih0bDv4FD1TbBPg/A4j6bVqJXaKt4apq69DQ9VyIEj6xOnAje6yt?= =?us-ascii?q?QXh2UIIUlZeBKAiIjpP0rOLOr5Dfihn1Ssni1nx/fcPr3uGpnNNGTMkK/9fb?= =?us-ascii?q?Zh7E5R0BAzzcpF6JJUD7EOOvTzV1Ttu9zZFR82Lwu0z/z7B9V604NNEV6IV7?= =?us-ascii?q?WDOaPXuFmg7eM0KO7Kb4gQ6xjnLP1wrf/jkXE1kxccZrK00NMLcnmzHfl8aQ?= =?us-ascii?q?3NfWDlif8dFmAOpUw/QfDkzlqYXmgAND6JQ6sg62RjW8qdBoDZS9X13e6t+Q?= =?us-ascii?q?6BNcQNODIeTnyJGG3jTYiPXO0AOmqKd8lmlDFAHaCqV9p4jUnq/BTinv4vJ+?= =?us-ascii?q?bX+yhNr9ar3cNt6bjJ0Vko6DUhPITS32SEVWpDl2wHbyE/2KE5rEl0y1PMle?= =?us-ascii?q?Ah26AISIMNv7INGkd1OZvV1ec/Ed3qXRjdVtaEVFjgRc+pTnV5F4ptk4JRPR?= =?us-ascii?q?48LpGkiRbOhXD4KqIJl7GNGJ0/+77d2H60Hctm1nLaz/N50AsvRs9JcGygjK?= =?us-ascii?q?li8QSWDMjCkl6SkOChcqFPlCLO9WLWy22IsQkYVQNrSqzKUDgZYVeettX24E?= =?us-ascii?q?7ODveuBL0rPxEHyJuELa1HOZXylVsTYvDlNZzFZn6p3WK5BBKG3LSJOZbwcm?= =?us-ascii?q?41wCLaDFNCkg0P8zCBLwdtTjy5rTf4CzpjXUnqf1uq8eR6ryajSVQoygiRc0?= =?us-ascii?q?B7/7ao4B8bw+CbTPcImLMJpClnrC97Tx6x2tvMAI+OrgtlNOVENNU65loP2W?= =?us-ascii?q?PC4gp6OJHhZ6w3h1MCfUJwpUy3jUdNB45NkNYnoDYR9CQpcfPK9lRHenvY1J?= =?us-ascii?q?T0PPjWLGP14RajLqWQ0VDF29HQ8aAKurw+rB34sQelG1BHkT0v2sRJ03aa+p?= =?us-ascii?q?TBDRYDGZP3XEEt8hFmprbcKiAj7oLQ3HdoPOG6qDjHk94uAeIkzF6ncbI9eO?= =?us-ascii?q?uYDgb5O9EdAMy1bu0nh1bvaQgLfahT+KMyI8K6Zq6D0a+vMvxnmWHD7ywP64?= =?us-ascii?q?R830SQsitkH7SQh89XmqDAhlncD2+l3g744JKsldMhB3laBGe0xCn6CZQEb6?= =?us-ascii?q?l2e8MKD22pPsu7g944jJ/2UHke/1mmVDZkkIekfwSfa1vl0Ehez0MS9Da7gy?= =?us-ascii?q?Kz5yBzlDUy6KuSwCKIxP7tPkliWCYDVCx5gFHgLJLhxcwAVUOAcw8ukADj5E?= =?us-ascii?q?vmye5cvqs1fCHDBExPeSbxNWRrVKC946GabflI7pc56H8Faum3bFGER7K4mC?= =?us-ascii?q?M0iHi5TU1Zwj1zNziuvpO8nhpwj3+bIDN46nHYYsp3gxzY4Y6UQ/kZxTcASC?= =?us-ascii?q?Ri7FufTlGhI9mk+8mVnJbfo6i/UWymTJhabSjsy8uJqiK64WRgBRD3keq0n5?= =?us-ascii?q?XrFg0z0Cmz0NcPN22AtBHnfozizLi3K8prY1NpChng7M1+Acd/n5c+wpYK1j?= =?us-ascii?q?lSh5mY+2YGjXamMdhf3vGbDjJFTjoKztjJpQn9jRc7divbntOhDifGmpM4NY?= =?us-ascii?q?DjMDFN1nFYjYgCEqqf4b1akDEgq168q0fQZ/J6gzERjPBo438BiOZPsw0onU?= =?us-ascii?q?D/SvgfG1dVOSv0mlGG9de7+e9Lfm+kWaS3005l29GsEL/EpRtTEiWcGN9qDW?= =?us-ascii?q?pr48NzPUiZmmX08Z3hccLMYMg7ugCOkhmGk+9SLIl3l/cWi2xgI2237hhHg6?= =?us-ascii?q?YryBdp25+9po2OLW5gqbmhDClfMDnkPpJBynTWla9b2/2u8cWqF5RlFC8MWc?= =?us-ascii?q?K2H+6vFzYJ8/XqKwjIFycz+C/CROjvWDSH4UIjlErhVpCmM3bNfisV0M9jSl?= =?us-ascii?q?+BI0tbm0YVUSk02JkjGVLyyQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8F8AADDtxpc/wAZASCDgISAEQA9ZB0?= =?us-ascii?q?BAQUBBwUBgVEIAQsBgTABTwECJz9zBAsng32IGV+LHYFog2qUGYE/PA0TEAg?= =?us-ascii?q?BAoN4RoJuGgY2CQ0BAwEBAQEBAQEBAQECaRwMgjYiDgRNOzABAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEaAg03NiBWDyYCCR0CAgNEKQUDgxuBIFQODqgSgS+ELQETQDCEewW?= =?us-ascii?q?BC4s0Fz6BQYFEgiqDUwICAQGBTV2CO4JXAolJhlaRFQkChw6KUhiRWY1Sb4t?= =?us-ascii?q?BgUY5gVZ9CIMnglCDOIUUhT8/M4EFAQGLFSuCIAEB?= X-IPAS-Result: =?us-ascii?q?A8F8AADDtxpc/wAZASCDgISAEQA9ZB0BAQUBBwUBgVEIA?= =?us-ascii?q?QsBgTABTwECJz9zBAsng32IGV+LHYFog2qUGYE/PA0TEAgBAoN4RoJuGgY2C?= =?us-ascii?q?Q0BAwEBAQEBAQEBAQECaRwMgjYiDgRNOzABAQEBAQEBAQEBAQEBAQEaAg03N?= =?us-ascii?q?iBWDyYCCR0CAgNEKQUDgxuBIFQODqgSgS+ELQETQDCEewWBC4s0Fz6BQYFEg?= =?us-ascii?q?iqDUwICAQGBTV2CO4JXAolJhlaRFQkChw6KUhiRWY1Sb4tBgUY5gVZ9CIMng?= =?us-ascii?q?lCDOIUUhT8/M4EFAQGLFSuCIAEB?= X-IronPort-AV: E=Sophos;i="5.56,374,1539648000"; d="scan'208";a="132353729" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from durif.tools.ietf.org ([IPv6:2001:1900:3001:11::3d]) by alln-inbound-c.cisco.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 19 Dec 2018 21:33:01 +0000 Received: from localhost ([::1]:45495 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1gZjSc-0007jK-AQ; Wed, 19 Dec 2018 13:32:58 -0800 From: ietfdb issue tracker X-Trac-Version: 0.12.5 Precedence: bulk CC: , Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: X-Trac-Project: ietfdb Date: Wed, 19 Dec 2018 21:32:58 +0000 Reply-To: X-URL: https://tools.ietf.org/tools/ietfdb/ Subject: [ietfdb] #2667 (Datatracker: Yang): Newer version of yanglint needed for YANG validation X-Trac-Ticket-URL: https://tools.ietf.org/tools/ietfdb/ticket/2667 Message-ID: <065.4ac72b6a900cad38d7c35386e1e68c19@tools.ietf.org> X-Trac-Ticket-ID: 2667 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rrahman@cisco.com, henrik@levkowetz.com, rjsparks@nostrum.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett X-Outbound-SMTP-Client: 173.37.147.233, alln-inbound-c.cisco.com X-Outbound-Node: alln-core-9.cisco.com Return-Path: trac@tools.ietf.org X-MS-Exchange-Organization-Network-Message-Id: 9387c5a0-26a4-475b-e4f5-08d665f98eea X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-AuthSource: XCH-ALN-003.cisco.com X-MS-Exchange-Organization-AuthAs: Anonymous Content-type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 #2667: Newer version of yanglint needed for YANG validation So datatracker still has yanglint showing these errors for https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed- notifications: yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i: err : The leafref leaf is config but refers to a non-config leaf. (/ietf- subscribed-notifications:subscriptions/subscription/target/stream/stream) This is due to issue below which was fixed in yanglint in 0.16.59 https://github.com/CESNET/libyang/issues/644 So we need datatracker to use a more recent version of yanglint. Regards, Reshad. -- -------------------------------+-------------------- Reporter: rrahman@cisco.com | Owner: Type: enhancement | Status: new Priority: major | Milestone: (None) Component: Datatracker: Yang | Version: Keywords: sprint | -------------------------------+-------------------- Ticket URL: ietfdb --_004_15D146FDFD7A451C8655C6BC1987CC22ciscocom_-- From nobody Thu Aug 15 00:30:50 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771EF12003E for ; Thu, 15 Aug 2019 00:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 YjpEbk1k7ox3 for ; Thu, 15 Aug 2019 00:30:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3522C120045 for ; Thu, 15 Aug 2019 00:30:45 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id E3A1318201C9; Thu, 15 Aug 2019 09:32:15 +0200 (CEST) Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id EB3A0182004A; Thu, 15 Aug 2019 09:31:54 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , jernej.tuljak@mg-soft.si Cc: netmod@ietf.org In-Reply-To: <20190813.114728.2262411490998285952.mbj@tail-f.com> References: <8e19f280-5b63-c2d4-003b-e5e5370e9ea1@mg-soft.si> <20190813.114728.2262411490998285952.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , jernej.tuljak@mg-soft.si, netmod@ietf.org Date: Thu, 15 Aug 2019 09:30:21 +0200 Message-ID: <87d0h6x4vm.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] RFC8526 and 'derived-from-or-self(datastore, "ds:operational")' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 07:30:48 -0000 Martin Bjorklund writes: > Hi, > > Jernej Tuljak wrote: >> Hi, >>=20 >> I'm trying to determine who is at fault, our YANG validator >> implementation or the module ietf-netconf-nmda in RFC8526 . >>=20 >> There is a "when" expression at line 193 within this module >>=20 >> when 'derived-from-or-self(datastore, "ds:operational") '; >>=20 >> which is under this pseudo-branch within the module: / get-data >> ("rpc") / input ("input") / origin-filters ("choice"). >>=20 >> Our implementation claims that the initial context node of the >> expression does not contain a "datastore" child, resulting in a >> warning for this expression, which seemed like an obvious bug at >> first, but does not anymore. >>=20 >> The accessible tree for this expression is built using the following >> bullet in Section 6.4.1: >>=20 >> o If the XPath expression is defined in a substatement to an "input" >> statement in an "rpc" or "action" statement, the accessible tree >> is the RPC or action operation instance, all state data in the >> server, and the running configuration datastore. The root node >> has top-level data nodes in all modules as children. >> Additionally, for an RPC, the root node also has the node >> representing the RPC operation being defined as a child. The node >> representing the operation being defined has the operation's input >> parameters as children. >>=20 >>=20 >> "origin-filters" for which the "when" expression is defined is clearly >> a substatement to an "input" statement in an "rpc" statement. Pseudo- >> accessible tree below (matches what our implementation does). >>=20 >> >> =C2=A0=C2=A0=C2=A0 +- get-data >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +- datastore >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +- // other data node sibling= s of datastore >> =C2=A0=C2=A0=C2=A0 +- // top-level data nodes of all modules The rules may be easier to describe if we define schema root nodes (or simi= lar name) as a special category of schema nodes. It makes sense also becaus= e all these schema root nodes have a corresponding instance node in the XPa= th tree - the invisible XPath root, rpc, input, output and notification. Lada >>=20 >> The initial context node is determined by using the following bullet >> in Section 7.21.5: >>=20 >> o If the "when" statement is a child of a "uses", "choice", or >> "case" statement, then the context node is the closest ancestor >> node to the node with the "when" statement that is also a data >> node. If no such node exists, the context node is the root node. >> The accessible tree is tentatively altered during the processing >> of the XPath expression by removing all instances (if any) of the >> nodes added by the "uses", "choice", or "case" statement. >>=20 >>=20 >> The "when" statement in question is clearly a child of a "choice" >> statement without a data node ancestor. Neither "input" nor "rpc" >> represent data nodes, as per Terminology section: >>=20 >> o data node: A node in the schema tree that can be instantiated in a >> data tree. One of container, leaf, leaf-list, list, anydata, and >> anyxml. >>=20 >>=20 >> To our implementation this means that the initial context node is the >> root node of the accessible tree, not the node that represents the >> "rpc". Therefore the expression is attempting to refer to a node that >> is undefined. It is expecting >>=20 >> when 'derived-from-or-self(get-data/datastore, "ds:operational") '; >>=20 >> or something along those lines instead. >>=20 >> Either way, something doesn't add up between RFC7950 and RFC8526. >>=20 >> There is a suspicious verified RFC7950 errata >> (https://www.rfc-editor.org/errata/eid4794) dealing with initial >> context nodes under augments, but there's nothing for the UCC ("uses", >> "choice", "case") corner case. Perhaps there should be? Should Section >> 7.21.5 say >>=20 >> NEW: >>=20 >> o If the "when" statement is a child of a "uses", "choice", or >> "case" statement, then the context node is the closest ancestor >> node to the node with the "when" statement that is also a data >> node, rpc, action or notification. If no such node exists, the >> context node is the root node. The accessible tree is tentatively >> altered during the processing of the XPath expression by removing >> all instances (if any) of the nodes added by the "uses", >> "choice", or "case" statement. >>=20 >> OLD: >>=20 >> o If the "when" statement is a child of a "uses", "choice", or >> "case" statement, then the context node is the closest ancestor >> node to the node with the "when" statement that is also a data >> node. If no such node exists, the context node is the root node. >> The accessible tree is tentatively altered during the processing >> of the XPath expression by removing all instances (if any) of the >> nodes added by the "uses", "choice", or "case" statement. >>=20 >> ? > > I think this matches the intent. As you note above, since the > accessible tree is: > > > =C2=A0=C2=A0=C2=A0 +- get-data > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +- datastore > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +- // other data node siblin= gs of datastore > =C2=A0=C2=A0=C2=A0 +- // top-level data nodes of all modules > > the context node for the "when" statement in the "choice" is supposed > to be "get-data". > > This also makes it consistent with augment: > > augment /get-data/input { > choice origin-filters { > when 'derived-from-or-self(datastore, "ds:operational")'; > ... > } > } > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka=20 Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Aug 16 13:36:43 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 834B7120131; Fri, 16 Aug 2019 13:36:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ron Bonica via Datatracker To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-artwork-folding.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ron Bonica Message-ID: <156598779447.32100.16122759941973280894@ietfa.amsl.com> Date: Fri, 16 Aug 2019 13:36:34 -0700 Archived-At: Subject: [netmod] Opsdir telechat review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 20:36:34 -0000 Reviewer: Ron Bonica Review result: Ready Well written with appropriate recommendations. I would vote "YES". From nobody Mon Aug 19 02:27:13 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2301200E3 for ; Mon, 19 Aug 2019 02:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwiTY-KFt9pt for ; Mon, 19 Aug 2019 02:27:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FFB1200B2 for ; Mon, 19 Aug 2019 02:27:10 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BF56C9AD809F225DE656 for ; Mon, 19 Aug 2019 10:27:07 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Aug 2019 10:27:06 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.9]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0439.000; Mon, 19 Aug 2019 17:23:29 +0800 From: Qin Wu To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AdVWbuoFnURVzbOjSWymVJiHz5UHjw== Date: Mon, 19 Aug 2019 09:23:28 +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.134.31.203] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 09:27:12 -0000 I have reviewed this document and have a few comments as follows: 1. Suggest to add references for imported module 2. Suggest to add a paragraph in the section 5 to explain which common type= or type in specific module is imported 3. s/ reference "Internet draft: draft-ietf-netmod-intf-ext-yang-07";/ refe= rence "RFCxxxx: Common Interface Extension YANG Data Models"; 4. I am not sure L2 MTU is common attribute applicable to all packet frame = based interface, in most case, we are using L3 MTU. >From the definition of L2 MTU " A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the maxi= mum size of a layer 2 frame that may be transmitted or received on an interface. " I am wondering this L2 MTU is related to Maximum Receive Unit defined in RF= C4638. If the answer is YES, I would suggest to rename it, but it is still = not clear whether it should be An common attribute part of ietf-interfaces-common. If it is No, I am wondering why L2 MTU is not augmented from IP address man= agement module which define common MTU attribute, also it is not clear to m= e if ietf-interfaces-common Is positioned as technology specific model? When we choose to use MTU defin= ed in RFC8344 and when we should choose to use L2 MTU defined in draft-ietf= -netmod-intf-ext-yang-07. I think L3 MTU is common and widely deployed and supported by most of imple= mentations. But go to L2 MTU: " The payload MTU available to higher layer protocols is either derived from the layer 2 MTU, taking into account the size of the layer 2 header, or is further restricted by explicit layer 3 or protocol specific MTU configuration."; " You add a lot of flexibility or multiple options, therefore I think it is h= ard to implement it. -Qin -----Original Message----- From: netmod On Behalf Of Kent Watsen Sent: 2019. j=FAlius 10., szerda 2:15 To: netmod@ietf.org Subject: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 All, This starts a twelve-day working group last call for draft-ietf-netmod-intf-ext-yang-07 The working group last call ends on July 21 (the day before the NETMOD 105 = sessions). Please send your comments to the working group mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from = authors. Thank you, NETMOD Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Aug 19 03:00:23 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E435120045 for ; Mon, 19 Aug 2019 03:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbyuqkrcH4Oc for ; Mon, 19 Aug 2019 03:00:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5188012001A for ; Mon, 19 Aug 2019 03:00:19 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 03B75E3957876E98DC34 for ; Mon, 19 Aug 2019 11:00:17 +0100 (IST) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Aug 2019 11:00:16 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.9]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0439.000; Mon, 19 Aug 2019 17:55:20 +0800 From: Qin Wu To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05 Thread-Index: AdVWb9jBrvFtuOF4QOq507Kml1QdNQ== Date: Mon, 19 Aug 2019 09:55:19 +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.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 10:00:22 -0000 SSBrbm93IHRoZSBMQyBoYXMgZW5kZWQuIEJ1dCBJIGhhdmUgYSBmZXcgc3VnZ2VzdGlvbiB0byBk cmFmdC1pZXRmLW5ldG1vZC1zdWItaW50Zi12bGFuLW1vZGVsLTA1Og0KMS4gDQpPTEQgVEVYVDoN CiINCiAgICAgaW1wb3J0IGllZWU4MDItZG90MXEtdHlwZXMgew0KICAgICAgcHJlZml4IGRvdDFx LXR5cGU7DQogICAgIH0NCiINCk5FVyBURVhUOg0KIg0KICAgICBpbXBvcnQgaWVlZTgwMi1kb3Qx cS10eXBlcyB7DQogICAgICBwcmVmaXggZG90MXEtdHlwZTsNCiAgICAgIHJlZmVyZW5jZQ0KICAg ICAgICAiSUVFRSBTdGQgODAyLjFRLTIwMTg6IFZpcnR1YWwgQnJpZGdlZCBMb2NhbCBBcmVhIE5l dHdvcmtzLiI7DQogICAgIH0NCiINCjIuIFN1Z2dlc3QgdG8gYWRkIElFRUUgU3RkIDgwMi4xUS0y MDE4IHRvIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQozLiBBcyB5b3UgZGVzY3JpYmVkIGluIGRyYWZ0 LWlldGYtbmV0bW9kLXN1Yi1pbnRmLXZsYW4tbW9kZWwsDQoiDQpTdWItaW50ZXJmYWNlICdldGgx LjAnIGlzIG5vdCBjdXJyZW50bHkgYm91bmQgdG8gYW55IHNlcnZpY2UgYW5kIGhlbmNlDQp0cmFm ZmljIGNsYXNzaWZpZWQgdG8gdGhhdCBzdWItaW50ZXJmYWNlIGlzIGRyb3BwZWQuDQoiDQpKdXN0 IHdhbnQgdG8gY29uZmlybSBiaW5kaW5nIGV0aDEuMCB0byBsMnZwbiBzZXJ2aWNlIGlzIHJlYWxp emVkIHVzaW5nIGFjIGF0dHJpYnV0ZSB3aGljaCBpcyBsZWFmcmVmIHRvIGludGVyZmFjZSBpbiB0 aGUgaW50ZXJmYWNlIG1hbmFnZW1lbnQgbW9kZWwuDQpCdXQgYXMgZGVzY3JpYmVkIGluIFJGQzg1 MjksIGJpbmRpbmcgc2VydmljZSB0byBpbnRlcmZhY2UgaXMgcmVhbGl6ZWQgYnkgdXNpbmcgdGhl IGZvbGxvd2luZzoNCiINCiAgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0K ICAgICArLS1ydyBiaW5kLW5pLW5hbWU/ICAgLT4gL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmst aW5zdGFuY2UvbmFtZQ0KICAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UvaXA6 aXB2NDoNCiAgICAgKy0tcncgYmluZC1uaS1uYW1lPyAgIC0+IC9uZXR3b3JrLWluc3RhbmNlcy9u ZXR3b3JrLWluc3RhbmNlL25hbWUNCiAgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJm YWNlL2lwOmlwdjY6DQogICAgICstLXJ3IGJpbmQtbmktbmFtZT8gICAtPiAvbmV0d29yay1pbnN0 YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lDQoiDQpJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHRo aXMgaXMgb3ZlcmRlc2lnbiBpbiBSRkM4NTI5Lg0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0N CreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2Vu dCBXYXRzZW4NCreiy83KsbzkOiAyMDE5xOo31MIxMMjVIDg6MTUNCsrVvP7IyzogbmV0bW9kQGll dGYub3JnDQrW98ziOiBbbmV0bW9kXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLXN1 Yi1pbnRmLXZsYW4tbW9kZWwtMDUNCg0KQWxsLA0KDQpUaGlzIHN0YXJ0cyBhIHR3ZWx2ZS1kYXkg d29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLXN1Yi1pbnRmLXZs YW4tbW9kZWwtMDUuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEp1bHkg MjEgKHRoZSBkYXkgYmVmb3JlIHRoZSBORVRNT0QgMTA1IHNlc3Npb25zKS4gIFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0Lg0KDQpQb3Np dGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVs aWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSEgIFRoaXMgaXMg dXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpUaGFuayB5b3UsDQpO RVRNT0QgQ2hhaXJzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Mon Aug 19 14:48:30 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7751A1208A9 for ; Mon, 19 Aug 2019 14:48:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 MzPn8F1RnVvL for ; Mon, 19 Aug 2019 14:48:10 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76A51201E4 for ; Mon, 19 Aug 2019 14:48:10 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 9948B1E0711 for ; Mon, 19 Aug 2019 15:48:08 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id zpVYhZvzaDTbozpVYhIcbG; Mon, 19 Aug 2019 15:48:08 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=Hs5Y5XbS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=FmdZ9Uzk2mMA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=IPLOiHKmnLqe8CMl__AA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BR2rGvrOMiY6WdwVsbeNb+WWGdyH5LlWcCCRSJ2X9GY=; b=LkVu6ugTIQCqkAfYZeXJiQg+0/ 34m3bhGWhhxRy1rmYYCaJ/jBzNBjTFfGXGhZ/2TfgSOZLt8K+OBqw9VHLAfuXK2QM2Lj7tCgVIA1I Num7b3Y9w93wM1qnCyF45AvgQ; Received: from [127.0.0.1] (port=13253 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hzpVY-001iup-8t; Mon, 19 Aug 2019 15:48:08 -0600 From: Lou Berger To: NetMod WG Cc: NetMod WG Chairs Message-ID: Date: Mon, 19 Aug 2019 17:48:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1hzpVY-001iup-8t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:13253 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] Draft 105 meeting minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 21:48:18 -0000 All,     Draft minutes for the Montreal meeting are available at: https://datatracker.ietf.org/meeting/105/materials/minutes-105-netmod and/or https://etherpad.ietf.org/p/notes-ietf-105-netmod Please take a look and send any comments/correction to the list. Please feel free to make proposed changes to etherpad, but be aware that only on-list discussed/approved changes will make it into the official minutes. Thank you, Lou (Kent and Joel) From nobody Tue Aug 20 11:04:40 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C33120812 for ; Tue, 20 Aug 2019 11:04:40 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OgjCv153; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RkO6hZn8 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 hla5_mi-I9Co for ; Tue, 20 Aug 2019 11:04:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A521207FC for ; Tue, 20 Aug 2019 11:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1566324278; x=1567533878; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9ISgv/mlFciKFoYmzNB1adyIgYMlwQeM9qp11oMOLqI=; b=OgjCv153REfqj3Yr+jUVeNyiz6zoRLSHdVUkbq55bPDazxfqT12MCOnK NhM02Yal4/DyQaV5fNlG59VZjAyvqFA0b+wZCtGzVW6UEs10gpTZI71kM 3M6y4IqxhBBEtBDdN2/j3cH4ft2sgZEhKzX6BHnvvy0SmcPDxMu9lXzoT E=; IronPort-PHdr: =?us-ascii?q?9a23=3ANeF7cxTgQJJTQNZCOQBN0ig4jNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYgFcRHXVlN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAAZNVxd/40NJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFEUANtVSAECyqEH4NHA4RShilNmXSBLoEkA1QJAQE?= =?us-ascii?q?BDAEBGAsKAgEBg3pFAheCPiM0CQ4CBQEBBAEBAQIBBgRthScMhUsCAQMBARA?= =?us-ascii?q?REQwBASwMDwIBCBoCJgICAiULFRACBAESIoMAAYFqAx0BAgygfgKBOIhhc4E?= =?us-ascii?q?ygnsBAQWBNgIOQYMJGIIUCYEMKAGLaBiBQD+BEAEnH4JMPoJhAQECAQEWgUc?= =?us-ascii?q?XgnQygiaPF5xCCQKCHYZojVEbgjFthkOEGIYvhB6NW4djkCsCBAIEBQIOAQE?= =?us-ascii?q?FgVA4gVhwFRohKgGCQQmCOYNyhRSFP3KBKY4UAQE?= X-IronPort-AV: E=Sophos;i="5.64,408,1559520000"; d="scan'208";a="315039965" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Aug 2019 18:04:37 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7KI4bFc029310 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Aug 2019 18:04:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 13:04:36 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 14:04:35 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 20 Aug 2019 14:04:35 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LyVb+uzvf3jPeEAd8APbDWVDkVnpfEWdh6SuoCzoPMbKQsXJrpGkdydRbVEnVE93BgzF4Jre/CRkxQ3gjqjZL/lGxttMeCFQ5//zM75wgOfIbLnwLWBO1ipuSxzjzojrwI97ECkzEndJY4ROqi1c+5EnE9aadrIUK3UTD/J3/XoXAxugPCDdZRYwwQlbiYyMd9vgsC5S+ijRPPDcLswWHb6/0FPfqhRs93OWUZt0DWnnZDK6YpLM6e3Nr5rrATehO2Sm8xGIZecwh3bung+Q7BlMKai5KEnEDKnvMlVNLBO6yKF/4ox/syGT68o4zYx5PjhzggLu3GzpUSqAczDmGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ISgv/mlFciKFoYmzNB1adyIgYMlwQeM9qp11oMOLqI=; b=SCiWvaHJbgKbstTFflZv6CceB+oeZLmN+UhCsOAHejSn+NiV+xOU5OaQh+hNZKrOmBY+x5AlaH9oq6wio/c2yLVfXLnqbLQH/Y16KyVn3CZ/hP1DkyLtNfQfMzH0fhBS3c3MF6ySP9TYkdeiqeuJUaSOjTY4glJLhsWFlqkQrwhLDC/ajV+m7sjWjM+5DHhL1bxzxtI0ESY3kQCsLmLgY6ef62oGyoEuMDOfJoxulRV9k9RW3hygX7xkEZc8cw8HGKNxfiZ2J217nYRC/yXI0T/CJWDxq7O3TCXseBZL8RqkDzYq807UPwSid3z8YBxGwIpFEPcaUpezdkVRLPtYqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ISgv/mlFciKFoYmzNB1adyIgYMlwQeM9qp11oMOLqI=; b=RkO6hZn8KhSLI3y7udovsU35S+te/t3A2Z6YoD/EwpRbJKsgTjUMoSzV5P/39B/VUfRuz/3qjedF0zXH9m73HcNyTGGAtHVmsJSTcaIhIIGQDLUk6q6ww2TvUfyrp36X28ts1Wsi70KpcRfE7uf+Eiv23oVs9kOMQ17B4jqo8gE= Received: from MN2PR11MB4157.namprd11.prod.outlook.com (20.179.150.223) by MN2PR11MB3789.namprd11.prod.outlook.com (20.178.252.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Tue, 20 Aug 2019 18:04:34 +0000 Received: from MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::80bb:d4b:bc47:7daf]) by MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::80bb:d4b:bc47:7daf%3]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 18:04:34 +0000 From: "Reshad Rahman (rrahman)" To: "netmod@ietf.org" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-01.txt Thread-Index: AQHVQAKPiXRJimWH2Uek26JIn+I9IacEQF2A Date: Tue, 20 Aug 2019 18:04:34 +0000 Message-ID: <6B5B1E86-FB1F-473C-A3BC-41917D5B52AE@cisco.com> References: <156374075648.20526.75079222214519351@ietfa.amsl.com> In-Reply-To: <156374075648.20526.75079222214519351@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:6900:eb73:e481:aee6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40d7535f-00e4-43bc-ea9a-08d72598dbbb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3789; x-ms-traffictypediagnostic: MN2PR11MB3789: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(189003)(199004)(305945005)(7736002)(966005)(99286004)(478600001)(256004)(71200400001)(14444005)(14454004)(76176011)(81166006)(36756003)(5660300002)(6306002)(6436002)(81156014)(8676002)(6512007)(25786009)(8936002)(66556008)(76116006)(66446008)(46003)(64756008)(53936002)(66946007)(186003)(486006)(11346002)(102836004)(446003)(66574012)(6486002)(476003)(2616005)(229853002)(6246003)(110136005)(71190400001)(316002)(2906002)(2501003)(33656002)(6116002)(6506007)(58126008)(66476007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3789; H:MN2PR11MB4157.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /UkapKDJFuKs4V0V72+Jkw+cekhNCdmmydSi2UDCkhapR582Z/kyzapcThcRVxmeI8JYcsVnWFgCWYsMyVGto5CI7yYXCz9sOA2IVOZoGNt+NQu18YD8R8i4YXF4pPjf1tnfighw2cregS0GLGMEL6YwKt1Xafbqhwz7lKMgnIm2TtEph9mXmUNnOcUdGcm7z0gxqv61fMA2mhp+etiukcDKrx9tp4Stq3svUpLbt2YWOVpTJdj4keu1L3p7ICeXZcpjb200nRHbMTi/wx6SFXoHRRyRObok9tY6MuQM+44QBHb19cf2gGJY6RA2gzfTQjeURjyH6endky8xUXy/bNtkBqiIFIWeYIXc1dKQqSJVRZkl1Yd30JlrJps92UryGEVPeC9okPgPixsyrrG+kb4WIp+5mP2sagYzMXM5RdI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <05C2A499C5FD664DA61C2F7099C68B2C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 40d7535f-00e4-43bc-ea9a-08d72598dbbb X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 18:04:34.4748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o3I4SIQdB33GujTFFjOPf2kV85Mqr+6M2v+/6iEoDNwHrmyaipxujIbU4zt/AHO8PPcgWt4ztoSqfu2uCCbBaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:04:40 -0000 SGkgSnVlcmdlbiwNCg0KVGhlcmUgYXJlIHdhcm5pbmdzIG9uIGRhdGF0cmFja2VyIChzZWUgYmVs b3cpIGJlY2F1c2Ugb2YgdGhlIGV4dHJhICcwJyBpbiB0aGUgZGF0ZTogZmlsZSAiaWV0Zi1pbmV0 LXR5cGVzQDIwMTktMDctMDIxLnlhbmciDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCiMgUkVBRCAv YS93d3cvaWV0Zi1mdHAveWFuZy9kcmFmdG1vZC9pZXRmLWluZXQtdHlwZXNAMjAxOS0wNy0wMjEu eWFuZw0KL2Evd3d3L2lldGYtZnRwL3lhbmcvZHJhZnRtb2QvaWV0Zi1pbmV0LXR5cGVzQDIwMTkt MDctMDIxLnlhbmc6MTogd2FybmluZzogZmlsZW5hbWUgIi9hL3d3dy9pZXRmLWZ0cC95YW5nL2Ry YWZ0bW9kL2lldGYtaW5ldC10eXBlc0AyMDE5LTA3LTAyMS55YW5nIiBzdWdnZXN0cyBpbnZhbGlk IHJldmlzaW9uICIyMDE5LTA3LTAyMSIsIHNob3VsZCBtYXRjaCAiWVlZWS1NTS1ERCINCg0KDQrv u79PbiAyMDE5LTA3LTIxLCA0OjI2IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAgIEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1v ZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KICAgIA0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAg IDogQ29tbW9uIFlBTkcgRGF0YSBUeXBlcw0KICAgICAgICAgICAgQXV0aG9yICAgICAgICAgIDog SnVlcmdlbiBTY2hvZW53YWVsZGVyDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt bmV0bW9kLXJmYzY5OTEtYmlzLTAxLnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiA0Ng0KICAg IAlEYXRlICAgICAgICAgICAgOiAyMDE5LTA3LTIxDQogICAgDQogICAgQWJzdHJhY3Q6DQogICAg ICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgY29sbGVjdGlvbiBvZiBjb21tb24gZGF0YSB0 eXBlcyB0byBiZSB1c2VkDQogICAgICAgd2l0aCB0aGUgWUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1 YWdlLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDDQogICAgICAgNjk5MS4NCiAgICANCiAg ICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1v ZC1yZmM2OTkxLWJpcy8NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbmV0bW9kLXJmYzY5OTEtYmlzLTAxDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2OTkxLWJpcy0wMQ0KICAgIA0KICAgIEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjk5MS1i aXMtMDENCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAg ICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo= From nobody Wed Aug 21 01:53:28 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB3120854; Wed, 21 Aug 2019 01:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbwIpw9nFwu6; Wed, 21 Aug 2019 01:53:24 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00133.outbound.protection.outlook.com [40.107.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD1A12081F; Wed, 21 Aug 2019 01:53:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BDPJ5NvvcgJvTJ3Dm3YbKA9+V9PjpIKFTEHYwmWMqFYIHyBeWDEL91utq3mwMQhJQUn7U7Od1Jj+ejGgmxz0HiDAHU7H7jDQfr+1ZRkpWa6q+tjBGkrocZ901Kq0RjdugPYTB18g45WN4bDR/QbCNEr3O1T8QLK974BoGjHFHrrTIKIBvATw46B9gyZb7UtUnPB0CsrYOotHho7Wecx9hW4X1+VcC9SgL2nBRf8o4CW5TCZyh18n73LnAinpvtbQ/p9M7UPUARPzoDd/sxgD44QI5kvN2tNrEpHxrxmmoQP1g2C3IP4pUTNxWHeTDGdnbeFNsBLxg+jZ/Foq+N8RuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lismW3egkoP0JCPxX4aLeqAE+dAvpE3xWxjPcc8DX8Y=; b=Q9dUYZiUyF4LiLEE1W1S3rvIll0ROgr6T5moslnjnQ/SEgJ9D82SlsN/5fitTHD/dEHBnNgx99a4LHLV/+v9ZXiMycULVsCkoAvDPUlpxzAugt/gADqwEIhXOIAJzT3tvRb2ZOPYVPo9U58d3iLtAVLIAz31xPXvN+p1hZFTnQvR244wjF6Fgnj2FbHGWFx4AZXBAT6R2i5VNRLIcpCWeMEJK4motPOojT7Quo5w7ekuG3zoXhXaswRV4213S40PROuOYrbP2kKAPCbkmiEZNnCWotpXW373m1QkWR5EikmtdTgpBkrm3b8QzCJ2i6CuF5Os3gwAj/O2MsPkcKRWEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lismW3egkoP0JCPxX4aLeqAE+dAvpE3xWxjPcc8DX8Y=; b=UkiuEgJqEkw5YW8/ZQz2JqGsK3vspOf4EwAj8dtsMjgzVil9WlBziOZ+nxmlGMF0RPMYYD/so7hH5deWSw12baq4ReYtsMXlh28eEu4J+leEOZ2B1i8dvPLsNsFC2ziVuv9SfD6pApl9x+6Chg/16OKv7qbKkVjhhDcWQyon6pY= Received: from HE1PR0701MB2283.eurprd07.prod.outlook.com (10.168.36.20) by HE1PR0701MB2140.eurprd07.prod.outlook.com (10.168.35.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.15; Wed, 21 Aug 2019 08:53:21 +0000 Received: from HE1PR0701MB2283.eurprd07.prod.outlook.com ([fe80::a55b:4fb9:4253:2d1c]) by HE1PR0701MB2283.eurprd07.prod.outlook.com ([fe80::a55b:4fb9:4253:2d1c%6]) with mapi id 15.20.2199.011; Wed, 21 Aug 2019 08:53:21 +0000 From: tom petch To: NetMod WG CC: NetMod WG Chairs Thread-Topic: import from another SDO Thread-Index: AQHVV/3icEivKjxTa06sush7JMLKYA== Date: Wed, 21 Aug 2019 08:53:21 +0000 Message-ID: <00b801d557fd$ba9d21a0$4001a8c0@gateway.2wire.net> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P123CA0009.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::21) To HE1PR0701MB2283.eurprd07.prod.outlook.com (2603:10a6:3:2b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed23b5fd-5acb-4ef1-000b-08d7261504a7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2140; x-ms-traffictypediagnostic: HE1PR0701MB2140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(366004)(39860400002)(346002)(189003)(199004)(61296003)(44736005)(6436002)(8676002)(8936002)(81166006)(71200400001)(81156014)(71190400001)(478600001)(6486002)(6512007)(9686003)(3480700005)(316002)(14454004)(256004)(99286004)(50226002)(86362001)(305945005)(7736002)(53936002)(3846002)(6116002)(66556008)(66476007)(64756008)(66446008)(66946007)(2906002)(450100002)(4326008)(25786009)(44716002)(62236002)(66066001)(4720700003)(1556002)(6916009)(5660300002)(26005)(52116002)(102836004)(486006)(186003)(476003)(81816011)(81686011)(76176011)(446003)(6506007)(4744005)(14496001)(386003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2140; H:HE1PR0701MB2283.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: naa0ef6Ue9fHeYOVncRHJ6+aTEuaiMfpfRjPvpgn6s8xITFAOGmHQIxbvV1FECAWboRsikD68SeZr3Ncx+MzCpItXR0gloiuVHiwzdVcQClG5FJ6IKp7lF1GEBYsNglLStneqGcp8yHQJnSvw4CPPxOTg5C5s7VF8I4XSvZECJJKThHkMRYAzH56j0MidfCjfCKIK/o1bvz8p664napDYjwdyUxpvdcKk72QZEYOxvvlP6goPmyJOrgSjOJcwdMraSK0pg06Oll/BwbsJH6Ww0zm4env+rujUZJbaqCMv0JQHUt7Wbe3KBl4N2Q54nxLOOUW5gyQeBSIAMnLtDwPJAKOXiFde5wc9Ih4cmve9sI979CAuPqZOAPWrgJZxzEI1KDewI/TOMdwgucLdFsXMhoyXn+7js3DLSVRe/dCCG8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed23b5fd-5acb-4ef1-000b-08d7261504a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 08:53:21.2545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VLu+IA+7lmaDx6KRnyQfqbo1oB4P8PTRc5C28xLm/bEAlCUMsuKJE0kB7iMJiza3N+cHfgA5ZZVgmSe2ElhVsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2140 Archived-At: Subject: [netmod] import from another SDO X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 08:53:27 -0000 TG9va2luZyBhdA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3Jr LXRvcG9sb2d5LTA5DQpJIHNlZSB0aGF0IGl0IGltcG9ydHMgaWVlZTgwMi1kb3QxcS10eXBlcyB7 DQogICBwcmVmaXggZG90MXEtdHlwZTsNCiAgIHJlZmVyZW5jZQ0KICAgIklFRUUgU3RkIDgwMi4x US0yMDE3OiBWaXJ0dWFsIEJyaWRnZWQgTG9jYWwgQXJlYSBOZXR3b3Jrcy4iOw0KDQpJIGhhdmUg c2VlbiB0aGlzIGJlZm9yZSB3aXRoDQogICAgICAgICAgICAgICAgIGRyYWZ0LXdpbHRvbi1uZXRt b2QtaW50Zi12bGFuLXlhbmcNCndoaWNoIEkgZG8gbm90IHRoaW5rIHByb2dyZXNzZWQuDQoNClNv LCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zLCBpbiB0ZXJtcyBvZiBwcm9ncmVzcywgb2YgZXZv bHV0aW9uLCBvZg0KdGhlIGRpZmZlcmVudCBhcHByb2FjaGVzIG9mIElFRUUgYW5kIElFVEY/ICBE b2VzIHRoZSBJRUVFIGhhdmUgdGhlIHNhbWUNCmlkZWFzIGFzIHVzIG9uIHJlZ2lzdGVyaW5nIG1v ZHVsZXMsIHdoYXQgdXBkYXRlcyBhcmUgcGVybWlzc2libGUgYW5kIHNvDQpvbj8NCg0KQW55IGlk ZWFzPw0KDQpUb20gUGV0Y2gNCg0K From nobody Wed Aug 21 02:14:13 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA171208C7; Wed, 21 Aug 2019 02:14:11 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AZkHUw+/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eE/fq+So 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 e0sfxDFvrlDG; Wed, 21 Aug 2019 02:14:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB61C12084E; Wed, 21 Aug 2019 02:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1807; q=dns/txt; s=iport; t=1566378849; x=1567588449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zMFf3XP3J3qOLAKrekWQRu6ZPojMVdLsOtP2kSieGp4=; b=AZkHUw+/GhU9asohE1jU1+zb2QiNeBG2JkVJJb59VKYyZrDnanbX82s4 FUJtVhkVgFhqbo8tRCkssPP4eQKHtp30v8Ec/0140KaPI4qYo+wJTE8PI QsPOvp59bL15YjJ7u57E6kME3RXnZ/Mc7ZcAqnBKZN6PS+eDD6uudsUf/ 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AALDoghA6rKGAQh+rj/OjUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAABvCl1d/4oNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBRFADbVUgBAsqCodcA4p8glyXZYEugSQDVAk?= =?us-ascii?q?BAQEMAQEYDQgCAQGDekUCglojNQgOAgUBAQQBAQMBBgRthScMhUoBAQEBAwE?= =?us-ascii?q?BECgGAQEsCwELBAIBCBEEAQEfECcLHQgCBAENBQgagwGBagMdAQIMnzoCgTi?= =?us-ascii?q?IYYIlgnsBAQWBMgETQYMNGIIUAwaBNAGLaBiBQD+BV4JMPoJhAQEDAYFfgzu?= =?us-ascii?q?CJqtZCQKCHYZojWyCMZYVjVuBNoYtkCsCBAIEBQIOAQEFgVIBNYFYcBU7gmy?= =?us-ascii?q?CQoNyhRSFP3IBgSiMGgGBIAEB?= X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208";a="616564116" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 09:14:08 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7L9E88I029930 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 09:14:08 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 04:14:08 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 04:14:01 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 04:14:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GWWUe+KvR/3APXtxPk5IYMs7GKqTUsHRzf0978lSX2rzG0gYTU7bPj+Q0fwz5x8/DMLp5D+ZuBN1Mz4Rx6CIjBoG0iAhNVeJaVKRUqiQ+88VBtT4QOTeTylJeUfJFTDvlaKvq4Ro85WAmGaWHLSbmBD6gbcs38Xh2yCiT3jDK4pnkhXvwpKq/8VNfo72OmhW6d611ffIFhgLfws/iJZ/tNXRv/nrUluVsk5+L1atjTnpd0a7OhiEH0jtKGm9OWqb6j08ZV8CXjFkOz8/pL/cIDbnGlP4wOXhlEe8iBFFHIgHjpVynQZUwC7q6QBCsgjnpT2+oNc3mXknR1Pj+qDv7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W+83Uy5Kio129bqAvbSxtZ4a19g0HXhEJmgbeCZDEdA=; b=lQ1CWMdYNVT9isVewjmKYeI3EnS0zFTp3FqqJAQoIctQ3WgJ67jvLYMUn2WkknAPu9ZhtR7tcL3P+FveYVxyYQ7rGSbR+0R5m9ae9BjCxnhSDpKDjPkcqmVCPtgJhDjddk52Mv5DCLsw1g8oWTUejedjt8KB7EIQw/tWVh7ZG5zx8v0xyf3rBCGqiVjBKrfZoeL/e9UrO30Ai6EuRx1lzf0U+z2tnaDWK70DbLZRNLPSq5iV08iRGX9CXFE8oL2VaZ/MarZDm4LWQ9UQWUa5hnip4/CgBL2w5diCz2WJW53Ak/L9nGh9ZLr615qK/5TqLCUEkCLnoj9T42DvAFvv3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W+83Uy5Kio129bqAvbSxtZ4a19g0HXhEJmgbeCZDEdA=; b=eE/fq+Son+/KVD522cJlOrOHkDsyTfmiaVrYqIqKTx5Fl/XkA6B6nCWocO6TPppbkwpeDLEfz+xBUINK83rUZGDY1LwibavbbqW/R8pwgLD91qYo0A3MbtndYpFDETkXsUTv0my5mv0aQydS2BQS6xiJAQ1YQ+oyGfkNMoGc0xk= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3789.namprd11.prod.outlook.com (20.178.252.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Wed, 21 Aug 2019 09:14:00 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2178.020; Wed, 21 Aug 2019 09:14:00 +0000 From: "Rob Wilton (rwilton)" To: tom petch , NetMod WG , "Scott Mansfield" CC: NetMod WG Chairs Thread-Topic: import from another SDO Thread-Index: AQHVV/34Pp+u/WtfuUWDW61TnnDvKKcFTssg Date: Wed, 21 Aug 2019 09:14:00 +0000 Message-ID: References: <00b801d557fd$ba9d21a0$4001a8c0@gateway.2wire.net> In-Reply-To: <00b801d557fd$ba9d21a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20f89cf6-6785-4640-03be-08d72617e76d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3789; x-ms-traffictypediagnostic: MN2PR11MB3789: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(346002)(136003)(396003)(189003)(13464003)(199004)(3480700005)(76176011)(186003)(476003)(446003)(11346002)(8676002)(14454004)(81156014)(7696005)(81166006)(486006)(74316002)(53936002)(66946007)(66476007)(66556008)(64756008)(66446008)(76116006)(66066001)(6506007)(53546011)(102836004)(7736002)(26005)(33656002)(229853002)(305945005)(6246003)(55016002)(6306002)(256004)(14444005)(2906002)(25786009)(86362001)(9686003)(3846002)(6116002)(52536014)(110136005)(5660300002)(966005)(8936002)(6436002)(478600001)(99286004)(71200400001)(71190400001)(296002)(316002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3789; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KSDr+E7ZPZL8prIk6rjM5SpTZc2bezeieMovVM+I1RAoi9KMIo8tcmFAH4Ne2eeeJZlMvgmhP6md0Gcl1ZEOTf7ojVfY5Kq55PIrup0t8+j9D77CaerV2u97549OXpZN+mGYHCeVVefIqIaAG172wbRBJIRjqA9icKOLWUGfh0+j9R3uAuBTpshQXj29BHGYkzQi7Kzg7d1ctVcxbD8Dvh6vSjYPfj25k4SzPDj0TF+0BAuR0iPiTtbQjolDCUQEIshpjHo0xisgbWnTd909SIT6UrTCjnASBdrN2eV0ab7STBeKP3gnyTE2fHKsvAJDjHgqtok1LTukPbiqclhkjCBtkMIQj/kVHsX8HhrLrCFncyFB6W9lKHNJ0sdKnXeS0LoWvOl2SFxVdFdw+owB3cYx3IoXRlLheNRd4hXd+9o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 20f89cf6-6785-4640-03be-08d72617e76d X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 09:14:00.3260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eHe4CFkLypklgxp2la50Xb5/JtYRNumDJzNk+GwHrRDk7bavaUc8/TR/MjTgiFbUv52hdGmzwPQQ8F39I5YF5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netmod] import from another SDO X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 09:14:12 -0000 Hi Tom, I don't think that there is an issue here. Copying Scott (as coordinator o= f IEEE YANG activities). ieee802-dot1q-types.yang is developed as part of IEEE 802.1Qcp. A copy of = the published module is available at https://github.com/YangModels/yang/blo= b/master/standard/ieee/published/802.1/ieee802-dot1q-types.yang, and that r= eferences=20 "IEEE Std 802.1Q-2018, Bridges and Bridged Networks." I don't know if they have a registry for IEEE YANG modules. But my underst= anding is that the update rules for IEEE developed YANG modules are the sam= e as IETF, i.e. currently following the rules defined in RFC 7950 chapter 1= 1. draft-wilton-netmod-intf-vlan-yang is progressing as https://datatracker.ie= tf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/. It is in Netmod WG LC. Thanks, Rob -----Original Message----- From: netmod On Behalf Of tom petch Sent: 21 August 2019 09:53 To: NetMod WG Cc: NetMod WG Chairs Subject: [netmod] import from another SDO Looking at draft-ietf-i2rs-yang-l2-network-topology-09 I see that it imports ieee802-dot1q-types { prefix dot1q-type; reference "IEEE Std 802.1Q-2017: Virtual Bridged Local Area Networks."; I have seen this before with draft-wilton-netmod-intf-vlan-yang which I do not think progressed. So, what are the implications, in terms of progress, of evolution, of the d= ifferent approaches of IEEE and IETF? Does the IEEE have the same ideas as= us on registering modules, what updates are permissible and so on? Any ideas? Tom Petch _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 21 06:59:56 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71484120052 for ; Wed, 21 Aug 2019 06:59:54 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcDshA3PAnSS for ; Wed, 21 Aug 2019 06:59:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A990D1209B7 for ; Wed, 21 Aug 2019 06:59:52 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id E4C071AE0397 for ; Wed, 21 Aug 2019 15:59:50 +0200 (CEST) Date: Wed, 21 Aug 2019 15:59:50 +0200 (CEST) Message-Id: <20190821.155950.1596034237173159188.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:59:54 -0000 Hi, Here is my (late) review of draft-ietf-netmod-intf-ext-yang-07. It is a well-written document and my comments are mostly minor. o Abstract OLD: The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. NEW: The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. o Section 1 One of the aims of this draft is to provide a standard namespace and path for these configuration items regardless of the underlying interface type. For example a standard namespace and path for "standard namespace and path" sounds a bit clumsy. In section 2 you use "standard definition", perhaps that can be use here. o General s/this internet draft/this document/g s/this draft/this document/g o Section 2 It seems this short section mostly says what is already said in section 1. Remove? o 3 The text says: o A parent interface leaf useable for all types of sub-interface that are children of parent interfaces. I suggest you add before that bullet: o A generic "sub-interface" identity that an interface identity defintion can derive from if it defines a sub-interface. o 3.1 The text says: E.g. in the case that the link state transition is suppressed then there is no change of the /if:interfaces-state/if:interface/oper-status or /if:interfaces-state/if:interfaces/last-change leaves for the interface that the feature is operating on. This should be: no change of the /if:interfaces/if:interface/oper-status or /if:interfaces/if:interfaces/last-change leaves for the interface that the feature is operating on. o 3.2 It took me some time to understand the dampening algorithm. Why is it important to talk about nominal values and that a device doesn't have to use 1000 as the penalty, as long as they scale the given values? Wouldn't it be easier to describe the algorithm w/o any nominal values, and then explain that an implementation is free to implement this algorithm in any way it wants (which of course is true for everything we do...) Otherwise, the text currently says: Implementations are not required to use a penalty of 1000 units in their dampening algorithm, but should ensure that the Suppress Threshold and Reuse Threshold values are scaled relative to the nominal 1000 unit penalty to ensure that the same configuration values provide consistent behaviour. Should "should" in this text be "SHOULD"? Or perhaps "MUST"? o 3.2.1 The text says: When the accumulated penalty reaches the default or configured suppress threshold, the interface is placed in a dampened state. The term "dampended state" occurs twice, in 3.2.1 and 3.2.3. It is not used in the YANG model. I suspect the leaf "suppressed" reflects this. Perhaps align naming. o 4 It would be useful with a sentence that describes the relationship to /if:interfaces/if:interface/if:phys-address. It seems that the mac-address leaf is useful when the mac address can be configured; otherwise if:phys-address should be sufficient, right? Should the mac-address leaf have a feature, or can we expect all implementations to support configurable mac addresses? o 4 You add a container 'statistics' under 'ethernet-like', so we have: +--rw interfaces +--rw interface* [name] ... +--ro statistics ... +--rw ethlike:ethernet-like +--ro ethlike:statistics ... Did you consider augmenting the container if:statistics instead? I think it can be useful to have all statistics in the same container in this case. o 7.2 Perhaps show the (related) 'if:oper-status' leaf as well. o 7.3 Perhaps show the (related) if:phys-address' leaf as well in the first and third examples. Before the second example, perhaps change: The following example shows an explicit MAC address being configured on interface eth0. to: The following example shows the intended configuration for interface eth0 with an explicit MAC address being configured. o YANG nits Both YANG modules list the WG chairs; we don't do that anymore. Both YANG modules have the IETF Trust Copyright statement, but not exactly as it should be (try: pyang --ietf and/or pyang --ietf-help) Many descriptions are full sentences w/o the ending ".". The reference in the revision statement should be changed to "RFC XXXX: " /martin From nobody Wed Aug 21 07:13:17 2019 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E34120152 for <netmod@ietfa.amsl.com>; Wed, 21 Aug 2019 07:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 kuUAEXfYAs12 for <netmod@ietfa.amsl.com>; Wed, 21 Aug 2019 07:13:13 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D33120052 for <netmod@ietf.org>; Wed, 21 Aug 2019 07:13:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 33EAE852; Wed, 21 Aug 2019 16:13:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id fkNQkOOz8Nac; Wed, 21 Aug 2019 16:13:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Aug 2019 16:13:11 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1229020140; Wed, 21 Aug 2019 16:13:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 2qyyxpX8pLWM; Wed, 21 Aug 2019 16:13:10 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8AC432013F; Wed, 21 Aug 2019 16:13:10 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 21 Aug 2019 16:13:09 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 990A74A1BAE; Wed, 21 Aug 2019 16:13:09 +0200 (CEST) Date: Wed, 21 Aug 2019 16:13:08 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: "Reshad Rahman (rrahman)" <rrahman@cisco.com> CC: "netmod@ietf.org" <netmod@ietf.org> Message-ID: <20190821141308.b6coemp63ut2wcmb@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mail-Followup-To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> References: <156374075648.20526.75079222214519351@ietfa.amsl.com> <6B5B1E86-FB1F-473C-A3BC-41917D5B52AE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6B5B1E86-FB1F-473C-A3BC-41917D5B52AE@cisco.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G-Tt0qtWVkM_D1RyEnihEp7sFyY> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 21 Aug 2019 14:13:16 -0000 Reshad, sorry for messing up the file name. This is fixed in my sources. /js On Tue, Aug 20, 2019 at 06:04:34PM +0000, Reshad Rahman (rrahman) wrote: > Hi Juergen, >=20 > There are warnings on datatracker (see below) because of the extra '0' = in the date: file "ietf-inet-types@2019-07-021.yang" >=20 > Regards, > Reshad. >=20 > # READ /a/www/ietf-ftp/yang/draftmod/ietf-inet-types@2019-07-021.yang > /a/www/ietf-ftp/yang/draftmod/ietf-inet-types@2019-07-021.yang:1: warni= ng: filename "/a/www/ietf-ftp/yang/draftmod/ietf-inet-types@2019-07-021.y= ang" suggests invalid revision "2019-07-021", should match "YYYY-MM-DD" >=20 >=20 > =EF=BB=BFOn 2019-07-21, 4:26 PM, "netmod on behalf of internet-drafts@i= etf.org" <netmod-bounces@ietf.org on behalf of internet-drafts@ietf.org> = wrote: >=20 > =20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Network Modeling WG of the IETF. > =20 > Title : Common YANG Data Types > Author : Juergen Schoenwaelder > Filename : draft-ietf-netmod-rfc6991-bis-01.txt > Pages : 46 > Date : 2019-07-21 > =20 > Abstract: > This document introduces a collection of common data types to be= used > with the YANG data modeling language. This document obsoletes R= FC > 6991. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ > =20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-rfc6991-bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis= -01 > =20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6991-bis-0= 1 > =20 > =20 > Please note that it may take a couple of minutes from the time of s= ubmission > until the htmlized version and diff are available at tools.ietf.org= . > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > =20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> From nobody Wed Aug 21 21:41:22 2019 Return-Path: <noreply@ietf.org> X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5212006F; Wed, 21 Aug 2019 21:41:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker <noreply@ietf.org> To: "The IESG" <iesg@ietf.org> Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba <barryleiba@computer.org> Message-ID: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 21:41:11 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3ac5tCZQszDn-9ETgVWi58pNwhA> Subject: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 04:41:12 -0000 Barry Leiba has entered the following ballot position for draft-ietf-netmod-artwork-folding-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 4.1 — 
I find the BCP 14 “SHOULD” in this section to be odd, and would lower-case them. When needed, this effort again SHOULD be automated to reduce effort and errors resulting from manual processing. This sentence is really awkward: “when needed”, the use of “effort” twice, and the uncertainty of whether the clause “resulting from manual processing” applies to both effort and errors, or only to the latter. I would say it this way: NEW This work should also be automated to reduce the effort and to reduce errors resulting from manual processing. END — Section 6 — assumes that the continuation begins at the character that is not a space character (' ') on the following line. Should be “at the first character”. — Section 7.1.1 — The second line is a blank line. The code in the appendix generates an *empty* line (no text). Is that what you mean by “blank line”? Will a line that contains only space characters (*looks* the same) work also? The code in the appendix appears to discard the second line without checking its content at all. I think you should be clearer about what qualifies as a “blank line”. (This also applies to Section 8.1.1.) — Section 7.2.1 — If this text content needs to and can be folded, insert the header described in Section 7.1.1, ensuring that any additional printable characters surrounding the header does not result in a line exceeding the desired maximum. Should be “do not result” (to match the plural “printable characters”). From nobody Thu Aug 22 02:02:35 2019 Return-Path: <adrian@olddog.co.uk> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72A5120018; Thu, 22 Aug 2019 02:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 WQxHLEJHG_tJ; Thu, 22 Aug 2019 02:02:31 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D91B120115; Thu, 22 Aug 2019 02:02:31 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7M92Ngt028042; Thu, 22 Aug 2019 10:02:28 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B266522050; Thu, 22 Aug 2019 10:02:27 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id A627C2204C; Thu, 22 Aug 2019 10:02:27 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.32.52]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7M92Pso013885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Aug 2019 10:02:26 +0100 Reply-To: <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "'Barry Leiba'" <barryleiba@computer.org>, "'The IESG'" <iesg@ietf.org> Cc: <draft-ietf-netmod-artwork-folding@ietf.org>, "'Lou Berger'" <lberger@labn.net>, <netmod-chairs@ietf.org>, <netmod@ietf.org> References: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> In-Reply-To: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 10:02:24 +0100 Organization: Old Dog Consulting Message-ID: <003d01d558c8$5211cf20$f6356d60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGcLRpVLtklUvVo/VWx3z1J6h/AJqd5NSyw Content-Language: en-gb X-Originating-IP: 84.93.32.52 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24862.004 X-TM-AS-Result: No--5.079-10.0-31-10 X-imss-scan-details: No--5.079-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24862.004 X-TMASE-Result: 10--5.079000-10.000000 X-TMASE-MatchedRID: 9d2LtCNB3NLxIbpQ8BhdbPVY7U3NX8JgPXu1L28jSnEgcEd8uJSjxOmW pqKXmZL5ZKk6eKONTfdxo9qwhEt9B2j1t8tcTt8vWqDLIdGEwFItHoY2SuDzHR3RY4pGTCyHTSy DPY8FHmcaTjuMW6GGOh+2OZjj2n0/LhiVcI0czH+zmX56C89UdzoSfZud5+GgkBqzlpo2fKoXxG DD7ldukG5YdKGEGLxcy0M3tme4VcNhaj10i6TXQMK1Ib9JAALxKINyBe8DNbJOz8YOQHnBeW4RZ q5BvfozoQDf+Z9vpFDK+QFXYp+GtbQ9b4Fxsj8uYuJV6fJ53KMCn5QffvZFlUvEK4FMJdoqgHb8 2GdiBc5PbhexfXCKb362zYU+73JAjeydHFnA4nmHjFnwsKDMDET0lGtfbK/pxQPzaZASUS2XNag pKKGTE/AGRi37Sdwo1V9OXmImeZQe442PB0TDJpK9FvwQx1hF+KI7RoRYwIbNvY+4S76i2qPFjJ EFr+ol4e8/DBwuXGd0HSe131POnrI7zVffJqTzENgEmt2wIlTtbYdIP/E8oOzUWqQLueKWDRiXX LYGavULU3ty9DPsQX7cGd19dSFd X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BEzdxAEEa4QI7xmbykc3QfEACDI> Subject: Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 09:02:34 -0000 Thanks for the review, Barry. These look like good comments to me, and I think we should fix them all. Best, Adrian -----Original Message----- From: Barry Leiba via Datatracker <noreply@ietf.org>=20 Sent: 22 August 2019 05:41 To: The IESG <iesg@ietf.org> Cc: draft-ietf-netmod-artwork-folding@ietf.org; Lou Berger = <lberger@labn.net>; netmod-chairs@ietf.org; lberger@labn.net; = netmod@ietf.org Subject: Barry Leiba's No Objection on = draft-ietf-netmod-artwork-folding-08: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-netmod-artwork-folding-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =E2=80=94 Section 4.1 =E2=80=94 =E2=80=A8I find the BCP 14 =E2=80=9CSHOULD=E2=80=9D in this section to = be odd, and would lower-case them. When needed, this effort again SHOULD be automated to reduce effort and errors resulting from manual processing. This sentence is really awkward: =E2=80=9Cwhen needed=E2=80=9D, the use = of =E2=80=9Ceffort=E2=80=9D twice, and the uncertainty of whether the clause =E2=80=9Cresulting from manual = processing=E2=80=9D applies to both effort and errors, or only to the latter. I would say = it this way: NEW This work should also be automated to reduce the effort and to reduce = errors resulting from manual processing. END =E2=80=94 Section 6 =E2=80=94 assumes that the continuation begins at the character that is not a space character (' ') on the following line. Should be =E2=80=9Cat the first character=E2=80=9D. =E2=80=94 Section 7.1.1 =E2=80=94 The second line is a blank line. The code in the appendix generates an *empty* line (no text). Is that = what you mean by =E2=80=9Cblank line=E2=80=9D? Will a line that contains only = space characters (*looks* the same) work also? The code in the appendix appears to discard the = second line without checking its content at all. I think you should be clearer = about what qualifies as a =E2=80=9Cblank line=E2=80=9D. (This also applies to = Section 8.1.1.) =E2=80=94 Section 7.2.1 =E2=80=94 If this text content needs to and can be folded, insert the header described in Section 7.1.1, ensuring that any additional printable characters surrounding the header does not result in a line exceeding the desired maximum. Should be =E2=80=9Cdo not result=E2=80=9D (to match the plural = =E2=80=9Cprintable characters=E2=80=9D). From nobody Thu Aug 22 03:13:48 2019 Return-Path: <rwilton@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86F3120815 for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 03:13:46 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ekIQ9yAs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GzwpWkCy 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 gOWQJ8R8y0eH for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 03:13:43 -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 A0B481200B2 for <netmod@ietf.org>; Thu, 22 Aug 2019 03:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21168; q=dns/txt; s=iport; t=1566468823; x=1567678423; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qODB4iofa33N2q/3v7BRAYjM7nZibojldw6y4Uy7/aI=; b=ekIQ9yAsxO6SQDjargLqfhKgpSnAd9pUdIGXx95yVccpc83MbXAC4MOS a80KXT05pHIVRYhpKo3INpTHv7Cnj5yNMdKiHZXl6yLUul6u8iKft1NpE 2GnSQvJrFUI/pz2WbMXlEsy4DQ+OEfG9RIf+jp5Fn9tZSLzgTLHPd/ZN7 s=; IronPort-PHdr: =?us-ascii?q?9a23=3AsG6o/BFsKa9d1ROZy9oE8J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAAAfal5d/4ENJK1bCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVYDAQEBCwGBRFADbVUgBAsqCoQWg0cDimhNgg+XZoJSA1QJAQE?= =?us-ascii?q?BDAEBGA8GAgEBg3pFAheCSCM3Bg4CBQEBBAEBAQIBBgRthScMhUoBAQEBAgE?= =?us-ascii?q?BARALBgQNDAEBJQcECAsEAgEGAhEEAQEBAgImAgICJQsVCAgCBAESCBqDAYF?= =?us-ascii?q?qAw4PAQIMjReQYQKBOIhhc38zgnsBAQWBMgGDZBiCFgMGgQwoAYttGIFAP4F?= =?us-ascii?q?Xgkw+gmEBAYE3LBUVgl8ygiaMHSEjEoIkhTKXEQkCgh2GaI1tgjGHMI5ojVy?= =?us-ascii?q?BNoYukCwCBAIEBQIOAQEFgWYigVhwFTuCbIJCDBeDT4UUhT4BcgGBKIh2K4E?= =?us-ascii?q?EAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,416,1559520000"; d="scan'208";a="312328572" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Aug 2019 10:13:42 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x7MADgVX013058 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Aug 2019 10:13:42 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 05:13:41 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 06:13:40 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 22 Aug 2019 06:13:39 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CDIP+X/9WBBYEmWAZgkr1pbvgBnhDJDMLuBd0WzQtsehjnS4z5WOlEavQ5bo4mM7Ytd60IFhcgjv6KscKSp0vvyDjuUOsbqa7/iydcnqWfkn4QMOnUZdQIAvAOjh7kkf9nhulPaNZ9BlaxShD17O3A2UF3ofw3+EvUWgbt2CfvJtryFO6kpl/WEUpBr3XSGv2vVhFSoQw/jiS0ayhiFoFu/Amk/rrJOhzI6HCFpV70ko4YlB6wwcprbL75cGSwmVj1bG/beV/gkGyN6zi1StiBjs3D+cFm6ClE40/FlXk5OyuM0AMm0bg6ikG/it6yakS1lDfuvi9eEtWl+dFEqZKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qODB4iofa33N2q/3v7BRAYjM7nZibojldw6y4Uy7/aI=; b=RLTCs0bpmMd9QXYc9GlmhSranWRDoTBrLbOKCmFv918rNYm4kgNZMKLAAa+wE9lE6BrCP2Op+5uHCcmviHvdegq+MBptgBOKusPwCeLZIKTKilAAkjPERTfgfEditpwl9gAR39mEe/TDTha5NcbdnIQ2JgBX8l9i5obxOfwijL+A9PMTy0j4uN9Tv4a0iJ8xG4g4Z2A0nX83mWS8YrJP7gW3c6e8GzKOT4m2ut/yhNfgurNMcefrubkP6oL2B+v6HjPR01xuWboJecuVtVBNhsTIoPYaoxa55aT9eVGpOg7BUTMAIl+cc2LxQmMQjtv8Xl+pBt9512u+1k1J7Y4sXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qODB4iofa33N2q/3v7BRAYjM7nZibojldw6y4Uy7/aI=; b=GzwpWkCymSLMK5bGTQ4gRWy3KBHgtkqPUSerJVEWRYUCG9AajBUSZdPU1+tK1MuQuQLi5+yedMn3O1N4lIfRPSGKllIhHNx44w/FJzVSV1pQMxov4GKbUHWKA8oVEbKQHeIW80gOoeF1k2WXP4RCgShN2r1ubkY8HTta6pmKLKY= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3853.namprd11.prod.outlook.com (20.178.250.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Thu, 22 Aug 2019 10:13:38 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2178.020; Thu, 22 Aug 2019 10:13:38 +0000 From: "Rob Wilton (rwilton)" <rwilton@cisco.com> To: Vladimir Vassilev <vladimir@transpacket.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6b5dGgAgAxs3iA= Date: Thu, 22 Aug 2019 10:13:38 +0000 Message-ID: <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> In-Reply-To: <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2ad6796-3603-4c89-05c8-08d726e9665d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3853; x-ms-traffictypediagnostic: MN2PR11MB3853: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: <MN2PR11MB385345636641C6532FB36D9AB5A50@MN2PR11MB3853.namprd11.prod.outlook.com> x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(366004)(136003)(39860400002)(189003)(13464003)(51444003)(199004)(52536014)(81156014)(53936002)(8936002)(966005)(30864003)(446003)(476003)(14454004)(486006)(11346002)(186003)(316002)(33656002)(81166006)(478600001)(5660300002)(7736002)(6506007)(305945005)(2906002)(53546011)(2501003)(74316002)(66476007)(71200400001)(7696005)(86362001)(66446008)(66946007)(25786009)(66556008)(64756008)(66066001)(6246003)(110136005)(71190400001)(26005)(6116002)(9686003)(6306002)(229853002)(6436002)(3846002)(76116006)(53946003)(55016002)(102836004)(14444005)(76176011)(8676002)(99286004)(256004)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3853; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Zoa/0vLQxBoeB7gE2FCUJ/E6vEyePOLvnXAG3eJPgE0qPwfB+/MFe75wtlqfU6rSObrlifv9iByCcArH2HhgNE3mVy03gY/SBiyTsoUtEu61k2ACdX0hlT7hEVrcI8e3gXgR/H5AfkTJyMUZOLvwAdipImrcp2XMD9nrsw5U5jrq6A5ROZjlPop40NegTWamMn7jp6ofWn9mIiT616qOtsqjmHvAwA7k2PfevQLyagejtXmt8z5GCX1xxVoJ2e50+U7tbyp1K//Z4Bbr8X3JI5nC90/mxgwTrIcZLSYwMcN/7o7ruxwyycRy5oC8l4vj605WmzQnoFisZSLVGX+PMxlhqrRn/103KDNKUddk7BWWmA2MMilFIoMpPxiHW4NRf5+FR0CzoT43bVIvl/+ezsKkdcLPzvBrQDv7O7ffm8s= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a2ad6796-3603-4c89-05c8-08d726e9665d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 10:13:38.1443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ltBFYDRwvRiaha92LJNB2cA6SpbmOsY2OkSUVHzs2tmpJpIG6GNGdyfyvuEkwwg8lr7wFkOmtQ7lOIz44Q+Zhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3853 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hNHBtyJKQLaxp-BENl0KvRW5Y7s> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 10:13:47 -0000 SGkgVmxhZGltaXIsDQoNClRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcuICBTb3JyeSBm b3IgdGhlIHNsb3cgcmVwbHksIEkndmUgYmVlbiBhd2F5LiAgSSdtIGFsc28gYWJvdXQgdG8gYmUg YXdheSBhZ2FpbiBmb3IgYSBjb3VwbGUgb2YgZGF5cy4NCg0KUGxlYXNlIHNlZSBteSBjb21tZW50 cyBpbmxpbmUgLi4uDQoNCkknbGwgYWxzbyB0cmFjayB0aGVzZSBpc3N1ZXMgdG8gY2xvc3VyZSBv biBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2ludGVyZmFjZS1leHRlbnNpb25zLXlhbmcv aXNzdWVzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIDxu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFZsYWRpbWlyIFZhc3NpbGV2DQo+ IFNlbnQ6IDEzIEF1Z3VzdCAyMDE5IDE3OjA1DQo+IFRvOiBLZW50IFdhdHNlbiA8a2VudCtpZXRm QHdhdHNlbi5uZXQ+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFdH IExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KPiANCj4gSSBo YXZlIHJldmlld2VkIHRoZSBkcmFmdC4gSSBoYXZlIHRoZSBmb2xsb3dpbmcgKDE5KSBJTU8gdXNl ZnVsIHByb3Bvc2FsczoNCj4gDQo+IDEuIERlZGljYXRlZCBtb2R1bGUgKGlldGYtaWYtb3Blci1z dGF0dXMtZGVib3VuY2UueWFuZykgZm9yIHRoZSBvcGVyLQ0KPiBzdGF0dXMgZGVib3VuY2luZy9k YW1wZW5pbmcgZnVuY3Rpb25hbGl0eSBjdXJyZW50bHkgaW4gaWV0Zi1pbnRlcmZhY2VzLQ0KPiBj b21tb24ueWFuZy4NCg0KSSBkb24ndCB0aGluayB0aGF0IHdlIHdhbnQgYSBwcm9saWZlcmF0aW9u IG9mIHRvbyBtYW55IHNlcGFyYXRlIFlBTkcgbW9kdWxlcyBmb3Igc21hbGwgZmVhdHVyZXMuICBF YWNoIG9mIHRoZSBhcmVhcyBvZiBkaWZmZXJlbnQgZnVuY3Rpb25hbGl0eSB3aXRoaW4gdGhpcyBt b2R1bGUgYXJlIGFscmVhZHkgY29uZGl0aW9uYWwgb24gaWYtZmVhdHVyZSwgc28gSSBkb24ndCB0 aGluayB0aGF0IHRoZXJlIGlzIGEgc3Ryb25nIGp1c3RpZmljYXRpb24gdG8gc2VwYXJhdGluZyB0 aGlzIG91dCBhcyBhIHNlcGFyYXRlIG1vZHVsZS4NCg0KDQo+IA0KPiAyLiBJbiBzZWMgIjMuMSBD YXJyaWVyIGRlbGF5IiB1c2Ugb2YgdGhlIHVuZGVyLWRlZmluZWQgIkNhcnJpZXIiDQo+IGRlZmlu aXRpb24gY2FuIGJlIHJlcGxhY2VkIHdpdGggZGlyZWN0IHJlZmVyZW5jZSB0byB0aGUgb3Blci1z dGF0dXMgbGVhZg0KPiAod2hpY2ggaXMgd2hhdCBpcyBhY3R1YWxseSB0YXJnZXRlZCBieSB0aGUg YWxnb3JpdGhtKSAiT3BlcmF0aW9uYWwgc3RhdHVzDQo+IHRyYW5zaXRpb24gZGVib3VuY2luZyIu DQoNCkkgdGhpbmsgdGhhdCBkaWZmZXJlbnQgdmVuZG9ycyBoYXZlIGRpZmZlcmVudCBuYW1lcyBm b3IgdGhpcyB0ZWNobm9sb2d5LiAgSSd2ZSBqdXN0IHVzZWQgdGhlIG9uZSB0aGF0IG91ciBwcm9k dWN0cyB1c2UuICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBqdXN0IGEgbmFtZSwgcmF0aGVyIHRoYW4g c29tZXRoaW5nIHRoYXQgaGFzIHRvIGJlIGRlZmluZWQuICBJIGNvdWxkIGFkZCBhIGNvbW1lbnQg dGhhdCB0aGlzIGZlYXR1cmUgaXMgc29tZXRpbWVzIGNhbGxlZCBob2xkIHRpbWU/DQoNCg0KPiAN Cj4gMy4gInRpbWVyLXJ1bm5pbmciIGFuZCAic3VwcHJlc3NlZCIgbGVhZnMgYXJlIGJvdGggImNv bmZpZyBmYWxzZSIgYW5kIGhhdmUNCj4gImRlZmF1bHQiIHN0YXRlbWVudHMuIEFsdGhvdWdoIHRo aXMgaXMgdmFsaWQgWUFORyBJIGRvIG5vdCB0aGluayB0aGUNCj4gImRlZmF1bHQiIHN0YXRlbWVu dHMgYXJlIGludGVuZGVkLg0KDQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBhIG1vcmUgZ2VuZXJhbCBx dWVzdGlvbiB0aGF0IG5lZWRzIGEgYml0IG1vcmUgZGlzY3Vzc2lvbi4gIEhlcmUsIEkgYW0gdXNp bmcgZGVmYXVsdHMgZm9yIHRoZSBjb25maWcgZmFsc2Ugbm9kZSB0byBkb2N1bWVudCB3aGF0IHRo ZSBub3JtYWwgdmFsdWUgaXMgZXhwZWN0ZWQuDQoNCg0KPiANCj4gNC4gRGVkaWNhdGVkIG1vZHVs ZSAoaWV0Zi1pZi1sb29wYmFjay55YW5nKSBmb3IgdGhlIGxvb3BiYWNrIGZ1bmN0aW9uYWxpdHkN Cj4gY3VycmVudGx5IGluIGlldGYtaW50ZXJmYWNlcy1jb21tb24ueWFuZy4NCg0KU2FtZSBhbnN3 ZXIgYXMgZm9yIDEuIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBzaG91bGQgaGF2ZSB0b28gbWFueSBy ZWFsbHkgc21hbGwgbW9kdWxlcy4NCg0KDQo+IA0KPiA1LiBMZXNzIHZlcmJvc2UgbG9vcGJhY2sg aWRlbnRpdGllcy4gV2l0aCBkZWRpY2F0ZWQgbW9kdWxlIHRoZQ0KPiAobG9vcGJhY2stKiBpZGVu dGl0aWVzIGNhbiBiZSBzaG9ydGVuZWQgc2tpcHBpbmcgdGhlIHByZWZpeCkuDQoNCkkgdGhpbmsg dGhhdCBpdCBpcyBub3JtYWwgdG8gYmluZCB0aGUgaWRlbnRpdHkgbmFtZXMgdG8gdGhlIGNvbW1v biBiYXNlIGlkZW50aXR5LiAgSSBkb24ndCBzZWUgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZSBpZGVu dGl0aWVzIHNob3VsZCByZWFsbHkgYmUgYW4gaXNzdWUuDQoNCg0KPiANCj4gNi4gVGhlIGRyYWZ0 IGludHJvZHVjZXMgImxvb3BiYWNrLWludGVybmFsIiwgImxvb3BiYWNrLWxpbmUiIGFuZA0KPiAi bG9vcGJhY2stY29ubmVjdG9yIiBsb29wYmFjayBpZGVudGl0aWVzLiBXaGF0IGlzIGNvbmZ1c2lu ZyBpcyB0aGF0DQo+ICJpbnRlcm5hbCBsb29wYmFjayIgaXMgaGlzdG9yaWNhbGx5IHRoZSBvcHBv c2l0ZSBvZiAiZXh0ZXJuYWwgbG9vcGJhY2siDQo+IHdoaWNoIGlzIGEgbG9vcGJhY2sgd2l0aCBh IGNvbm5lY3Rvci4gSSB0aGluayB0ZXJtaW5vbG9neSBhbHJlYWR5IGluIHVzZQ0KPiBsaWtlICJu ZWFyLWVuZCIgYW5kICJmYXItZW5kIiBpcyBsZXNzIGNvbmZ1c2luZy4NCg0KVGhlIGludGVybmFs L2xpbmUgbG9vcGJhY2sgY29uZmlndXJhdGlvbiBoYXMgYmVlbiB1c2VkIGluIHBhcnRzIG9mIHRo ZSBpbmR1c3RyeSBmb3IgYXQgbGVhc3QgMjAgeWVhcnMsIHNvIHRoaXMgdGVybWlub2xvZ3kgaXMg YWxyZWFkeSBpbiB1c2UuDQoNCkknbSBub3Qgc3VyZSB0aGF0ICJuZWFyLWVuZCIgYW5kICJmYXIt ZW5kIiB3b3VsZCBiZSBsZXNzIGNvbmZ1c2luZy4gIEFzc3VtaW5nIHRoYXQgImxvb3BiYWNrIGZh ci1lbmQiIHdhcyBlcXVpdmFsZW50IHRvICJsb29wYmFjay1saW5lIiB0aGVuIGl0IHdvdWxkIGJl IHNvbWV3aGF0IG9mIGEgbWlzbm9tZXIgc2luY2UgaXQgYWN0cyBvbiB0aGUgbmVhciBlbmQsIG5v dCB0aGUgZmFyIGVuZC4NCg0KSS5lLiBib3RoIGxvb3BiYWNrIGludGVybmFsLCBhbmQgbG9vcGJh Y2sgbGluZSBhY3Qgb24gdGhlIGxvY2FsIGludGVyZmFjZSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBp cyBpbiB3aGljaCBkaXJlY3Rpb24gdGhleSByZWZsZWN0IHRoZSBzaWduYWxzLCBpLmUuIEVncmVz cyAtPiBJbmdyZXNzIChpbnRlcm5hbCksIG9yIEluZ3Jlc3MgLT4gRWdyZXNzIChsaW5lKS4NCg0K UGVyaGFwcyB0aGUgZGVzY3JpcHRpb24gdGV4dCBjb3VsZCBiZSBzbGlnaHRseSBjbGFyaWZpZWQg aGVyZSB0byBoZWxwIGF2b2lkIGNvbmZ1c2lvbj8NCg0KT0xEOg0KDQogICBUaGUgZm9sbG93aW5n IGxvb3BiYWNrIG1vZGVzIGFyZSBkZWZpbmVkOg0KDQogICBvICBJbnRlcm5hbCBsb29wYmFjayAt IEFsbCBlZ3Jlc3MgdHJhZmZpYyBvbiB0aGUgaW50ZXJmYWNlIGlzDQogICAgICBpbnRlcm5hbGx5 IGxvb3BlZCBiYWNrIHdpdGhpbiB0aGUgaW50ZXJmYWNlIHRvIGJlIHJlY2VpdmVkIG9uIHRoZQ0K ICAgICAgaW5ncmVzcyBwYXRoLg0KDQogICBvICBMaW5lIGxvb3BiYWNrIC0gQWxsIGluZ3Jlc3Mg dHJhZmZpYyByZWNlaXZlZCBvbiB0aGUgaW50ZXJmYWNlIGlzDQogICAgICBpbnRlcm5hbGx5IGxv b3BlZCBiYWNrIHdpdGhpbiB0aGUgaW50ZXJmYWNlIHRvIHRoZSBlZ3Jlc3MgcGF0aC4NCg0KICAg byAgTG9vcGJhY2sgQ29ubmVjdG9yIC0gVGhlIGludGVyZmFjZSBoYXMgYSBwaHlzaWNhbCBsb29w YmFjaw0KICAgICAgY29ubmVjdG9yIGF0dGFjaGVkIHRoYXQgbG9vcHMgYWxsIGVncmVzcyB0cmFm ZmljIGJhY2sgaW50byB0aGUNCiAgICAgIGludGVyZmFjZSdzIGluZ3Jlc3MgcGF0aCwgd2l0aCBl cXVpdmFsZW50IHNlbWFudGljcyB0byBpbnRlcm5hbA0KICAgICAgbG9vcGJhY2suDQoNCk5FVzoN Cg0KICAgVGhlIGZvbGxvd2luZyBsb29wYmFjayBtb2RlcyBhcmUgZGVmaW5lZDoNCg0KICAgbyAg SW50ZXJuYWwgbG9vcGJhY2sgLSBBbGwgZnJhbWVzIHRoYXQgZWdyZXNzIG91dCBvZiB0aGUgaW50 ZXJmYWNlDQogICAgICBhcmUgbG9vcGVkIGJhY2sgaW50ZXJuYWxseSB3aXRoaW4gdGhlIGludGVy ZmFjZSBoYXJkd2FyZQ0KICAgICAgdG8gYmUgcmVjZWl2ZWQgb24gdGhlIGluZ3Jlc3MgcGF0aC4N Cg0KICAgbyAgTGluZSBsb29wYmFjayAtIEFsbCBpbmdyZXNzIGZyYW1lcyByZWNlaXZlZCBvbiB0 aGUgaW50ZXJmYWNlIGZyb20NCiAgICAgIHRoZSBsaW5lIGFyZSBsb29wZWQgYmFjayB3aXRoaW4g dGhlIGludGVyZmFjZSBoYXJkd2FyZSBhbmQNCiAgICAgIHRyYW5zbWl0dGVkIGJhY2sgb3V0IG9m IHRoZSBpbnRlcmZhY2UuDQoNCiAgIG8gIExvb3BiYWNrIGNvbm5lY3RvciAtIFRoZSBpbnRlcmZh Y2UgaGFzIGEgcGh5c2ljYWwgbG9vcGJhY2sNCiAgICAgIGNvbm5lY3RvciBhdHRhY2hlZCB0aGF0 IGxvb3BzIGFsbCBlZ3Jlc3MgZnJhbWVzIGJhY2sgaW50byB0aGUNCiAgICAgIGludGVyZmFjZSdz IGluZ3Jlc3MgcGF0aCwgd2l0aCBlcXVpdmFsZW50IHNlbWFudGljcyB0byBpbnRlcm5hbA0KICAg ICAgbG9vcGJhY2suDQoNCj4gDQo+IDcuIEkgYW0gbm90IHN1cmUgc3RhbmRhcmRpemluZyB0aGUg Imxvb3BiYWNrLWNvbm5lY3RvciIgaWRlbnRpdHkgaXMNCj4ganVzdGlmaWVkLiBBbGwgdXNlY2Fz ZXMgb2YgY29ubmVjdGluZyBhIGxvb3BiYWNrIGNvbm5lY3RvciBJIGNhbiB0aGluayBvZg0KPiBy ZXF1aXJlIHRoZSBzeXN0ZW0gdG8gbm90IGJlIGF3YXJlIHRoZXJlIGlzIHNwZWNpYWwgZXh0ZXJu YWwgbG9vcGJhY2sNCj4gY29ubmVjdG9yIG9uIHRoZSBpbnRlcmZhY2UuDQoNCkkgdGhpbmsgdGhh dCBpdCB3aWxsIGRlcGVuZCBvbiBob3cgc21hcnQgb2YgZHVtYiB0aGUgZXh0ZXJuYWwgbG9vcGJh Y2sgY29ubmVjdG9yIGlzLiAgSWYgaXQgaXMganVzdCBhIGR1bWIgZWxlY3RyaWNhbCBvciBvcHRp Y2FsIGxvb3BiYWNrIHRoZW4gdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDIGFkZHJlc3Nl cyBuZWVkIHRvIGJlIHN3YXBwZWQsIG9yIG90aGVyd2lzZSBhbnkgZWdyZXNzIGZyYW1lcyBvdXQg b2YgdGhlIGludGVyZmFjZSB3aWxsIGZhaWwgdGhlIGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIGZp bHRlciB3aGVuIHRoZXkgYXJlIGxvb3BlZCBhcm91bmQuDQoNClNvbWUgaW1wbGVtZW50YXRpb25z IGFsc28gdXNlIHRoaXMgY29uZmlndXJhdGlvbiB0byBmb3JjZSBzZWxmIHBpbmcgcGFja2V0cyBv dXQgdGhyb3VnaCB0aGUgaW50ZXJmYWNlLCBzbyB0aGF0IHRoZSBmdWxsIGRhdGFwYXRoIGlzIHRl c3RlZCwgcmF0aGVyIHRoYW4gdGhlIHBhY2tldHMgYmVpbmcgbG9vcGVkIGludGVybmFsbHkgd2l0 aGluIHRoZSBMMyBmb3J3YXJkaW5nIGNvZGUuDQoNCg0KPiANCj4gOC4gU29tZSBpbnRlcmZhY2Vz IHRoYXQgaW1wbGVtZW50ICJsb29wYmFjay1pbnRlcm5hbCIgZG8gbm90IGltcGxlbWVudA0KPiAi bG9vcGJhY2stbGluZSIgLSBlLmcuIGNsYXNzaWNhbCBldGhlcm5ldENzbWFjZCAoQ2Fycmllci1z ZW5zZSBtdWx0aXBsZQ0KPiBhY2Nlc3Mgd2l0aCBjb2xsaXNpb24gZGV0ZWN0aW9uKSBoYXMgYSBw aHlzaWNhbCBsYXllciB0aGF0IGJ5IGRlc2lnbiBjYW4NCj4gbm90IGltcGxlbWVudCBzdWNoIGxv b3BiYWNrLiBNYXliZSBpbnRyb2R1Y2luZyBhIGRlZGljYXRlZCBmZWF0dXJlIHRvDQo+IGVuYWJs ZSB0aGUgImxvb3BiYWNrLWxpbmUiIGlzIGEgZ29vZCBpZGVhLg0KDQpJJ20gbm90IHN1cmUgb24g dGhpcyBvbmUsIGkuZS4gd2hldGhlciBpdCByZWFsbHkgaGVscHMgb3IganVzdCBhZGRzIGV4dHJh IGNsdXR0ZXIuDQoNClJlYWxpc3RpY2FsbHksIEkgdGhpbmsgdGhhdCBldGhlcm5ldENzbWFjZCBp cyBkZWFkLiAgRG8geW91IGhhdmUgb3RoZXIgZXhhbXBsZXMgb2YgaW50ZXJmYWNlIHR5cGVzIHRo YXQgZG8gc3VwcG9ydCBsb29wYmFjaywgYnV0IG5vdCBpbiBib3RoIGRpcmVjdGlvbnM/ICBUaGlz IG1pZ2h0IGJlIHNvbWV0aGluZyBiZXR0ZXIgaGFuZGxlZCB2aWEgYSBkZXZpYXRpb24sIG9yIHRo ZSBkZXZpY2UgZmFpbGluZyB0aGUgY29uZmlndXJhdGlvbiB3aGVuIGl0IGlzIHZlcmlmaWVkLg0K DQpBcyBhIHNpZGUgbm90ZSwgb25lIG9mIHRoZSBsaW1pdGF0aW9ucyBvZiBmZWF0dXJlcyBhbmQg ZGV2aWF0aW9ucyBpcyB0aGF0IHRoZSBhcHBseSB0byBhbGwgaW50ZXJmYWNlcyBvbiB0aGUgZGV2 aWNlLCBidXQgdGhlIGFjdHVhbCBwcm9wZXJ0aWVzIG9mIGFuIGludGVyZmFjZSBtaWdodCB2YXJ5 IGRlcGVuZGluZyBvbiB0aGUgc3BlZWQsIHR5cGUgYW5kIGhhcmR3YXJlIGFzc29jaWF0ZWQgd2l0 aCB0aGUgaW50ZXJmYWNlLg0KDQoNCj4gDQo+IDkuIEFwcHJvcHJpYXRlIGVudHJ5IGluIHRoZSAi MTEuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiBub3RpbmcgdGhlDQo+IHBvc3NpYmlsaXR5IG9m IERvUyBhdHRhY2tzIGFuZCBicm9hZGNhc3QgdHJhZmZpYyBzdG9ybXMgcmVzdWx0aW5nIGZyb20N Cj4gbG9vcGJhY2tzOg0KPiANCj4gT0xEOg0KPiANCj4gIMKgwqAgVGhlIGZvbGxvd2luZyBsZWFm IGNvdWxkIGNhdXNlIHRoZSBpbnRlcmZhY2UgdG8gZ28gZG93biwgYW5kIHN0b3ANCj4gIMKgwqAg cHJvY2Vzc2luZyBhbnkgaW5ncmVzcyBvciBlZ3Jlc3MgdHJhZmZpYyBvbiB0aGUgaW50ZXJmYWNl Og0KPiANCj4gIMKgwqAgb8KgIC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9sb29wYmFjaw0K PiANCj4gTkVXOg0KPiANCj4gIMKgwqAgVGhlIGZvbGxvd2luZyBsZWFmIGNvdWxkIGNhdXNlIHRo ZSBpbnRlcmZhY2UgdG8gZ28gZG93biwgYW5kIHN0b3ANCj4gIMKgwqAgcHJvY2Vzc2luZyBhbnkg aW5ncmVzcyBvciBlZ3Jlc3MgdHJhZmZpYyBvbiB0aGUgaW50ZXJmYWNlLiBJdCBjb3VsZA0KPiAg wqDCoCBjYXVzZSBicm9hZGNhc3QgdHJhZmZpYyBzdG9ybXMuDQo+IA0KPiAgwqDCoCBvwqAgL2lm OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2xvb3BiYWNrDQo+IA0KDQpBY2suDQoNCg0KDQo+IA0K PiAxMC4gSW50cm9kdWNpbmcgY29uZmlnIHRydWUgImZvcndhcmRpbmctbW9kZSIgbGVhZiBicmVh a3MgY2xpZW50cyB0aGF0DQo+IHN1cHBvcnQgZS5nLiByZmM4MzQ0IGlldGYtaXAgKHdoaWNoIGhh cyBpdHMgZGVkaWNhdGVkIGZvcndhcmRpbmcgbGVhZnMNCj4gZS5nLiAvaWV0Zi1pbnRlcmZhY2Vz OmludGVyZmFjZXMvaW50ZXJmYWNlL2lldGYtaXA6aXB2NC9mb3J3YXJkaW5nICkgYnkNCj4gaW50 cm9kdWNpbmcgdGhpcyBuZXcgbW9kdWxlIHdpdGggYSBuZXcgbGVhZiB0aGV5IGtub3cgbm90aGlu ZyBhYm91dC4gSQ0KPiBzdXBwb3J0IHRoaXMgbGVhZiBhcyBjb25maWcgZmFsc2UuIElmIE5FVENP TkYgd2FzIG5vdCB0cmFuc2FjdGlvbmFsIGENCj4gZ2xvYmFsIGxlYWYgZW5hYmxpbmcgdGhlIGZv cndhcmRpbmcgY29uZmlndXJhdGlvbiB3b3VsZCBiZSBhIGZlYXR1cmUuDQo+IEJ1dCBORVRDT05G IGlzIHRyYW5zYWN0aW9uYWwuDQoNCkkgZG9uJ3QgZ2V0IHRoZSByZWxldmFuY2Ugb2YgdHJhbnNh Y3Rpb25zLCBidXQgaXQgaXNuJ3QgaW50ZW5kZWQgdG8gYnJlYWsgZXhpc3RpbmcgY2xpZW50cy9Z QU5HIG1vZHVsZXMuDQoNClRoZSBpZGVhIG9mIHRoaXMgbGVhZiBpcyB0aGF0IGlmIGl0IGlzIGNv bmZpZ3VyZWQgdGhlbiB0aGUgc3lzdGVtIGNhbiB1c2UgaXQgdG8gY2hlY2sgb3RoZXIgY29uc3Ry YWludHMuICBFLmcuIHRvIHZhbGlkYXRlIHRoYXQgYW4gTDIgUW9TIHBvbGljeSBpc27igJl0IGJl aW5nIGNvbmZpZ3VyZWQgb24gYW4gTDMgaW50ZXJmYWNlLiAgSWYgdGhlIGxlYWYgaXNuJ3QgY29u ZmlndXJlZCB0aGVuIHRob3NlIGNvbnN0cmFpbnRzIGFyZSBub3QgY2hlY2tlZC4NCg0KDQo+IA0K PiAxMS4gVGhlICJmb3J3YXJkaW5nLW1vZGUiIGxlYWYgaGFzIHRoZSBmb2xsb3dpbmcgc2V0IG9m IGlkZW50aXRpZXMNCj4ge29wdGljYWwtbGF5ZXIsIGwyLWZvcndhcmRpbmcsIG5ldHdvcmstbGF5 ZXJ9LiBXZSBjb3VsZCBtYWtlIHRoZSBpZGVudGl0eQ0KPiBuYW1lcyBzaG9ydGVyIGFuZCBjb25z aXN0ZW50LiBsMSxsMixsMyBvciBwaHlzaWNhbCxkYXRhLWxpbmssbmV0d29yay4NCg0KSSd2ZSB0 cmllZCB0byB1c2UgbmFtZXMgaGVyZSB0aGF0IG5ldHdvcmsgZW5naW5lZXJzIGFyZSBtb3N0IGxp a2VseSB0byBiZSBmYW1pbGlhciB3aXRoLg0KDQpJIHRoaW5rIHRoYXQgdXNpbmcgdGhlIE9TSSBs YXllciBuYW1lcyAoZS5nLiBsMSwgbDIsIGwzKSB3b3VsZCBiZSB0b28gdGVyc2UuDQoNCldlIGNv dWxkIGNoYW5nZSAibDItZm9yd2FyZGluZyIgdG8gImRhdGEtbGluay1sYXllciIsIGJ1dCBJIHdv dWxkIHRoaW5rIHRoYXQgcGVvcGxlIHdvdWxkIGJlIG1vcmUgZmFtaWxpYXIgd2l0aCAibDItZm9y d2FyZGluZyIgYXMgYSB0ZXJtLiAgRS5nLiByZWxhdGVkIHRvIEwyVlBOLg0KDQoNCj4gDQo+IDEy LiBJIGRvIG5vdCBhZ3JlZSB3ZSBuZWVkIHRoaXMgdGV4dC4gTm9ybWFsbHkgTkVUQ09ORiBkZXZp Y2VzIHNob3VsZA0KPiBhY2NlcHQgdHJhbnNhY3Rpb25zIHRvIGFueSB2YWxpZCBjb25maWd1cmF0 aW9uOg0KPiANCj4gT0xEOg0KPiAgwqDCoCAuLi4NCj4gIMKgwqAgTm9ybWFsbHkgZGV2aWNlcyB3 aWxsIG5vdCBhbGxvdyB0aGUgcGFyZW50LWludGVyZmFjZSBsZWFmIHRvIGJlDQo+ICDCoMKgIGNo YW5nZWQgYWZ0ZXIgdGhlIGludGVyZmNlIGhhcyBiZWVuIGNyZWF0ZWQuwqAgSWYgYW4gaW1wbGVt ZW50YXRpb24NCj4gIMKgwqAgZGlkIGFsbG93IHRoZSBwYXJlbnQtaW50ZXJmYWNlIGxlYWYgdG8g YmUgY2hhbmdlZCB0aGVuIGl0IGNvdWxkIGNhdXNlDQo+ICDCoMKgIGFsbCB0cmFmZmljIG9uIHRo ZSBhZmZlY3RlZCBpbnRlcmZhY2UgdG8gYmUgZHJvcHBlZC7CoCBUaGUgYWZmZWN0ZWQNCj4gIMKg wqAgbGVhZiBpczoNCj4gDQo+ICDCoMKgIG/CoCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2Uv cGFyZW50LWludGVyZmFjZQ0KPiAgwqDCoCAuLi4NCj4gDQo+IE5FVzoNCj4gIMKgwqAgLi4uDQo+ ICDCoMKgIENoYW5naW5nIHRoZSBwYXJlbnQtaW50ZXJmYWNlIGxlYWYgY291bGQgY2F1c2UNCj4g IMKgwqAgYWxsIHRyYWZmaWMgb24gdGhlIGFmZmVjdGVkIGludGVyZmFjZSB0byBiZSBkcm9wcGVk Lg0KPiAgwqDCoCBUaGUgYWZmZWN0ZWQgbGVhZiBpczoNCj4gDQo+ICDCoMKgIG/CoCAvaWY6aW50 ZXJmYWNlcy9pZjppbnRlcmZhY2UvcGFyZW50LWludGVyZmFjZQ0KPiAgwqDCoCAuLi4NCg0KVGhp cyBpc24ndCBhYm91dCB0cmFuc2FjdGlvbnMgc28gbXVjaCBhcyB2YWxpZCBjb25maWd1cmF0aW9u Lg0KDQpOb3JtYWxseSwgdGhlIG5hbWUgb2YgdGhlIHN1Yi1pbnRlcmZhY2UgaXMgdGlnaHRseSBi b3VuZCB0byB0aGUgcGFyZW50IGludGVyZmFjZS4gIEUuZy4gaWYgdGhlIHBhcmVudCBpbiAiRXRo ZXJuZXQwLzEiIHRoZW4gdGhlIHN1Yi1pbnRlcmZhY2Ugd291bGQgYmUgIkV0aGVybmV0MC8xLjEi LiAgSWYgeW91IHRyaWVkIHRvIGNoYW5nZSB0aGUgcGFyZW50LWludGVyZmFjZSBsZWFmIG9mICJF dGhlcm5ldDAvMS4xIiB0byAiRXRoZXJuZXQyLzIiIHRoZW4gSSB3b3VsZCBleHBlY3QgdGhlIHN5 c3RlbSB0byByZWplY3QgdGhhdCBjaGFuZ2UgKGJlY2F1c2UgdGhlIGNvbmZpZ3VyYXRpb24gaXMg aW52YWxpZCBub3QgYmVjYXVzZSBvZiB0cmFuc2FjdGlvbnMpLg0KDQoNCj4gDQo+IDEzLiBUaGUg aW4tZHJvcC11bmtub3duLWRlc3QtbWFjLXBrdHMgY2hhbmdlcyB0aGUgYmVoYXZpb3Igb2YgdGhl IGluLQ0KPiB1bmljYXN0LXBrdHMsaW4tbXVsdGljYXN0LXBrdHMgYW5kIGluLWJyb2FkY2FzdC1w a3RzLiBJIGRvIG5vdCBhZ3JlZSBhbnkNCj4gZGlzY2FyZGVkIHBhY2tldHMgaW4gdGhlIGZvcndh cmRpbmcgcHJvY2VzcyBzaG91bGQgYmUgc3VidHJhY3RlZCBmcm9tIHRoZQ0KPiBpbnRlcmZhY2Ug Y291bnRlcnMuDQo+IA0KPiBIZXJlIGlzIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uOg0KPiANCj4g T0xEOg0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEZvciBjb25zaXN0ZW5jeSwg ZnJhbWVzIGNvdW50ZWQgYWdhaW5zdCB0aGlzIGRyb3ANCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBjb3VudGVycyBhcmUgYWxzbyBjb3VudGVkIGFnYWluc3QgdGhlIElFVEYgaW50 ZXJmYWNlcw0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHN0YXRpc3RpY3MuwqAg SW4gcGFydGljdWxhciwgdGhleSBhcmUgaW5jbHVkZWQgaW4NCj4gIMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBpbi1vY3RldHMgYW5kIGluLWRpc2NhcmRzLCBidXQgYXJlIG5vdCBpbmNs dWRlZCBpbg0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGluLXVuaWNhc3QtcGt0 cywgaW4tbXVsdGljYXN0LXBrdHMgb3IgaW4tYnJvYWRjYXN0LXBrdHMsDQo+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgYmVjYXVzZSB0aGV5IGFyZSBub3QgZGVsaXZlcmVkIHRvIGEg aGlnaGVyIGxheWVyLg0KPiBORVc6DQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg VGhlIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgY291bnRlciBkb2VzIG5vdA0KPiAgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNoYW5nZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGNvdW50ZXJz IGRlZmluZWQgaW4NCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBJRVRGIGludGVy ZmFjZXMgc3RhdGlzdGljcy4NCj4gDQoNCkl0IGlzIG5vdCBjaGFuZ2luZyB0aGUgZGVmaW5pdGlv bnMgb2YgdGhvc2UgY291bnRlcnMgYXQgYWxsLiAgSXQgaXMganVzdCBleHBsYWluaW5nIHRoZSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVtLg0KDQoNCg0KPiANCj4gDQo+IDE0LiBJIHByb3Bvc2Ug dGhlIGluLXBrdHMgYW5kIG91dC1wa3RzIGNvdW50ZXJzIHN0YW5kYXJkaXplZCB0b28uDQo+IGh0 dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIvdmVuZG9yL2Npc2Nv L3hlLzE2NDEvaWV0Zi0NCj4gaW50ZXJmYWNlcy1leHQueWFuZy4NCj4gQW5kIHllcyBzb21lb25l IGZvcmdvdCB0byB1cGRhdGUgdGhlIGJvaWxlcnBsYXRlIHRleHQuDQoNClRoaXMgb25lIEkgdGhp bmsgdGhhdCB3ZSBuZWVkIHRvIGdldCBmdXJ0aGVyIGlucHV0IG9uLg0KDQpodHRwczovL2dpdGh1 Yi5jb20vWWFuZ01vZGVscy95YW5nL2Jsb2IvbWFzdGVyL3N0YW5kYXJkL2llZWUvcHVibGlzaGVk LzgwMi4zL2llZWU4MDItZXRoZXJuZXQtaW50ZXJmYWNlLnlhbmcNCg0KZGVmaW5lcyBpbi1mcmFt ZXMgYW5kIG91dC1mcmFtZXMsIGJ1dCB0aGVzZSBhcmUgb25seSBmb3IgRXRoZXJuZXQsIGJ1dCB5 b3UgYXJlIHByb2JhYmx5IGxvb2tpbmcgZm9yIGEgY291bnRlciBhY3Jvc3MgYWxsIGludGVyZmFj ZSB0eXBlcy4NCg0KDQo+IA0KPiAxNS4gSSBwcm9wb3NlIHRoYXQgbmV3ICJpZXRmLWludGVyZmFj ZXMtY29tbW9uOmluLWRpc2NhcmRzLW92ZXJmbG93Ig0KPiBjb3VudGVyIGlzIGFkZGVkLiBDdXJy ZW50bHkgdGhlICJpZXRmLWludGVyZmFjZXM6aW4tZGlzY2FyZHMiIGNhbiBjb250YWluDQo+IGJv dGggZGlzY2FyZHMgbGlrZSB0aGUgb25lcyBhY2N1bXVsYXRlZCBpbiBpbi1kcm9wLXVua25vd24t ZGVzdC1tYWMtcGt0cw0KPiBhbmQgZGlzY2FyZHMgY2F1c2VkIGJ5IG92ZXJmbG93cyAocGVyZm9y bWFuY2UgcmVsYXRlZCBsb3NzIG9mIHBhY2tldHMgbGlrZQ0KPiBmcmVlaW5nIGJ1ZmZlciBzcGFj ZSBpbiBkZXZpY2VzIHRoYXQgaW4gY2VydGFpbiBjYXNlcyBhcmUgZm9yd2FyZGluZw0KPiBzbG93 ZXIgdGhlbiB0aGUgbGluZSBzcGVlZCkuIFR1cm5zIG91dCBrbm93aW5nIGlmIGRldmljZSBpcyBk aXNjYXJkaW5nDQo+IChsb29zaW5nKSBwYWNrZXRzIGR1ZSB0byBwZXJmb3JtYW5jZSBzaG9ydGFn ZSBhbmQgZGlzY2FyZGluZyAoZmlsdGVyaW5nKQ0KPiB1bndhbnRlZCBwYWNrZXRzIGFyZSB0d28g ZGlmZmVyZW50IGV2ZW50cyB0aGF0IG9uZSBuZWVkcyB0byBkaWZmZXJlbnRpYXRlDQo+IGJldHdl ZW4gYXJlIGN1cnJlbnRseSBpbiB0aGUgc2FtZSBpbi1kaXNjYXJkcyBjb3VudGVyLiBXZSBjYW4g Zml4IHRoYXQNCj4gd2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIGluLWRpc2NhcmRzLW92ZXJmbG93 IGNvdW50ZXIuDQoNClRoaXMgb25lIEkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGdldCBmdXJ0aGVy IGlucHV0IG9uLiAgSSB0aGluayB0aGF0IHRoaXMgbWlnaHQgYmUgdXNlZnVsLiAgQnV0IHdlIG1p Z2h0IG5lZWQgc29tZSBjYXJlIHRvIGVuc3VyZSB0aGF0IGl0IGZpdHMgY2xlYW5seSB3aXRoIFFv UyBkcm9wcy4NCg0KSWYgd2Ugd2VyZSB0byBhZGQgdGhpcyB0aGVuIHRoZSBkZWZpbml0aW9uIG9m ICJpZXRmLWludGVyZmFjZXM6aW4tZGlzY2FyZHMiIGNhbm5vdCBjaGFuZ2UuICBpLmUuIEluLWRp c2NhcmRzLW92ZXJmbG93IHdvdWxkIGJlIGEgc3Vic2V0IG9mICJpbi1kaXNjYXJkcyIuDQoNCg0K PiANCj4gMTYuIFdlIGNhbiByZXBsYWNlDQo+ICJpZXRmLWludGVyZmFjZXMtZXRoZXJuZXQtbGlr ZTppbi1kcm9wLXVua25vd24tZGVzdC1tYWMtcGt0cyIgd2l0aCAoaW4tDQo+IGRpc2NhcmRzIC0g aW4tZGlzY2FyZHMtb3ZlcmZsb3cpIGZvciBNQUMgQnJpZGdlcyBvciBhbnkgb3RoZXIgRXRoZXJu ZXQNCj4gaW50ZXJmYWNlIHBsdXMgc2F2ZSB1cyB0aGUgaW50cm9kdWN0aW9uIG9mIHRlY2hub2xv Z3kgc3BlY2lmaWMgc2ltaWxhcg0KPiBjb3VudGVycyBmb3IgdGhlIHJlc3Qgb2YgdGhlIEJyaWRn ZXMgYW5kIG5vbi1FdGhlcm5ldCBpbnRlcmZhY2VzLg0KDQpGb3IgRXRoZXJuZXQsIGhhdmluZyBh IHRlY2hub2xvZ3kgc3BlY2lmaWMgaW4tZHJvcC11bmtub3duLWRlc3QtbWFjLXBrdHMgaXMgdXNl ZnVsLg0KDQpJbiB0aGUgV0cgZGlzY3Vzc2lvbiwgdGhlcmUgd2FzIGFncmVlbWVudCB0byBhbHNv IGFkZCBhIGRyb3AgY291bnRlciBmb3IgcGFja2V0cyB0aGF0IGFyZSBkcm9wcGVkIGJlY2F1c2Ug dGhleSBjYW5ub3QgYmUgZGVtdXhlZCB0byBhbnkgc3ViLWludGVyZmFjZS4NCg0KUGVyc29uYWxs eSwgSSB0aGluayB0aGF0IGl0IGlzIHVzZWZ1bCB0byBoYXZlIGFuIG92ZXJhbGwgZHJvcCBjb3Vu dGVyIHRoYXQgY2FwdHVyZXMgZXZlcnl0aGluZywgYWxvbmcgd2l0aCBtb3JlIHNwZWNpZmljIGRy b3AgY291bnRlcnMgdGhhdCBzb21ldGltZXMgZ2l2ZSBtb3JlIGluZm9ybWF0aW9uIGFzIHRvIHdo YXQgaGFzIGNhdXNlcyBzcGVjaWZpYyBkcm9wcy4gIFNwZWNpZmljYWxseSwganVzdCBiZWNhdXNl IGEgbW9yZSBzcGVjaWZpYyBkcm9wIGNvdW50ZXIgaGFzIGJlZW4gZGVmaW5lZCwgdGhhdCBkb2Vz bid0IG1lYW4gdGhhdCBpdCBzaG91bGRuJ3QgYWxzbyBiZSBpbmNsdWRlZCBpbiB0aGUgZ2VuZXJh bCBkcm9wIGNvdW50ZXIuDQoNCg0KPiANCj4gMTcuIEkgaGF2ZSBzZXBhcmF0ZWx5IHBvc3RlZCBt eSBhcmd1bWVudHMgYWdhaW5zdCBpbnRyb2R1Y3Rpb24gb2YgbGVhZg0KPiBuYW1lZCBsMi1tdHUg YW5kIHRoZSBuZWVkIG9mIGEgY29uZmlnIGZhbHNlIGxlYWYgdGhhdCBoYXMgc2ltaWxhcg0KPiBz ZW1hbnRpY3MgYXMgdGhlIGlmTXR1IG9iamVjdCBmcm9tIElGLU1JQi4NCg0KT0ssIGxldHMga2Vl cCB0aGlzIGlzc3VlIG9uIHRoYXQgb3RoZXIgdGhyZWFkLg0KDQoNCj4gDQo+IDE4LiBTb21lIHJl ZmVyZW5jZXMgdG8gcmVsZXZhbnQgSUVFRSBzdGFuZGFyZHMgYW5kIElFRUUgbWFpbnRhaW5lZCBZ QU5HDQo+IG1vZHVsZXMgc2hvdWxkIGJlIGFkZGVkIChpbiB0aGUgc2NvcGUgb2YgaWV0Zi1pbnRl cmZhY2VzLWV0aGVybmV0LWxpa2UpLg0KPiBBbHNvIGEgZmV3IGxpbmVzIGV4cGxhaW5pbmcgdGhl IHBvbGljeSBjaGFuZ2UgYW5kIHdoeSBub25lIG9mIHRoZQ0KPiBSRkMzNjM1IG1hbmFnZWQgb2Jq ZWN0cyBhcmUgcGFydCBvZiB0aGUgbmV3IGlldGYtaW50ZXJmYWNlcy1ldGhlcm5ldC1saWtlDQo+ IFlBTkcgbW9kdWxlLg0KDQpZZXMsIE9LLg0KDQoNCj4gDQo+IDE5LiBpZXRmLWlmLWNvbW1vbi55 YW5nIGFuZCBpZXRmLWlmLWV0aGVybmV0LWxpa2UueWFuZyBpbnN0ZWFkIG9mIGlldGYtDQo+IGlu dGVyZmFjZXMtY29tbW9uLnlhbmcgYW5kIGlldGYtaW50ZXJmYWNlcy1ldGhlcm5ldC1saWtlLnlh bmcuDQo+IFNldHRpbmcgYSBzaG9ydGVyIG5hbWluZyBwcmVjZWRlbnQgZm9yIGZ1dHVyZSBtb2R1 bGVzIGF1Z21lbnRpbmcgaWV0Zi0NCj4gaW50ZXJmYWNlcy4NCg0KSSdtIG5vdCBvcHBvc2VkIHRv IHNob3J0ZXIgbmFtZXMsIGJ1dCB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHRoZSB2aWV3cyBvZiBv dGhlcnMgaW4gdGhlIFdHLg0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSByZXZpZXcuICBJdCBpcyBh cHByZWNpYXRlZC4NCg0KUm9iDQoNCg0KPiANCj4gL1ZsYWRpbWlyDQo+IA0KPiBPbiAxMC8wNy8y MDE5IDAyLjE1LCBLZW50IFdhdHNlbiB3cm90ZToNCj4gPiBBbGwsDQo+ID4NCj4gPiBUaGlzIHN0 YXJ0cyBhIHR3ZWx2ZS1kYXkgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yDQo+ID4gZHJhZnQt aWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KPiA+DQo+ID4gVGhlIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGVuZHMgb24gSnVseSAyMSAodGhlIGRheSBiZWZvcmUgdGhlIE5FVE1PRA0KPiAx MDUgc2Vzc2lvbnMpLiAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgd29ya2luZyBn cm91cCBtYWlsaW5nDQo+IGxpc3QuDQo+ID4NCj4gPiBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwg IkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcw0KPiByZWFkeSBm b3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSEgIFRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRh bnQsIGV2ZW4NCj4gZnJvbSBhdXRob3JzLg0KPiA+DQo+ID4gVGhhbmsgeW91LA0KPiA+IE5FVE1P RCBDaGFpcnMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== From nobody Thu Aug 22 04:35:18 2019 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8B12081E for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 04:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UU-IIuXL0ao for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 04:35:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0E120026 for <netmod@ietf.org>; Thu, 22 Aug 2019 04:35:14 -0700 (PDT) Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id 039261AE0981; Thu, 22 Aug 2019 13:35:11 +0200 (CEST) Date: Thu, 22 Aug 2019 13:34:49 +0200 (CEST) Message-Id: <20190822.133449.502914144686905879.mbj@tail-f.com> To: rwilton@cisco.com Cc: vladimir@transpacket.com, netmod@ietf.org From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VfPJleTAMqbRbThxVoMTrRGWBa4> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 11:35:17 -0000 SGksDQoNClNvbWUgY29tbWVudHMgaW5saW5lLg0KDQoNCiJSb2IgV2lsdG9uIChyd2lsdG9uKSIg PHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gSGkgVmxhZGltaXIsDQo+IA0KPiBUaGFua3Mg Zm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3LiAgU29ycnkgZm9yIHRoZSBzbG93IHJlcGx5LCBJJ3Zl IGJlZW4NCj4gYXdheS4gIEknbSBhbHNvIGFib3V0IHRvIGJlIGF3YXkgYWdhaW4gZm9yIGEgY291 cGxlIG9mIGRheXMuDQo+IA0KPiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSAuLi4NCj4g DQo+IEknbGwgYWxzbyB0cmFjayB0aGVzZSBpc3N1ZXMgdG8gY2xvc3VyZSBvbg0KPiBodHRwczov L2dpdGh1Yi5jb20vbmV0bW9kLXdnL2ludGVyZmFjZS1leHRlbnNpb25zLXlhbmcvaXNzdWVzDQo+ IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmV0bW9kIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFZsYWRpbWlyIFZhc3NpbGV2DQo+ID4g U2VudDogMTMgQXVndXN0IDIwMTkgMTc6MDUNCj4gPiBUbzogS2VudCBXYXRzZW4gPGtlbnQraWV0 ZkB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KPiA+IA0K PiA+IEkgaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQuIEkgaGF2ZSB0aGUgZm9sbG93aW5nICgxOSkg SU1PIHVzZWZ1bA0KPiA+IHByb3Bvc2FsczoNCj4gPiANCj4gPiAxLiBEZWRpY2F0ZWQgbW9kdWxl IChpZXRmLWlmLW9wZXItc3RhdHVzLWRlYm91bmNlLnlhbmcpIGZvciB0aGUgb3Blci0NCj4gPiBz dGF0dXMgZGVib3VuY2luZy9kYW1wZW5pbmcgZnVuY3Rpb25hbGl0eSBjdXJyZW50bHkgaW4NCj4g PiBpZXRmLWludGVyZmFjZXMtDQo+ID4gY29tbW9uLnlhbmcuDQo+IA0KPiBJIGRvbid0IHRoaW5r IHRoYXQgd2Ugd2FudCBhIHByb2xpZmVyYXRpb24gb2YgdG9vIG1hbnkgc2VwYXJhdGUgWUFORw0K PiBtb2R1bGVzIGZvciBzbWFsbCBmZWF0dXJlcy4gIEVhY2ggb2YgdGhlIGFyZWFzIG9mIGRpZmZl cmVudA0KPiBmdW5jdGlvbmFsaXR5IHdpdGhpbiB0aGlzIG1vZHVsZSBhcmUgYWxyZWFkeSBjb25k aXRpb25hbCBvbg0KPiBpZi1mZWF0dXJlLCBzbyBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMg YSBzdHJvbmcganVzdGlmaWNhdGlvbiB0bw0KPiBzZXBhcmF0aW5nIHRoaXMgb3V0IGFzIGEgc2Vw YXJhdGUgbW9kdWxlLg0KDQpJIGFncmVlLg0KDQo+ID4gNC4gRGVkaWNhdGVkIG1vZHVsZSAoaWV0 Zi1pZi1sb29wYmFjay55YW5nKSBmb3IgdGhlIGxvb3BiYWNrDQo+ID4gZnVuY3Rpb25hbGl0eQ0K PiA+IGN1cnJlbnRseSBpbiBpZXRmLWludGVyZmFjZXMtY29tbW9uLnlhbmcuDQo+IA0KPiBTYW1l IGFuc3dlciBhcyBmb3IgMS4gSSBkb24ndCB0aGluayB0aGF0IHdlIHNob3VsZCBoYXZlIHRvbyBt YW55DQo+IHJlYWxseSBzbWFsbCBtb2R1bGVzLg0KDQpJIGFncmVlLg0KDQoNCj4gPiAxMC4gSW50 cm9kdWNpbmcgY29uZmlnIHRydWUgImZvcndhcmRpbmctbW9kZSIgbGVhZiBicmVha3MgY2xpZW50 cyB0aGF0DQo+ID4gc3VwcG9ydCBlLmcuIHJmYzgzNDQgaWV0Zi1pcCAod2hpY2ggaGFzIGl0cyBk ZWRpY2F0ZWQgZm9yd2FyZGluZyBsZWFmcw0KPiA+IGUuZy4gL2lldGYtaW50ZXJmYWNlczppbnRl cmZhY2VzL2ludGVyZmFjZS9pZXRmLWlwOmlwdjQvZm9yd2FyZGluZyApDQo+ID4gYnkNCj4gPiBp bnRyb2R1Y2luZyB0aGlzIG5ldyBtb2R1bGUgd2l0aCBhIG5ldyBsZWFmIHRoZXkga25vdyBub3Ro aW5nIGFib3V0LiBJDQo+ID4gc3VwcG9ydCB0aGlzIGxlYWYgYXMgY29uZmlnIGZhbHNlLiBJZiBO RVRDT05GIHdhcyBub3QgdHJhbnNhY3Rpb25hbCBhDQo+ID4gZ2xvYmFsIGxlYWYgZW5hYmxpbmcg dGhlIGZvcndhcmRpbmcgY29uZmlndXJhdGlvbiB3b3VsZCBiZSBhIGZlYXR1cmUuDQo+ID4gQnV0 IE5FVENPTkYgaXMgdHJhbnNhY3Rpb25hbC4NCj4gDQo+IEkgZG9uJ3QgZ2V0IHRoZSByZWxldmFu Y2Ugb2YgdHJhbnNhY3Rpb25zLCBidXQgaXQgaXNuJ3QgaW50ZW5kZWQgdG8NCj4gYnJlYWsgZXhp c3RpbmcgY2xpZW50cy9ZQU5HIG1vZHVsZXMuDQo+IA0KPiBUaGUgaWRlYSBvZiB0aGlzIGxlYWYg aXMgdGhhdCBpZiBpdCBpcyBjb25maWd1cmVkIHRoZW4gdGhlIHN5c3RlbSBjYW4NCj4gdXNlIGl0 IHRvIGNoZWNrIG90aGVyIGNvbnN0cmFpbnRzLiAgRS5nLiB0byB2YWxpZGF0ZSB0aGF0IGFuIEwy IFFvUw0KPiBwb2xpY3kgaXNu4oCZdCBiZWluZyBjb25maWd1cmVkIG9uIGFuIEwzIGludGVyZmFj ZS4gIElmIHRoZSBsZWFmIGlzbid0DQo+IGNvbmZpZ3VyZWQgdGhlbiB0aG9zZSBjb25zdHJhaW50 cyBhcmUgbm90IGNoZWNrZWQuDQoNCkhtbS4gIEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhpcyBsZWFm IGRvZXNuJ3QgaGF2ZSBhbnkgZGlyZWN0IGVmZmVjdCBpbg0KdGhlIHNlcnZlcj8NCg0KPiA+IDEy LiBJIGRvIG5vdCBhZ3JlZSB3ZSBuZWVkIHRoaXMgdGV4dC4gTm9ybWFsbHkgTkVUQ09ORiBkZXZp Y2VzIHNob3VsZA0KPiA+IGFjY2VwdCB0cmFuc2FjdGlvbnMgdG8gYW55IHZhbGlkIGNvbmZpZ3Vy YXRpb246DQo+ID4gDQo+ID4gT0xEOg0KPiA+ICDCoMKgIC4uLg0KPiA+ICDCoMKgIE5vcm1hbGx5 IGRldmljZXMgd2lsbCBub3QgYWxsb3cgdGhlIHBhcmVudC1pbnRlcmZhY2UgbGVhZiB0byBiZQ0K PiA+ICDCoMKgIGNoYW5nZWQgYWZ0ZXIgdGhlIGludGVyZmNlIGhhcyBiZWVuIGNyZWF0ZWQuwqAg SWYgYW4gaW1wbGVtZW50YXRpb24NCj4gPiAgwqDCoCBkaWQgYWxsb3cgdGhlIHBhcmVudC1pbnRl cmZhY2UgbGVhZiB0byBiZSBjaGFuZ2VkIHRoZW4gaXQgY291bGQNCj4gPiAgY2F1c2UNCj4gPiAg wqDCoCBhbGwgdHJhZmZpYyBvbiB0aGUgYWZmZWN0ZWQgaW50ZXJmYWNlIHRvIGJlIGRyb3BwZWQu wqAgVGhlIGFmZmVjdGVkDQo+ID4gIMKgwqAgbGVhZiBpczoNCj4gPiANCj4gPiAgwqDCoCBvwqAg L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL3BhcmVudC1pbnRlcmZhY2UNCj4gPiAgwqDCoCAu Li4NCj4gPiANCj4gPiBORVc6DQo+ID4gIMKgwqAgLi4uDQo+ID4gIMKgwqAgQ2hhbmdpbmcgdGhl IHBhcmVudC1pbnRlcmZhY2UgbGVhZiBjb3VsZCBjYXVzZQ0KPiA+ICDCoMKgIGFsbCB0cmFmZmlj IG9uIHRoZSBhZmZlY3RlZCBpbnRlcmZhY2UgdG8gYmUgZHJvcHBlZC4NCj4gPiAgwqDCoCBUaGUg YWZmZWN0ZWQgbGVhZiBpczoNCj4gPiANCj4gPiAgwqDCoCBvwqAgL2lmOmludGVyZmFjZXMvaWY6 aW50ZXJmYWNlL3BhcmVudC1pbnRlcmZhY2UNCj4gPiAgwqDCoCAuLi4NCj4gDQo+IFRoaXMgaXNu J3QgYWJvdXQgdHJhbnNhY3Rpb25zIHNvIG11Y2ggYXMgdmFsaWQgY29uZmlndXJhdGlvbi4NCj4g DQo+IE5vcm1hbGx5LCB0aGUgbmFtZSBvZiB0aGUgc3ViLWludGVyZmFjZSBpcyB0aWdodGx5IGJv dW5kIHRvIHRoZSBwYXJlbnQNCj4gaW50ZXJmYWNlLiAgRS5nLiBpZiB0aGUgcGFyZW50IGluICJF dGhlcm5ldDAvMSIgdGhlbiB0aGUgc3ViLWludGVyZmFjZQ0KPiB3b3VsZCBiZSAiRXRoZXJuZXQw LzEuMSIuICBJZiB5b3UgdHJpZWQgdG8gY2hhbmdlIHRoZSBwYXJlbnQtaW50ZXJmYWNlDQo+IGxl YWYgb2YgIkV0aGVybmV0MC8xLjEiIHRvICJFdGhlcm5ldDIvMiIgdGhlbiBJIHdvdWxkIGV4cGVj dCB0aGUNCj4gc3lzdGVtIHRvIHJlamVjdCB0aGF0IGNoYW5nZSAoYmVjYXVzZSB0aGUgY29uZmln dXJhdGlvbiBpcyBpbnZhbGlkIG5vdA0KPiBiZWNhdXNlIG9mIHRyYW5zYWN0aW9ucykuDQoNCldl bGwsIHRoaXMgaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjYuICBUaGUgcXVvdGVk IHRleHQgaXMNCmZyb20gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuICBJIGFncmVlIHdpdGggVmxh ZGltaXI7IEkgdGhpbmsgaGlzDQpzdWdnZXN0ZWQgdGV4dCBpcyBiZXR0ZXIuDQoNCj4gPiAxNC4g SSBwcm9wb3NlIHRoZSBpbi1wa3RzIGFuZCBvdXQtcGt0cyBjb3VudGVycyBzdGFuZGFyZGl6ZWQg dG9vLg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIv dmVuZG9yL2Npc2NvL3hlLzE2NDEvaWV0Zi0NCj4gPiBpbnRlcmZhY2VzLWV4dC55YW5nLg0KPiA+ IEFuZCB5ZXMgc29tZW9uZSBmb3Jnb3QgdG8gdXBkYXRlIHRoZSBib2lsZXJwbGF0ZSB0ZXh0Lg0K PiANCj4gVGhpcyBvbmUgSSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZ2V0IGZ1cnRoZXIgaW5wdXQg b24uDQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL2Jsb2IvbWFzdGVy L3N0YW5kYXJkL2llZWUvcHVibGlzaGVkLzgwMi4zL2llZWU4MDItZXRoZXJuZXQtaW50ZXJmYWNl LnlhbmcNCj4gDQo+IGRlZmluZXMgaW4tZnJhbWVzIGFuZCBvdXQtZnJhbWVzLCBidXQgdGhlc2Ug YXJlIG9ubHkgZm9yIEV0aGVybmV0LCBidXQNCj4geW91IGFyZSBwcm9iYWJseSBsb29raW5nIGZv ciBhIGNvdW50ZXIgYWNyb3NzIGFsbCBpbnRlcmZhY2UgdHlwZXMuDQoNCmluLXBrdHMgaXMgcHJl c3VtYWJseSBpbi11bmljYXN0LXBrdHMgKyBpbi1icm9hZGNhc3QtcGt0cyArDQppbi1tdWx0aWNh c3QtcGt0cy4gIFNvIGlzIHRoaXMgcmVhbGx5IG5lZWRlZD8NCg0KPiA+IDE5LiBpZXRmLWlmLWNv bW1vbi55YW5nIGFuZCBpZXRmLWlmLWV0aGVybmV0LWxpa2UueWFuZyBpbnN0ZWFkIG9mDQo+ID4g aWV0Zi0NCj4gPiBpbnRlcmZhY2VzLWNvbW1vbi55YW5nIGFuZCBpZXRmLWludGVyZmFjZXMtZXRo ZXJuZXQtbGlrZS55YW5nLg0KPiA+IFNldHRpbmcgYSBzaG9ydGVyIG5hbWluZyBwcmVjZWRlbnQg Zm9yIGZ1dHVyZSBtb2R1bGVzIGF1Z21lbnRpbmcgaWV0Zi0NCj4gPiBpbnRlcmZhY2VzLg0KPiAN Cj4gSSdtIG5vdCBvcHBvc2VkIHRvIHNob3J0ZXIgbmFtZXMsIGJ1dCB3b3VsZCBiZSBpbnRlcmVz dGVkIGluIHRoZSB2aWV3cw0KPiBvZiBvdGhlcnMgaW4gdGhlIFdHLg0KDQpJIGhhZCBhIHNpbWls YXIgY29uY2VybiBmb3IgdGhlIG1vZHVsZXMgaW4gdGhlIHN1Yi1pbnRmLXZsYW4gZHJhZnQgKEkN CndpbGwgcG9zdCBteSByZXZpZXcgb2YgdGhhdCBkb2MgbGF0ZXIpLg0KDQpDdXJyZW50bHkgd2Ug aGF2ZToNCg0KICBpZXRmLWludGVyZmFjZXMtY29tbW9uDQogIGlldGYtaW50ZXJmYWNlcy1ldGhl cm5ldC1saWtlDQogIGlldGYtaWYtbDMtdmxhbg0KICBpZXRmLWZsZXhpYmxlLWVuY2Fwc3VsYXRp b24NCg0KSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBjb25zaXN0ZW5jeSwgZWl0aGVyOg0KDQogIGll dGYtaW50ZXJmYWNlcy1jb21tb24NCiAgaWV0Zi1pbnRlcmZhY2VzLWV0aGVybmV0LWxpa2UNCiAg aWV0Zi1pbnRlcmZhY2VzLWwzLXZsYW4NCiAgaWV0Zi1pbnRlcmZhY2VzLWZsZXhpYmxlLWVuY2Fw c3VsYXRpb24NCg0Kb3INCg0KICBpZXRmLWlmLWNvbW1vbg0KICBpZXRmLWlmLWV0aGVybmV0LWxp a2UNCiAgaWV0Zi1pZi1sMy12bGFuDQogIGlldGYtaWYtZmxleGlibGUtZW5jYXBzdWxhdGlvbg0K DQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiBUaGFua3MgYWdhaW4gZm9yIHRoZSByZXZpZXcuICBJdCBp cyBhcHByZWNpYXRlZC4NCj4gDQo+IFJvYg0KPiANCj4gDQo+ID4gDQo+ID4gL1ZsYWRpbWlyDQo+ ID4gDQo+ID4gT24gMTAvMDcvMjAxOSAwMi4xNSwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4gPiBB bGwsDQo+ID4gPg0KPiA+ID4gVGhpcyBzdGFydHMgYSB0d2VsdmUtZGF5IHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0K PiA+ID4NCj4gPiA+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEp1bHkgMjEg KHRoZSBkYXkgYmVmb3JlIHRoZSBORVRNT0QNCj4gPiAxMDUgc2Vzc2lvbnMpLiAgUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyB0byB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nDQo+ID4gbGlzdC4N Cj4gPiA+DQo+ID4gPiBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdA0KPiA+ID4gaXMNCj4gPiByZWFkeSBmb3IgcHVibGlj YXRpb24iLCBhcmUgd2VsY29tZSEgIFRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsDQo+ID4g ZXZlbg0KPiA+IGZyb20gYXV0aG9ycy4NCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UsDQo+ID4gPiBO RVRNT0QgQ2hhaXJzDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYu b3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K PiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo= From nobody Thu Aug 22 05:00:26 2019 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0957A12083A for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 05:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT3u6JtTUyms for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 05:00:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 252F8120820 for <netmod@ietf.org>; Thu, 22 Aug 2019 05:00:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id 944E21AE0981; Thu, 22 Aug 2019 14:00:20 +0200 (CEST) Date: Thu, 22 Aug 2019 13:59:58 +0200 (CEST) Message-Id: <20190822.135958.1009278756627043139.mbj@tail-f.com> To: rwilton@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20190822.133449.502914144686905879.mbj@tail-f.com> References: <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> <20190822.133449.502914144686905879.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hHJU2jOq5lBXuk9SOBQABOQ4lRA> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 12:00:25 -0000 Martin Bjorklund <mbj@tail-f.com> wrote: > Hi, > > Some comments inline. > > > "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote: > > Hi Vladimir, > > > > Thanks for your detailed review. Sorry for the slow reply, I've been > > away. I'm also about to be away again for a couple of days. > > > > Please see my comments inline ... > > > > I'll also track these issues to closure on > > https://github.com/netmod-wg/interface-extensions-yang/issues > > > > > -----Original Message----- > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Vladimir Vassilev [...] > > > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of > > > ietf- > > > interfaces-common.yang and ietf-interfaces-ethernet-like.yang. > > > Setting a shorter naming precedent for future modules augmenting ietf- > > > interfaces. > > > > I'm not opposed to shorter names, but would be interested in the views > > of others in the WG. > > I had a similar concern for the modules in the sub-intf-vlan draft (I > will post my review of that doc later). > > Currently we have: > > ietf-interfaces-common > ietf-interfaces-ethernet-like > ietf-if-l3-vlan > ietf-flexible-encapsulation > > I think we should have consistency, either: > > ietf-interfaces-common > ietf-interfaces-ethernet-like > ietf-interfaces-l3-vlan > ietf-interfaces-flexible-encapsulation > > or > > ietf-if-common > ietf-if-ethernet-like > ietf-if-l3-vlan > ietf-if-flexible-encapsulation One comment re naming here. The name "ietf-interfaces-common" seems a bit odd; isn't "ietf-interfaces" for "common" definitions? I was going to suggest "ietf-interfaces-extensions", but then I re-read the description in the module: This module contains common definitions for extending the IETF interface YANG model (RFC 8343) with common configurable layer 2 properties. So perhaps "ietf-interfaces-l2-extensions" would be better? ... but then "forwarding-mode" isn't a l2 property. /martin From nobody Thu Aug 22 06:15:09 2019 Return-Path: <barryleiba@gmail.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1FF1200FA; Thu, 22 Aug 2019 06:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4QPy6iGKiC8; Thu, 22 Aug 2019 06:15:07 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 AD3021200F8; Thu, 22 Aug 2019 06:15:07 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id l7so11722712ioj.6; Thu, 22 Aug 2019 06:15:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZYvELJG2d0IKBrRebORcqJ9VRg1RikFN4xSxLae9BHI=; b=MgxifbYPgD3wjAZtNnrNscRCX8A5xC2z9kly60fyH43eqO1+Ed/r/eAOS5MgD8w6ez hR0FeKe56vk18qxZbeXqOKDka9BOwlC0smqovGjAJjrNAkX6CDGVzAOqVkd3x/kn6n/f loVnIl7rdcbt/SSc1DzAiwPUaUTjocJrL/fVnaK9h6dEzAO+YCT2IN2G/fbPPghsNPOw +XOCc1lP6aVUPhHIAZqWz3GP9Y+GBI083dsY+WWzrZ9vnjqbtovYkZ8lKcYyo9gt1aZP +lareGOAkZXMupl2NSLGeKP8d8P+2DnVOo8q9v1SNKAoOgBvD2kpE9/dX7sbsjPhM4Ni 9ZUA== X-Gm-Message-State: APjAAAXw7pTRFiRJjfCCq0l1FkETlmDJDlBvqxhWAjepc45yInKZXCnl Y88x7IcXWANX7HG2eOCariL/E1/MNPaEhWraWms= X-Google-Smtp-Source: APXvYqxPTNeqpF0x+0Zgg1zk8izYgRSGyLcwSs/vCQjItnpM4z97T0KS7cUjCnPxswJfU9Id9kZsOnJ/b2trI1+fS64= X-Received: by 2002:a02:81c5:: with SMTP id r5mr16316293jag.143.1566479706788; Thu, 22 Aug 2019 06:15:06 -0700 (PDT) MIME-Version: 1.0 References: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> <003d01d558c8$5211cf20$f6356d60$@olddog.co.uk> In-Reply-To: <003d01d558c8$5211cf20$f6356d60$@olddog.co.uk> From: Barry Leiba <barryleiba@computer.org> Date: Thu, 22 Aug 2019 09:14:55 -0400 Message-ID: <CALaySJL2un4-gXPfzXoRRJM0opS9wd=F42q67prqEjD5xC7r+A@mail.gmail.com> To: Adrian Farrel <adrian@olddog.co.uk> Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, netmod-chairs@ietf.org, netmod@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bZJdkF1QfbFvlFQlE0xZlOo_RkQ> Subject: Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 13:15:09 -0000 > These look like good comments to me, and I think we should fix them all. Thanks, Adrian! b From nobody Thu Aug 22 08:09:53 2019 Return-Path: <rwilton@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7E120921 for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 08:09:52 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MtoGXbwV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rwWbOV8T 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 3moC7PdF8D7n for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 08:09:49 -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 686A612091D for <netmod@ietf.org>; Thu, 22 Aug 2019 08:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11110; q=dns/txt; s=iport; t=1566486589; x=1567696189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=MtoGXbwVsxag2B1KLf823CK5Z9iaEo+OGhzjLjWGEjOOH8uVhf/dyIMw nW3UacgnJk/qGfeiIV5DB9u4HoQh4pxbY4vNAg290+BVVg3Fu8wGzez3t K/37pjpcoQVBjEX0nxeC2pM1r0gCC6AqKlkthxHLWuBJMirQTVOY3JxcW o=; IronPort-PHdr: =?us-ascii?q?9a23=3ALk1oeRGzjmWDYu916mHZyJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAADyr15d/51dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBRFADbVUgBAsqCoQWg0cDimqCXJdmglIDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGDekUCF4JIIzcGDgIJAQEEAQEDAQYEbYUtDIVKAQEBAQM?= =?us-ascii?q?BARALBhEMAQEsCwELBAIBCA4DBAEBAQICJgICAiULFQgIAgQOBQgagwGBagM?= =?us-ascii?q?dAQIMn0wCgTiIYXOBMoJ7AQEFgTIBg2YYghYDBoEMKAGLbhiBQD+BV4JMPoJ?= =?us-ascii?q?hAQGBSxgVgnQygiaMc4IlhTKXFgkCgh2GaY1vgjGHMI5pjxWGLpAvAgQCBAU?= =?us-ascii?q?CDgEBBYFmIoFYcBU7gjgBAQExgkIMF4NPhRSFPgFygSmJDyuBBAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.64,417,1559520000"; d="scan'208";a="619596236" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Aug 2019 15:09:37 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x7MF9bEJ026562 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Aug 2019 15:09:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 10:09:37 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 11:09:35 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 22 Aug 2019 10:09:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+A+NlXoXiXCMBq8B93+kWd1PdU0wgmAupQGrv75PUxQryCriKEE8BP+PGHCdg+E6zwKQ9qLIQqTrWWvGk46HOGBPMxxWMuC6A3W9RMIyoz7P9fb4kiesj1d8wiSGoj8T4aZe7q+C3RIDa0SQq+kFhtOVMZs9AroVg7u0QqVORmz23AMDAipc4ue23fFW6MqVw3smzlNVe4RruxS8beaPbAcXrDgDc5iVVHqTKy8QvS/EdqViWjj6BtL6vAbFHGcDxnGz9g6Ulg7kSZjclECRcdnsOZELfrtrBChWrQgqpII+7y1Byf8ygicVH2ZyBnEcp37sqoz5eZnhvTXIl4CmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=lGFOGaI8DQQwMFVBBIq5Y+wZo7jSBdSfYNRkSRz3ybNzBn7r2LnWah/FcMUAI/qCLwNrBlLHqOKWL2MY8vGXfmrwyEf9rntpzk9w93jFdfcaOY9ews8ItQ2PAtNxFo/i38uOSZrmXHZGKNmqzSb4FaqrwQPFoWPaDEWbDRRwohBwrcgriAyLuQDe9tujN5dT4wW8bk3XmuP80zdfSm6BOhAofUlIDRkMz+CiM5ehjsAN5WZu8NUJkpoXb1BONgxuvkzPVS/rhfmZ0N/Da/LNaey18T3mCECAg1APfYH/Goe6aP12OEhUoJNEbR9oEyprR9huerwkVM6B+D0Kc41CsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=rwWbOV8TcKO28M7nQiwRIXaA/72ZPsDwnTx9szbmt622LhuxllJLu77SNP8Ohg/VBd7hCdyWT4X0og3ASvTcWjA4WG0blrVTWu6n5UtTR3Rbf7mkm31SWrokruv/QTFwplLbP+NDhEjAatmzMZg9rdQduuesJuD4FmLME7kM2Rs= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2SPR01MB0035.namprd11.prod.outlook.com (20.178.251.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Thu, 22 Aug 2019 15:09:34 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2178.020; Thu, 22 Aug 2019 15:09:34 +0000 From: "Rob Wilton (rwilton)" <rwilton@cisco.com> To: Martin Bjorklund <mbj@tail-f.com> CC: "vladimir@transpacket.com" <vladimir@transpacket.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6b5dGgAgAxs3iCAAWyGgIAAJk+A Date: Thu, 22 Aug 2019 15:09:34 +0000 Message-ID: <MN2PR11MB4366DA593D42209D7F44C8EFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> <20190822.133449.502914144686905879.mbj@tail-f.com> In-Reply-To: <20190822.133449.502914144686905879.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35980c64-a3b6-4a68-8397-08d72712be13 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2SPR01MB0035; x-ms-traffictypediagnostic: MN2SPR01MB0035: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: <MN2SPR01MB0035876CC1E483391AE223ABB5A50@MN2SPR01MB0035.namprd11.prod.outlook.com> x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(13464003)(51444003)(189003)(199004)(9686003)(64756008)(6246003)(66066001)(6916009)(54906003)(81166006)(99286004)(8676002)(316002)(11346002)(229853002)(5660300002)(86362001)(446003)(7736002)(14454004)(81156014)(7696005)(53936002)(76176011)(476003)(478600001)(305945005)(74316002)(8936002)(6436002)(102836004)(76116006)(66556008)(66446008)(6306002)(486006)(4326008)(66946007)(3846002)(2906002)(33656002)(6116002)(71190400001)(71200400001)(6506007)(186003)(52536014)(53546011)(25786009)(55016002)(966005)(66476007)(256004)(14444005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2SPR01MB0035; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hZ1Lf5bT6X4Qlq8ivHMh4MsTvN8csxTopdmb13Hl59DaLByxzyBOvseg04T61SufjRfDzM7z0mYA/D1Ngo65I6HqrUbHN5+qKmJSbtcyyIi9cQD+cb0wQMGpOUuWk5qYyC458t9BcujmRabS/iGIS+MXbdNLD529juP6SUythR2A/En49qTK8XO/Oc1+lGaodTam7EglIQ4t0qrqYfbMPWtHzw66fCB0G0bt4a+16lO77MiiiD5bkkZiXNcqpEDuxy4kxVz+4DxYZ50Y0g/o6QZ9yjLjaFSgpj+qw9Dn3xT5NZqMu6UKoOKdno0JllTZFadBoeNbLbrvfpGJFOkgUldLd0VTjt4FejtnGTDGdjQoos0tCqVdbASyQcGbhvVxdrk72B38MvR6ZoegqBjw4YpF73P3r4iyMiVi8+8tJtQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 35980c64-a3b6-4a68-8397-08d72712be13 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 15:09:34.6090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xl/kKkB82TRMnK3184mBxsWXJAj1BekcU6YlP9XQs8dVKPIIBMW+VwhNMyi1Wb4vi9CNNXCobv2BLehk8j9IwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2SPR01MB0035 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MpqdZqH3YFbewOoDal7A6OlaXlc> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 15:09:52 -0000 SGkgTWFydGluLA0KDQpQbGVhc2Ugc2VlIGNvbW1lbnRzIGlubGluZSAuLi4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbT4NCj4gU2VudDogMjIgQXVndXN0IDIwMTkgMTI6MzUNCj4gVG86IFJvYiBXaWx0b24gKHJ3 aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gQ2M6IHZsYWRpbWlyQHRyYW5zcGFja2V0LmNv bTsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGw6 IGRyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmctMDcNCj4gDQo+IEhpLA0KPiANCj4gU29t ZSBjb21tZW50cyBpbmxpbmUuDQo+IA0KPiANCj4gIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndp bHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiA+IEhpIFZsYWRpbWlyLA0KPiA+DQo+ID4gVGhhbmtz IGZvciB5b3VyIGRldGFpbGVkIHJldmlldy4gIFNvcnJ5IGZvciB0aGUgc2xvdyByZXBseSwgSSd2 ZSBiZWVuDQo+ID4gYXdheS4gIEknbSBhbHNvIGFib3V0IHRvIGJlIGF3YXkgYWdhaW4gZm9yIGEg Y291cGxlIG9mIGRheXMuDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSAu Li4NCj4gPg0KPiA+IEknbGwgYWxzbyB0cmFjayB0aGVzZSBpc3N1ZXMgdG8gY2xvc3VyZSBvbg0K PiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvaW50ZXJmYWNlLWV4dGVuc2lvbnMteWFu Zy9pc3N1ZXMNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy b206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBWbGFkaW1p cg0KPiA+ID4gVmFzc2lsZXYNCj4gPiA+IFNlbnQ6IDEzIEF1Z3VzdCAyMDE5IDE3OjA1DQo+ID4g PiBUbzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3Jn DQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsOg0KPiA+ID4gZHJhZnQt aWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KPiA+ID4NCj4gPiA+IEkgaGF2ZSByZXZpZXdl ZCB0aGUgZHJhZnQuIEkgaGF2ZSB0aGUgZm9sbG93aW5nICgxOSkgSU1PIHVzZWZ1bA0KPiA+ID4g cHJvcG9zYWxzOg0KPiA+ID4NCj4gPiA+IDEuIERlZGljYXRlZCBtb2R1bGUgKGlldGYtaWYtb3Bl ci1zdGF0dXMtZGVib3VuY2UueWFuZykgZm9yIHRoZQ0KPiA+ID4gb3Blci0gc3RhdHVzIGRlYm91 bmNpbmcvZGFtcGVuaW5nIGZ1bmN0aW9uYWxpdHkgY3VycmVudGx5IGluDQo+ID4gPiBpZXRmLWlu dGVyZmFjZXMtDQo+ID4gPiBjb21tb24ueWFuZy4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhh dCB3ZSB3YW50IGEgcHJvbGlmZXJhdGlvbiBvZiB0b28gbWFueSBzZXBhcmF0ZSBZQU5HDQo+ID4g bW9kdWxlcyBmb3Igc21hbGwgZmVhdHVyZXMuICBFYWNoIG9mIHRoZSBhcmVhcyBvZiBkaWZmZXJl bnQNCj4gPiBmdW5jdGlvbmFsaXR5IHdpdGhpbiB0aGlzIG1vZHVsZSBhcmUgYWxyZWFkeSBjb25k aXRpb25hbCBvbg0KPiA+IGlmLWZlYXR1cmUsIHNvIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSBp cyBhIHN0cm9uZyBqdXN0aWZpY2F0aW9uIHRvDQo+ID4gc2VwYXJhdGluZyB0aGlzIG91dCBhcyBh IHNlcGFyYXRlIG1vZHVsZS4NCj4gDQo+IEkgYWdyZWUuDQo+IA0KPiA+ID4gNC4gRGVkaWNhdGVk IG1vZHVsZSAoaWV0Zi1pZi1sb29wYmFjay55YW5nKSBmb3IgdGhlIGxvb3BiYWNrDQo+ID4gPiBm dW5jdGlvbmFsaXR5IGN1cnJlbnRseSBpbiBpZXRmLWludGVyZmFjZXMtY29tbW9uLnlhbmcuDQo+ ID4NCj4gPiBTYW1lIGFuc3dlciBhcyBmb3IgMS4gSSBkb24ndCB0aGluayB0aGF0IHdlIHNob3Vs ZCBoYXZlIHRvbyBtYW55DQo+ID4gcmVhbGx5IHNtYWxsIG1vZHVsZXMuDQo+IA0KPiBJIGFncmVl Lg0KPiANCj4gDQo+ID4gPiAxMC4gSW50cm9kdWNpbmcgY29uZmlnIHRydWUgImZvcndhcmRpbmct bW9kZSIgbGVhZiBicmVha3MgY2xpZW50cw0KPiA+ID4gdGhhdCBzdXBwb3J0IGUuZy4gcmZjODM0 NCBpZXRmLWlwICh3aGljaCBoYXMgaXRzIGRlZGljYXRlZA0KPiA+ID4gZm9yd2FyZGluZyBsZWFm cyBlLmcuDQo+ID4gPiAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaW50ZXJmYWNlL2lldGYt aXA6aXB2NC9mb3J3YXJkaW5nICkgYnkNCj4gPiA+IGludHJvZHVjaW5nIHRoaXMgbmV3IG1vZHVs ZSB3aXRoIGEgbmV3IGxlYWYgdGhleSBrbm93IG5vdGhpbmcgYWJvdXQuDQo+ID4gPiBJIHN1cHBv cnQgdGhpcyBsZWFmIGFzIGNvbmZpZyBmYWxzZS4gSWYgTkVUQ09ORiB3YXMgbm90DQo+ID4gPiB0 cmFuc2FjdGlvbmFsIGEgZ2xvYmFsIGxlYWYgZW5hYmxpbmcgdGhlIGZvcndhcmRpbmcgY29uZmln dXJhdGlvbg0KPiB3b3VsZCBiZSBhIGZlYXR1cmUuDQo+ID4gPiBCdXQgTkVUQ09ORiBpcyB0cmFu c2FjdGlvbmFsLg0KPiA+DQo+ID4gSSBkb24ndCBnZXQgdGhlIHJlbGV2YW5jZSBvZiB0cmFuc2Fj dGlvbnMsIGJ1dCBpdCBpc24ndCBpbnRlbmRlZCB0bw0KPiA+IGJyZWFrIGV4aXN0aW5nIGNsaWVu dHMvWUFORyBtb2R1bGVzLg0KPiA+DQo+ID4gVGhlIGlkZWEgb2YgdGhpcyBsZWFmIGlzIHRoYXQg aWYgaXQgaXMgY29uZmlndXJlZCB0aGVuIHRoZSBzeXN0ZW0gY2FuDQo+ID4gdXNlIGl0IHRvIGNo ZWNrIG90aGVyIGNvbnN0cmFpbnRzLiAgRS5nLiB0byB2YWxpZGF0ZSB0aGF0IGFuIEwyIFFvUw0K PiA+IHBvbGljeSBpc27igJl0IGJlaW5nIGNvbmZpZ3VyZWQgb24gYW4gTDMgaW50ZXJmYWNlLiAg SWYgdGhlIGxlYWYgaXNuJ3QNCj4gPiBjb25maWd1cmVkIHRoZW4gdGhvc2UgY29uc3RyYWludHMg YXJlIG5vdCBjaGVja2VkLg0KPiANCj4gSG1tLiAgQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGlzIGxl YWYgZG9lc24ndCBoYXZlIGFueSBkaXJlY3QgZWZmZWN0IGluIHRoZQ0KPiBzZXJ2ZXI/DQoNCkl0 IGRlcGVuZHMgb24gdGhlIGRldmljZS4gIFNvbWUgZGV2aWNlcyByZXF1aXJlIGEgbGVhZiBsaWtl IHRoaXMgKG9yIHNpbWlsYXIpIHRvIGNvcnJlY3RseSBwcm92aXNpb24gdGhlIHNlcnZpY2VzLiAg T3RoZXIgZGV2aWNlcyBkb24ndCBuZWVkIGl0Lg0KDQoNCg0KPiANCj4gPiA+IDEyLiBJIGRvIG5v dCBhZ3JlZSB3ZSBuZWVkIHRoaXMgdGV4dC4gTm9ybWFsbHkgTkVUQ09ORiBkZXZpY2VzDQo+ID4g PiBzaG91bGQgYWNjZXB0IHRyYW5zYWN0aW9ucyB0byBhbnkgdmFsaWQgY29uZmlndXJhdGlvbjoN Cj4gPiA+DQo+ID4gPiBPTEQ6DQo+ID4gPiAgwqDCoCAuLi4NCj4gPiA+ICDCoMKgIE5vcm1hbGx5 IGRldmljZXMgd2lsbCBub3QgYWxsb3cgdGhlIHBhcmVudC1pbnRlcmZhY2UgbGVhZiB0byBiZQ0K PiA+ID4gIMKgwqAgY2hhbmdlZCBhZnRlciB0aGUgaW50ZXJmY2UgaGFzIGJlZW4gY3JlYXRlZC7C oCBJZiBhbg0KPiA+ID4gaW1wbGVtZW50YXRpb24NCj4gPiA+ICDCoMKgIGRpZCBhbGxvdyB0aGUg cGFyZW50LWludGVyZmFjZSBsZWFmIHRvIGJlIGNoYW5nZWQgdGhlbiBpdCBjb3VsZA0KPiA+ID4g Y2F1c2UNCj4gPiA+ICDCoMKgIGFsbCB0cmFmZmljIG9uIHRoZSBhZmZlY3RlZCBpbnRlcmZhY2Ug dG8gYmUgZHJvcHBlZC7CoCBUaGUNCj4gPiA+IGFmZmVjdGVkDQo+ID4gPiAgwqDCoCBsZWFmIGlz Og0KPiA+ID4NCj4gPiA+ICDCoMKgIG/CoCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UvcGFy ZW50LWludGVyZmFjZQ0KPiA+ID4gIMKgwqAgLi4uDQo+ID4gPg0KPiA+ID4gTkVXOg0KPiA+ID4g IMKgwqAgLi4uDQo+ID4gPiAgwqDCoCBDaGFuZ2luZyB0aGUgcGFyZW50LWludGVyZmFjZSBsZWFm IGNvdWxkIGNhdXNlDQo+ID4gPiAgwqDCoCBhbGwgdHJhZmZpYyBvbiB0aGUgYWZmZWN0ZWQgaW50 ZXJmYWNlIHRvIGJlIGRyb3BwZWQuDQo+ID4gPiAgwqDCoCBUaGUgYWZmZWN0ZWQgbGVhZiBpczoN Cj4gPiA+DQo+ID4gPiAgwqDCoCBvwqAgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL3BhcmVu dC1pbnRlcmZhY2UNCj4gPiA+ICDCoMKgIC4uLg0KPiA+DQo+ID4gVGhpcyBpc24ndCBhYm91dCB0 cmFuc2FjdGlvbnMgc28gbXVjaCBhcyB2YWxpZCBjb25maWd1cmF0aW9uLg0KPiA+DQo+ID4gTm9y bWFsbHksIHRoZSBuYW1lIG9mIHRoZSBzdWItaW50ZXJmYWNlIGlzIHRpZ2h0bHkgYm91bmQgdG8g dGhlIHBhcmVudA0KPiA+IGludGVyZmFjZS4gIEUuZy4gaWYgdGhlIHBhcmVudCBpbiAiRXRoZXJu ZXQwLzEiIHRoZW4gdGhlIHN1Yi1pbnRlcmZhY2UNCj4gPiB3b3VsZCBiZSAiRXRoZXJuZXQwLzEu MSIuICBJZiB5b3UgdHJpZWQgdG8gY2hhbmdlIHRoZSBwYXJlbnQtaW50ZXJmYWNlDQo+ID4gbGVh ZiBvZiAiRXRoZXJuZXQwLzEuMSIgdG8gIkV0aGVybmV0Mi8yIiB0aGVuIEkgd291bGQgZXhwZWN0 IHRoZQ0KPiA+IHN5c3RlbSB0byByZWplY3QgdGhhdCBjaGFuZ2UgKGJlY2F1c2UgdGhlIGNvbmZp Z3VyYXRpb24gaXMgaW52YWxpZCBub3QNCj4gPiBiZWNhdXNlIG9mIHRyYW5zYWN0aW9ucykuDQo+ IA0KPiBXZWxsLCB0aGlzIGlzIGFscmVhZHkgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy42LiAgVGhl IHF1b3RlZCB0ZXh0IGlzIGZyb20NCj4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuICBJIGFncmVl IHdpdGggVmxhZGltaXI7IEkgdGhpbmsgaGlzIHN1Z2dlc3RlZA0KPiB0ZXh0IGlzIGJldHRlci4N Cg0KQWgsIE9LLiAgSWYgaXQgaXMgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24sIHRoZW4gSSBhZ3Jl ZSB0aGF0IGl0IGlzbid0IHJlcXVpcmVkLg0KDQoNCj4gDQo+ID4gPiAxNC4gSSBwcm9wb3NlIHRo ZSBpbi1wa3RzIGFuZCBvdXQtcGt0cyBjb3VudGVycyBzdGFuZGFyZGl6ZWQgdG9vLg0KPiA+ID4g aHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy9ibG9iL21hc3Rlci92ZW5kb3IvY2lz Y28veGUvMTY0MS8NCj4gPiA+IGlldGYtDQo+ID4gPiBpbnRlcmZhY2VzLWV4dC55YW5nLg0KPiA+ ID4gQW5kIHllcyBzb21lb25lIGZvcmdvdCB0byB1cGRhdGUgdGhlIGJvaWxlcnBsYXRlIHRleHQu DQo+ID4NCj4gPiBUaGlzIG9uZSBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBnZXQgZnVydGhlciBp bnB1dCBvbi4NCj4gPg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxv Yi9tYXN0ZXIvc3RhbmRhcmQvaWVlZS9wdWJsaXNoZWQNCj4gPiAvODAyLjMvaWVlZTgwMi1ldGhl cm5ldC1pbnRlcmZhY2UueWFuZw0KPiA+DQo+ID4gZGVmaW5lcyBpbi1mcmFtZXMgYW5kIG91dC1m cmFtZXMsIGJ1dCB0aGVzZSBhcmUgb25seSBmb3IgRXRoZXJuZXQsIGJ1dA0KPiA+IHlvdSBhcmUg cHJvYmFibHkgbG9va2luZyBmb3IgYSBjb3VudGVyIGFjcm9zcyBhbGwgaW50ZXJmYWNlIHR5cGVz Lg0KPiANCj4gaW4tcGt0cyBpcyBwcmVzdW1hYmx5IGluLXVuaWNhc3QtcGt0cyArIGluLWJyb2Fk Y2FzdC1wa3RzICsgaW4tbXVsdGljYXN0LQ0KPiBwa3RzLiAgU28gaXMgdGhpcyByZWFsbHkgbmVl ZGVkPw0KDQpJdCBzZWVtcyB0aGF0IHRoaXMgbWlnaHQgYmUgYW4gaXNzdWUgcmVsYXRlZCB0byB0 aGUgcm91dGUgcG9saWN5IGxhbmd1YWdlIHRoYXQgd2FudHMgdGhlIHBvbGljeSB0byB1c2UgdGhl IHRvdGFsIG51bWJlciBvZiBnb29kIHBrdHMsIGJ1dCBpcyB1bmFibGUgb2YgYWRkaW5nIHRoZSAz IGluZGl2aWR1YWwgdmFsdWVzIHRvZ2V0aGVyLg0KDQpJdCBzZWVtcyBzbGlnaHRseSBzdHJhbmdl IHRvIG1lIHRoYXQgdGhlIHRvdGFsIGlucHV0L291dHB1dCBwa3QgY291bnRlcnMgZG9uJ3QgZXhp c3QsIHBhcnRpY3VsYXJseSBpZiB5b3UgaGFkIGEgcG9pbnQtdG8tcG9pbnQgTDIgcHJvdG9jb2wg dGhhdCBkb2Vzbid0IGRpZmZlcmVudGlhdGUgYmV0d2VlbiB1Y2FzdCwgbWNhc3QgYW5kIGJjYXN0 Lg0KDQoNCj4gDQo+ID4gPiAxOS4gaWV0Zi1pZi1jb21tb24ueWFuZyBhbmQgaWV0Zi1pZi1ldGhl cm5ldC1saWtlLnlhbmcgaW5zdGVhZCBvZg0KPiA+ID4gaWV0Zi0NCj4gPiA+IGludGVyZmFjZXMt Y29tbW9uLnlhbmcgYW5kIGlldGYtaW50ZXJmYWNlcy1ldGhlcm5ldC1saWtlLnlhbmcuDQo+ID4g PiBTZXR0aW5nIGEgc2hvcnRlciBuYW1pbmcgcHJlY2VkZW50IGZvciBmdXR1cmUgbW9kdWxlcyBh dWdtZW50aW5nDQo+ID4gPiBpZXRmLSBpbnRlcmZhY2VzLg0KPiA+DQo+ID4gSSdtIG5vdCBvcHBv c2VkIHRvIHNob3J0ZXIgbmFtZXMsIGJ1dCB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHRoZSB2aWV3 cw0KPiA+IG9mIG90aGVycyBpbiB0aGUgV0cuDQo+IA0KPiBJIGhhZCBhIHNpbWlsYXIgY29uY2Vy biBmb3IgdGhlIG1vZHVsZXMgaW4gdGhlIHN1Yi1pbnRmLXZsYW4gZHJhZnQgKEkgd2lsbA0KPiBw b3N0IG15IHJldmlldyBvZiB0aGF0IGRvYyBsYXRlcikuDQo+IA0KPiBDdXJyZW50bHkgd2UgaGF2 ZToNCj4gDQo+ICAgaWV0Zi1pbnRlcmZhY2VzLWNvbW1vbg0KPiAgIGlldGYtaW50ZXJmYWNlcy1l dGhlcm5ldC1saWtlDQo+ICAgaWV0Zi1pZi1sMy12bGFuDQo+ICAgaWV0Zi1mbGV4aWJsZS1lbmNh cHN1bGF0aW9uDQo+IA0KPiBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGNvbnNpc3RlbmN5LCBlaXRo ZXI6DQo+IA0KPiAgIGlldGYtaW50ZXJmYWNlcy1jb21tb24NCj4gICBpZXRmLWludGVyZmFjZXMt ZXRoZXJuZXQtbGlrZQ0KPiAgIGlldGYtaW50ZXJmYWNlcy1sMy12bGFuDQo+ICAgaWV0Zi1pbnRl cmZhY2VzLWZsZXhpYmxlLWVuY2Fwc3VsYXRpb24NCj4gDQo+IG9yDQo+IA0KPiAgIGlldGYtaWYt Y29tbW9uDQo+ICAgaWV0Zi1pZi1ldGhlcm5ldC1saWtlDQo+ICAgaWV0Zi1pZi1sMy12bGFuDQo+ ICAgaWV0Zi1pZi1mbGV4aWJsZS1lbmNhcHN1bGF0aW9uDQo+IA0KDQpJIHByZWZlciB0aGUgc2hv cnRlciBuYW1lcyBwZXJzb25hbGx5Lg0KDQpUaGFua3MsDQpSb2INCg0KDQo+IA0KPiAvbWFydGlu DQo+IA0KPiANCj4gPg0KPiA+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldy4gIEl0IGlzIGFw cHJlY2lhdGVkLg0KPiA+DQo+ID4gUm9iDQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+IC9WbGFkaW1p cg0KPiA+ID4NCj4gPiA+IE9uIDEwLzA3LzIwMTkgMDIuMTUsIEtlbnQgV2F0c2VuIHdyb3RlOg0K PiA+ID4gPiBBbGwsDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgc3RhcnRzIGEgdHdlbHZlLWRheSB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3INCj4gPiA+ID4gZHJhZnQtaWV0Zi1uZXRtb2QtaW50 Zi1leHQteWFuZy0wNw0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNh bGwgZW5kcyBvbiBKdWx5IDIxICh0aGUgZGF5IGJlZm9yZSB0aGUNCj4gPiA+ID4gTkVUTU9EDQo+ ID4gPiAxMDUgc2Vzc2lvbnMpLiAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgd29y a2luZyBncm91cA0KPiA+ID4gbWFpbGluZyBsaXN0Lg0KPiA+ID4gPg0KPiA+ID4gPiBQb3NpdGl2 ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2 ZQ0KPiA+ID4gPiBpdCBpcw0KPiA+ID4gcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNv bWUhICBUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LA0KPiA+ID4gZXZlbiBmcm9tIGF1dGhv cnMuDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rIHlvdSwNCj4gPiA+ID4gTkVUTU9EIENoYWlycw0K PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGlu ZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Thu Aug 22 13:15:01 2019 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6D4120889 for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 13:14:59 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slYPGzfC3NYL for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 13:14:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8812011B for <netmod@ietf.org>; Thu, 22 Aug 2019 13:14:58 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 98F4E1AE0981 for <netmod@ietf.org>; Thu, 22 Aug 2019 22:14:53 +0200 (CEST) Date: Thu, 22 Aug 2019 22:14:53 +0200 (CEST) Message-Id: <20190822.221453.1052536475937856222.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <0100016bd93be4a2-a22ba545-c022-44d6-9188-1b51ff1effe0-000000@email.amazonses.com> References: <0100016bd93be4a2-a22ba545-c022-44d6-9188-1b51ff1effe0-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TIl-enDCk7jquEw15XH5rFWwzTY> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 20:15:00 -0000 Hi, Here is my (late) review of draft-ietf-netmod-sub-intf-vlan-model-05. o 1 The YANG module names are not correct; they are listed as: if-l3-vlan.yang - Defines the model for basic classification of VLAN tagged traffic to L3 transport services flexible-encapsulation.yang - Defines the model for flexible classification of Ethernet/VLAN traffic to L2 transport services Should be "ietf-if-l3-vlan" and "ietf-flexible-encapsulation". Or "ietf-if-l3-vlan" and "ietf-if-flexible-encapsulation". But I also wonder if these names should somehow be changed. What is a "l3-vlan"? And "flexible-encapsulation" sound a bit too generic. o 1.1 The text says: Sub-interface: A sub-interface is a small augmentation of a regular interface in the standard YANG module for Interface Management that represents a subset of the traffic handled by its parent interface. I think the augmentation is the YANG-realization of a sub-interface, but it is not what a sub-interface is. Also, this definition is mis-leading; it doesn't mention that a sub-interface has its own interface type and is represented as one separate entry in the interface list. I think it is better to import this term from draft-ietf-netmod-intf-ext-yang (section 3.6) o 3 The text says: The L3 Interface VLAN model provides appropriate leaves for termination of an 802.1Q VLAN tagged segment to a sub-interface based L3 service. There is a comment in the YANG model that says the same thing. But the YANG model itself augments not only to sub-interface-based interface, but also to ethernet-like interfaces. o YANG modules Both modules lack the IETF Trust Copyright statement. We don't list WG Chairs anymore. The revision statements should be on the form: "RFC XXXX: <title>" Many descriptions are full sentences w/o the ending ".". The modules should be indented properly; a starting point can be pyang -f yang --yang-line-length 69 o ietf-if-l3-vlan There is a comment: /* * Matches a single VLAN Id, or a pair of VLAN Ids to classify * traffic into an L3 service. */ This should be moved into a description clause. o ietf-if-l3-vlan / container dot1q-vlan The must statement has: count(../../if-cmn:forwarding-mode) = 0 This can be changed to not(../../if-cmn:forwarding-mode) which is more direct imo. The must statement's description statement seems to be a copy-and-paste error. o ietf-if-l3-vlan / container dot1q-vlan The descriptions talk about "matching frames" and "classifying traffic", but it is not described anywhere how the matching and classifying is used. (also applies to ietf-flexible-encapsulation) o ietf-if-l3-vlan / outer-tag / second-tag These names are a bit inconsistent. The description describes them as "outermost tag" and "second outermost tag". Perhaps use these names instead? (same names are found in ietf-flexible-encapsulation) o ietf-flexible-encapsulation / all features The features are described as: "This feature indicates whether the network element supports specifying flexible rewrite operations"; Should this be s/whether/that ? o ietf-flexible-encapsulation There is some descriptive text in comments that should be moved to description statements. o ietf-flexible-encapsulation The descriptions for pop/push are a bit terse. It seems to assume that readers already know what this (from somewhere) is so it doesn't need to be described. If this is intended, perhaps add a reference to where this is described. /martin From nobody Fri Aug 23 10:50:44 2019 Return-Path: <alandawn91@gmail.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364A1120108 for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 XULeVqubex-I for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 10:50:41 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 01283120044 for <netmod@ietf.org>; Fri, 23 Aug 2019 10:50:40 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id f22so14646491edt.4 for <netmod@ietf.org>; Fri, 23 Aug 2019 10:50:40 -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=mmc3JvUSTdHA8FMnv1I3XCsMfjziMb+AJsFP6M7ykFg=; b=ph60xOskbZ0WvAIQPGoUUDKPeKqiSGACbYx3XikZCGXMlVIK6cZrUFllmYS/LyMeL2 nMjEv39ME7HowUxtbjoi3O7GaE+MU5L/Zarwj4nFZPo8TSlLEwNFOuf/0ulEqxExT8Vs RkxR6w0wOdN3REnn6XaUm93zuR7miR2O8ar3Urj90bARU5tTRXTTyifKK0RDB41hUVkx Yjt71V7TyhTNaawB4oBj/a8sW/1Fbgv36QDNfVZjO7owGi313TQk01FVSbYUOnxh9+1f gBnNVZDWamkrtwqZuf+a++wTHngO2RcYlFmBk8MV7Y0Bx7qIMGCZV3kntGFDeCbFR8R0 8y7Q== 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=mmc3JvUSTdHA8FMnv1I3XCsMfjziMb+AJsFP6M7ykFg=; b=scoeF6V9hMhGgcpnEZYwSSXAIwZdW3D2SaxQicWxG7NoBAO0hOjEMOZ9EF3hh7SHjo i1US2klZdXQZ5VSavix8gPAeB80Ieb5uXOwNLSjYMIoKxOmKGiHdXLDhufg6lQUf3sn7 iM6LWfIafgk03AnsKgaBnyh5KU/kdgxG1VAjLAwUpBhTffvqWhT9eyO59/DTK8iPbBKh jCD5SV0P7Qjffwz0tsqIbujVgpwdZYG+SG+XjQTaQylx+Lq7tBL7CqTSJITAd27n9sbo 0eAiXWhu38R9Yz+sBNcymDQyk2oP6MsSJQ9vuaPlv14eDU2EjbvT2cErumYx1QslFD1w HJlg== X-Gm-Message-State: APjAAAV3bntKJ88lxt2w8+RXJdTKp6ZpEZO65ShQvEjNeOF3eck++M8j 36nMRuIstUuza+c5FtTz86LLg15CdIGnaAp1C0xLWg== X-Google-Smtp-Source: APXvYqzUxemfljr28kwdYheasqSqEv5D/uaHNqHUdqhsn/m/ytHmgYhgeqz9bqpwOUDCtvtF+9xqNRSE5uL9QpLKE84= X-Received: by 2002:aa7:c0d9:: with SMTP id j25mr5860714edp.166.1566582639502; Fri, 23 Aug 2019 10:50:39 -0700 (PDT) MIME-Version: 1.0 From: Alan Dawn <alandawn91@gmail.com> Date: Fri, 23 Aug 2019 13:50:27 -0400 Message-ID: <CAFS-HXoJtLaqK5UiZGzy5D1xfsc-g8KBFDV4XDwexi9qHXpjuQ@mail.gmail.com> To: netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000bd27270590cc71c8" Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EJLXR6Ld-JVNs4GqhkinD0WQsV0> Subject: [netmod] yang to mib X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 23 Aug 2019 17:50:42 -0000 --000000000000bd27270590cc71c8 Content-Type: text/plain; charset="UTF-8" Has there been any work done on defining a method of converting yang modules to mib modules? --000000000000bd27270590cc71c8 Content-Type: text/html; charset="UTF-8" <div dir="ltr">Has there been any work done on defining a method of converting yang modules to mib modules?<br></div> --000000000000bd27270590cc71c8-- From nobody Fri Aug 23 11:17:44 2019 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5A212006A for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 11:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 v8lek5P_jwgn for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 11:17:40 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E25120044 for <netmod@ietf.org>; Fri, 23 Aug 2019 11:17:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1206C33D; Fri, 23 Aug 2019 20:17:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id HEw45dAl1X1R; Fri, 23 Aug 2019 20:17:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Aug 2019 20:17:38 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFED62013F; Fri, 23 Aug 2019 20:17:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id JZYwLRb4EdEu; Fri, 23 Aug 2019 20:17:38 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6B5982013E; Fri, 23 Aug 2019 20:17:38 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 23 Aug 2019 20:17:37 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 9EBF94C6369; Fri, 23 Aug 2019 20:17:37 +0200 (CEST) Date: Fri, 23 Aug 2019 20:17:37 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Alan Dawn <alandawn91@gmail.com> CC: <netmod@ietf.org> Message-ID: <20190823181736.ee562zme3udbj53u@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mail-Followup-To: Alan Dawn <alandawn91@gmail.com>, netmod@ietf.org References: <CAFS-HXoJtLaqK5UiZGzy5D1xfsc-g8KBFDV4XDwexi9qHXpjuQ@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <CAFS-HXoJtLaqK5UiZGzy5D1xfsc-g8KBFDV4XDwexi9qHXpjuQ@mail.gmail.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/b_iGqy4HQn1dSpdJnzPoVo-Siwg> Subject: Re: [netmod] yang to mib X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 23 Aug 2019 18:17:43 -0000 On Fri, Aug 23, 2019 at 01:50:27PM -0400, Alan Dawn wrote: > Has there been any work done on defining a method of converting yang > modules to mib modules? Since YANG is way more flexible than SMIv2, this will only work if the YANG language is heavily restricted to a subset that is mappable. My recommendation is to not spent time on this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> From nobody Fri Aug 23 13:20:55 2019 Return-Path: <reid@snmp.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F59312085F for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ZRR8G1aV-E for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 13:20:52 -0700 (PDT) Received: from mailbox.SNMP.COM (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1D12082F for <netmod@ietf.org>; Fri, 23 Aug 2019 13:20:52 -0700 (PDT) Received: from rh7.snmp.com (rh7.snmp.com [192.147.142.222]) by mailbox.SNMP.COM (8.9.3p2-20030922/m.0080228) with ESMTP id QAA06127; Fri, 23 Aug 2019 16:20:45 -0400 (EDT) Received: from snmp.com (rh7 [IPv6:::1]) by rh7.snmp.com (Postfix) with ESMTP id 15FF63E83B; Fri, 23 Aug 2019 16:20:45 -0400 (EDT) To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> cc: Alan Dawn <alandawn91@gmail.com>, netmod@ietf.org Reply-To: David Reid <reid@snmp.com> From: David Reid <reid@snmp.com> In-reply-to: Your message of Fri, 23 Aug 2019 20:17:37 +0200. <20190823181736.ee562zme3udbj53u@anna.jacobs.jacobs-university.de> Date: Fri, 23 Aug 2019 16:20:44 -0400 Sender: reid@snmp.com Message-Id: <20190823202045.15FF63E83B@rh7.snmp.com> Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/b96-GYyusKYkSHIaSRs_7QtZ4ro> Subject: Re: [netmod] yang to mib X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 23 Aug 2019 20:20:54 -0000 > > Has there been any work done on defining a method of converting yang > > modules to mib modules? > > Since YANG is way more flexible than SMIv2, this will only work if the > YANG language is heavily restricted to a subset that is mappable. My > recommendation is to not spent time on this. > > /js Some of the yang constructs that can't easily be mapped could be mapped with some creativity. I think the subset that can't be mapped would be relatively small. -David Reid From nobody Fri Aug 23 13:59:49 2019 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D890120122 for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 13:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 EVzxgjs_lx80 for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 13:59:46 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CE312011D for <netmod@ietf.org>; Fri, 23 Aug 2019 13:59:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 816D7674; Fri, 23 Aug 2019 22:59:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 0DuHcFAvmK4W; Fri, 23 Aug 2019 22:59:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Aug 2019 22:59:45 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A1F72013F; Fri, 23 Aug 2019 22:59:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id mCRJ4Ot_FB8O; Fri, 23 Aug 2019 22:59:45 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id AC4F72013E; Fri, 23 Aug 2019 22:59:44 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 23 Aug 2019 22:59:44 +0200 Received: by anna.localdomain (Postfix, from userid 501) id CD4434C6636; Fri, 23 Aug 2019 22:59:43 +0200 (CEST) Date: Fri, 23 Aug 2019 22:59:43 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: David Reid <reid@snmp.com> CC: Alan Dawn <alandawn91@gmail.com>, <netmod@ietf.org> Message-ID: <20190823205943.wuovwozmnwz7wmzn@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mail-Followup-To: David Reid <reid@snmp.com>, Alan Dawn <alandawn91@gmail.com>, netmod@ietf.org References: <20190823181736.ee562zme3udbj53u@anna.jacobs.jacobs-university.de> <20190823202045.15FF63E83B@rh7.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190823202045.15FF63E83B@rh7.snmp.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hvL-7oznrsthpq7HD7jasUCQsAk> Subject: Re: [netmod] yang to mib X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 23 Aug 2019 20:59:48 -0000 On Fri, Aug 23, 2019 at 04:20:44PM -0400, David Reid wrote: > > > Has there been any work done on defining a method of converting yang > > > modules to mib modules? > > > > Since YANG is way more flexible than SMIv2, this will only work if the > > YANG language is heavily restricted to a subset that is mappable. My > > recommendation is to not spent time on this. > > > > /js > > Some of the yang constructs that can't easily be mapped could be mapped with some creativity. I think the subset that can't be mapped would be relatively small. > Yes, I stand corrected, you can probably even map everything somehow. Whether such mappings result in _usable_ MIB module is going to be a question for which answers will be subjective. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> From nobody Fri Aug 23 16:35:46 2019 Return-Path: <alandawn91@gmail.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669DD12006A for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 16:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 DckNBf5uk08Y for <netmod@ietfa.amsl.com>; Fri, 23 Aug 2019 16:35:44 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 A2E2512000F for <netmod@ietf.org>; Fri, 23 Aug 2019 16:35:43 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id x19so15877822eda.12 for <netmod@ietf.org>; Fri, 23 Aug 2019 16:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=p+hvRqd0U/6kmXoV+5pri9f9wDF6Dr5LoXVLlTL4Ekc=; b=H8FA8x/jxXyZjq94cCq3sXNtfxDZSzdw365OdmwrH4s9hQ9oBcDRYqbtoBYtOzcY0Z vwHI1oyklfE04SKpX27a0PvKOgtFN3N7nHZLVms/hLb6yUC5dRnYPjV7T5O8186lFzL6 BUFfvdEN0DyFS52or8bdI3clPpF8u4AfI0AKH83iqHQ96LkSeqbyRmNndeGS34ylprCd cBa0TnpIOEubSupcVpUml284qB7mcDG+6rJvUnjU7sA2D1P2vA+19K+mKJjv8ARW8Z5x j8TjR/EvR0WI2lLrlhQvkruFK/lKRYfLQo3A7CioSEtngYzEYezU4Kp2XuYURQYcA0+C OYjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=p+hvRqd0U/6kmXoV+5pri9f9wDF6Dr5LoXVLlTL4Ekc=; b=gjbQdpNSgJGSMW6cIwRQp+OSqBWjZ9rftka6Shd7fXv2nEJrgXsiO7MnMXdzglTIqV jCpCk2Nwdxs0jEJxe0yWvuJOQ45D/6g0M0NYy7Zs+TGXU/5/wBEqP7ixZZDFA8Pezgtx KeyIvcm/5L7yj7woadF74tjJbB0qZCHvUzi0mtwZMoNDV8F40HQz92vZ0HUtDUFc/A7S BXYkKZ0RcRFxcZp6rIc1qpCCtGBZ6RAR2tM+dIkKa/QkgnhT3KFtzaBuN52Wkbp2s717 TZC9ULVB/SYjLSEU5WOm+EZ4neVTJIx1OuXZsobFE3V/9x8SuijJyupbBMESvyg/Lscf 4N3g== X-Gm-Message-State: APjAAAWNrDxUBisxwpYSwH1M/0tr0oy0Dxluuzw9v+h1TjYaFVmkCUWL h8SIwlAZLW9qR81Kp0stWICeytjJvaTQ0w/KQEI= X-Google-Smtp-Source: APXvYqzr4NjBzAARnUkxc+6sg/aP15F4aJ1YoCOtv1/OWBVAh/auR3hQpLvKFqC67SJoHNac9hw7pinMbFQwBHfko0Y= X-Received: by 2002:a17:906:e10b:: with SMTP id gj11mr6568931ejb.138.1566603342321; Fri, 23 Aug 2019 16:35:42 -0700 (PDT) MIME-Version: 1.0 References: <20190823181736.ee562zme3udbj53u@anna.jacobs.jacobs-university.de> <20190823202045.15FF63E83B@rh7.snmp.com> <20190823205943.wuovwozmnwz7wmzn@anna.jacobs.jacobs-university.de> In-Reply-To: <20190823205943.wuovwozmnwz7wmzn@anna.jacobs.jacobs-university.de> From: Alan Dawn <alandawn91@gmail.com> Date: Fri, 23 Aug 2019 19:35:35 -0400 Message-ID: <CAFS-HXqbyc=zwKj73gxFBj4Bh97FA+stowJLsj6qGgycK8iX7w@mail.gmail.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, David Reid <reid@snmp.com>, Alan Dawn <alandawn91@gmail.com>, netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000b91a1d0590d143e0" Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8FwnnVlUIAKfbSF_kaTItLkmCDg> Subject: Re: [netmod] yang to mib X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 23 Aug 2019 23:35:45 -0000 --000000000000b91a1d0590d143e0 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 23, 2019 at 4:59 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Aug 23, 2019 at 04:20:44PM -0400, David Reid wrote: > > > > Has there been any work done on defining a method of converting yang > > > > modules to mib modules? > > > > > > Since YANG is way more flexible than SMIv2, this will only work if the > > > YANG language is heavily restricted to a subset that is mappable. My > > > recommendation is to not spent time on this. > > > > > > /js > > > > Some of the yang constructs that can't easily be mapped could be mapped > with some creativity. I think the subset that can't be mapped would be > relatively small. > > > > Yes, I stand corrected, you can probably even map everything somehow. > Whether such mappings result in _usable_ MIB module is going to be a > question for which answers will be subjective. > > /js > > Perhaps there would be value in defining a subset that could be reasonably mapped. I found a project that has a pyang module for yang to mib conversion: http://help.openclovis.com/index.php/Convert_YANG_to_MIB_model I was not able to get it to work, so I don't know how complete it is. --000000000000b91a1d0590d143e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g= mail_attr">On Fri, Aug 23, 2019 at 4:59 PM Juergen Schoenwaelder <<a hre= f=3D"mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-un= iversity.de</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">On Fri, Aug 23, 2019 at 04:20:44PM -0400, David Reid wrote:<br> > > > Has there been any work done on defining a method of convert= ing yang<br> > > > modules to mib modules?<br> > > <br> > > Since YANG is way more flexible than SMIv2, this will only work i= f the<br> > > YANG language is heavily restricted to a subset that is mappable.= My<br> > > recommendation is to not spent time on this.<br> > > <br> > > /js<br> > <br> > Some of the yang constructs that can't easily be mapped could be m= apped with some creativity. I think the subset that can't be mapped wou= ld be relatively small.<br> > <br> <br> Yes, I stand corrected, you can probably even map everything somehow.<br> Whether such mappings result in _usable_ MIB module is going to be a<br> question for which answers will be subjective.<br> <br> /js<br>=C2=A0 <br></blockquote><div><br></div><div>Perhaps there would be value in defini= ng a subset that could be reasonably mapped.</div><div><br></div><div>I fou= nd a project that has a pyang module for yang to mib conversion:=20 <a href=3D"http://help.openclovis.com/index.php/Convert_YANG_to_MIB_model">= http://help.openclovis.com/index.php/Convert_YANG_to_MIB_model</a></div><di= v>I was not able to get it to work, so I don't know how complete it is.= </div><div><br> </div></div></div> --000000000000b91a1d0590d143e0-- From nobody Mon Aug 26 00:04:40 2019 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C9E1200A4 for <netmod@ietfa.amsl.com>; Mon, 26 Aug 2019 00:04:38 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3c2UGyxT7lP for <netmod@ietfa.amsl.com>; Mon, 26 Aug 2019 00:04:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE16D120019 for <netmod@ietf.org>; Mon, 26 Aug 2019 00:04:35 -0700 (PDT) Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id AF0D21AE0187; Mon, 26 Aug 2019 09:04:31 +0200 (CEST) Date: Mon, 26 Aug 2019 09:04:08 +0200 (CEST) Message-Id: <20190826.090408.243319791214325843.mbj@tail-f.com> To: rwilton@cisco.com Cc: vladimir@transpacket.com, netmod@ietf.org From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <MN2PR11MB4366DA593D42209D7F44C8EFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> References: <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> <20190822.133449.502914144686905879.mbj@tail-f.com> <MN2PR11MB4366DA593D42209D7F44C8EFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_Kyql57qfBQo4wo1wBweV-NLdw4> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Aug 2019 07:04:38 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBN YXJ0aW4sDQo+IA0KPiBQbGVhc2Ugc2VlIGNvbW1lbnRzIGlubGluZSAuLi4NCj4gDQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA dGFpbC1mLmNvbT4NCj4gPiBTZW50OiAyMiBBdWd1c3QgMjAxOSAxMjozNQ0KPiA+IFRvOiBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4gQ2M6IHZsYWRpbWlyQHRy YW5zcGFja2V0LmNvbTsgbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNw0KPiA+IA0K PiA+IEhpLA0KPiA+IA0KPiA+IFNvbWUgY29tbWVudHMgaW5saW5lLg0KPiA+IA0KPiA+IA0KPiA+ ICJSb2IgV2lsdG9uIChyd2lsdG9uKSIgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ IEhpIFZsYWRpbWlyLA0KPiA+ID4NCj4gPiA+IFRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZp ZXcuICBTb3JyeSBmb3IgdGhlIHNsb3cgcmVwbHksIEkndmUgYmVlbg0KPiA+ID4gYXdheS4gIEkn bSBhbHNvIGFib3V0IHRvIGJlIGF3YXkgYWdhaW4gZm9yIGEgY291cGxlIG9mIGRheXMuDQo+ID4g Pg0KPiA+ID4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUgLi4uDQo+ID4gPg0KPiA+ID4g SSdsbCBhbHNvIHRyYWNrIHRoZXNlIGlzc3VlcyB0byBjbG9zdXJlIG9uDQo+ID4gPiBodHRwczov L2dpdGh1Yi5jb20vbmV0bW9kLXdnL2ludGVyZmFjZS1leHRlbnNpb25zLXlhbmcvaXNzdWVzDQo+ ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBu ZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVmxhZGltaXINCj4g PiA+ID4gVmFzc2lsZXYNCj4gPiA+ID4gU2VudDogMTMgQXVndXN0IDIwMTkgMTc6MDUNCj4gPiA+ ID4gVG86IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IG5ldG1vZEBpZXRmLm9y Zw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsOg0KPiA+ID4gPiBk cmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTA3DQo+ID4gPiA+DQo+ID4gPiA+IEkgaGF2 ZSByZXZpZXdlZCB0aGUgZHJhZnQuIEkgaGF2ZSB0aGUgZm9sbG93aW5nICgxOSkgSU1PIHVzZWZ1 bA0KPiA+ID4gPiBwcm9wb3NhbHM6DQo+ID4gPiA+DQo+ID4gPiA+IDEuIERlZGljYXRlZCBtb2R1 bGUgKGlldGYtaWYtb3Blci1zdGF0dXMtZGVib3VuY2UueWFuZykgZm9yIHRoZQ0KPiA+ID4gPiBv cGVyLSBzdGF0dXMgZGVib3VuY2luZy9kYW1wZW5pbmcgZnVuY3Rpb25hbGl0eSBjdXJyZW50bHkg aW4NCj4gPiA+ID4gaWV0Zi1pbnRlcmZhY2VzLQ0KPiA+ID4gPiBjb21tb24ueWFuZy4NCj4gPiA+ DQo+ID4gPiBJIGRvbid0IHRoaW5rIHRoYXQgd2Ugd2FudCBhIHByb2xpZmVyYXRpb24gb2YgdG9v IG1hbnkgc2VwYXJhdGUgWUFORw0KPiA+ID4gbW9kdWxlcyBmb3Igc21hbGwgZmVhdHVyZXMuICBF YWNoIG9mIHRoZSBhcmVhcyBvZiBkaWZmZXJlbnQNCj4gPiA+IGZ1bmN0aW9uYWxpdHkgd2l0aGlu IHRoaXMgbW9kdWxlIGFyZSBhbHJlYWR5IGNvbmRpdGlvbmFsIG9uDQo+ID4gPiBpZi1mZWF0dXJl LCBzbyBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBzdHJvbmcganVzdGlmaWNhdGlvbiB0 bw0KPiA+ID4gc2VwYXJhdGluZyB0aGlzIG91dCBhcyBhIHNlcGFyYXRlIG1vZHVsZS4NCj4gPiAN Cj4gPiBJIGFncmVlLg0KPiA+IA0KPiA+ID4gPiA0LiBEZWRpY2F0ZWQgbW9kdWxlIChpZXRmLWlm LWxvb3BiYWNrLnlhbmcpIGZvciB0aGUgbG9vcGJhY2sNCj4gPiA+ID4gZnVuY3Rpb25hbGl0eSBj dXJyZW50bHkgaW4gaWV0Zi1pbnRlcmZhY2VzLWNvbW1vbi55YW5nLg0KPiA+ID4NCj4gPiA+IFNh bWUgYW5zd2VyIGFzIGZvciAxLiBJIGRvbid0IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGhhdmUgdG9v IG1hbnkNCj4gPiA+IHJlYWxseSBzbWFsbCBtb2R1bGVzLg0KPiA+IA0KPiA+IEkgYWdyZWUuDQo+ ID4gDQo+ID4gDQo+ID4gPiA+IDEwLiBJbnRyb2R1Y2luZyBjb25maWcgdHJ1ZSAiZm9yd2FyZGlu Zy1tb2RlIiBsZWFmIGJyZWFrcyBjbGllbnRzDQo+ID4gPiA+IHRoYXQgc3VwcG9ydCBlLmcuIHJm YzgzNDQgaWV0Zi1pcCAod2hpY2ggaGFzIGl0cyBkZWRpY2F0ZWQNCj4gPiA+ID4gZm9yd2FyZGlu ZyBsZWFmcyBlLmcuDQo+ID4gPiA+IC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pbnRlcmZh Y2UvaWV0Zi1pcDppcHY0L2ZvcndhcmRpbmcgKSBieQ0KPiA+ID4gPiBpbnRyb2R1Y2luZyB0aGlz IG5ldyBtb2R1bGUgd2l0aCBhIG5ldyBsZWFmIHRoZXkga25vdyBub3RoaW5nIGFib3V0Lg0KPiA+ ID4gPiBJIHN1cHBvcnQgdGhpcyBsZWFmIGFzIGNvbmZpZyBmYWxzZS4gSWYgTkVUQ09ORiB3YXMg bm90DQo+ID4gPiA+IHRyYW5zYWN0aW9uYWwgYSBnbG9iYWwgbGVhZiBlbmFibGluZyB0aGUgZm9y d2FyZGluZyBjb25maWd1cmF0aW9uDQo+ID4gPiA+IHdvdWxkIGJlIGEgZmVhdHVyZS4NCj4gPiA+ ID4gQnV0IE5FVENPTkYgaXMgdHJhbnNhY3Rpb25hbC4NCj4gPiA+DQo+ID4gPiBJIGRvbid0IGdl dCB0aGUgcmVsZXZhbmNlIG9mIHRyYW5zYWN0aW9ucw0KDQpOZWl0aGVyIGRvIEkuDQoNCg0KPiA+ ID4gLCBidXQgaXQgaXNuJ3QgaW50ZW5kZWQgdG8NCj4gPiA+IGJyZWFrIGV4aXN0aW5nIGNsaWVu dHMvWUFORyBtb2R1bGVzLg0KPiA+ID4NCj4gPiA+IFRoZSBpZGVhIG9mIHRoaXMgbGVhZiBpcyB0 aGF0IGlmIGl0IGlzIGNvbmZpZ3VyZWQgdGhlbiB0aGUgc3lzdGVtIGNhbg0KPiA+ID4gdXNlIGl0 IHRvIGNoZWNrIG90aGVyIGNvbnN0cmFpbnRzLiAgRS5nLiB0byB2YWxpZGF0ZSB0aGF0IGFuIEwy IFFvUw0KPiA+ID4gcG9saWN5IGlzbuKAmXQgYmVpbmcgY29uZmlndXJlZCBvbiBhbiBMMyBpbnRl cmZhY2UuICBJZiB0aGUgbGVhZiBpc24ndA0KPiA+ID4gY29uZmlndXJlZCB0aGVuIHRob3NlIGNv bnN0cmFpbnRzIGFyZSBub3QgY2hlY2tlZC4NCj4gPiANCj4gPiBIbW0uICBBcmUgeW91IHNheWlu ZyB0aGF0IHRoaXMgbGVhZiBkb2Vzbid0IGhhdmUgYW55IGRpcmVjdCBlZmZlY3QgaW4NCj4gPiB0 aGUNCj4gPiBzZXJ2ZXI/DQo+IA0KPiBJdCBkZXBlbmRzIG9uIHRoZSBkZXZpY2UuICBTb21lIGRl dmljZXMgcmVxdWlyZSBhIGxlYWYgbGlrZSB0aGlzIChvcg0KPiBzaW1pbGFyKSB0byBjb3JyZWN0 bHkgcHJvdmlzaW9uIHRoZSBzZXJ2aWNlcy4gIE90aGVyIGRldmljZXMgZG9uJ3QNCj4gbmVlZCBp dC4NCg0KSG1tLCBpcyB0aGlzIHJlYWxseSBhIHByb3BlcnR5IG9mIHRoZSBkZXZpY2UgaW1wbGVt ZW50YXRpb24/ICBJc24ndCBpdA0KYSBwcm9wZXJ0eSBvZiB0aGUgZGF0YSBtb2RlbHMgdGhhdCBk ZXNjcmliZSB0aGVzZSBzZXJ2aWNlcz8NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgc2VtYW50 aWNzIG9mIHRoaXMgbGVhZiBpcyBhIGJpdCB1bmNsZWFyLA0KZXNwLiBpZiB3ZSBsb29rIGF0IHRo ZSBzdWItaW50Zi12bGFuIG1vZGVsIHdoaWNoIHVzZXMgdGhpcyBsZWFmOg0KDQogICAgY29udGFp bmVyIGRvdDFxLXZsYW4gew0KICAgICAgbXVzdA0KICAgICAgICAnY291bnQoLi4vLi4vaWYtY21u OmZvcndhcmRpbmctbW9kZSkgPSAwIG9yICcgKw0KICAgICAgICAnZGVyaXZlZC1mcm9tLW9yLXNl bGYoLi4vLi4vaWYtY21uOmZvcndhcmRpbmctbW9kZSwnICsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICciaWYtY21uOmxheWVyLTMtZm9yd2FyZGluZyIpJyANCg0KDQpUaGlzIG1lYW5z IHRoYXQgaXQgaXMgcGVyZmVjdGx5IG9rIGZvciBhIGNsaWVudCB0byBjb25maWd1cmUNCiJkb3Qx cS12bGFuIiB3aXRob3V0IGFsc28gc2V0dGluZyBmb3J3YXJkaW5nLW1vZGUuDQoNCg0KDQo+ID4g PiA+IDE5LiBpZXRmLWlmLWNvbW1vbi55YW5nIGFuZCBpZXRmLWlmLWV0aGVybmV0LWxpa2UueWFu ZyBpbnN0ZWFkIG9mDQo+ID4gPiA+IGlldGYtDQo+ID4gPiA+IGludGVyZmFjZXMtY29tbW9uLnlh bmcgYW5kIGlldGYtaW50ZXJmYWNlcy1ldGhlcm5ldC1saWtlLnlhbmcuDQo+ID4gPiA+IFNldHRp bmcgYSBzaG9ydGVyIG5hbWluZyBwcmVjZWRlbnQgZm9yIGZ1dHVyZSBtb2R1bGVzIGF1Z21lbnRp bmcNCj4gPiA+ID4gaWV0Zi0gaW50ZXJmYWNlcy4NCj4gPiA+DQo+ID4gPiBJJ20gbm90IG9wcG9z ZWQgdG8gc2hvcnRlciBuYW1lcywgYnV0IHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gdGhlIHZpZXdz DQo+ID4gPiBvZiBvdGhlcnMgaW4gdGhlIFdHLg0KPiA+IA0KPiA+IEkgaGFkIGEgc2ltaWxhciBj b25jZXJuIGZvciB0aGUgbW9kdWxlcyBpbiB0aGUgc3ViLWludGYtdmxhbiBkcmFmdCAoSQ0KPiA+ IHdpbGwNCj4gPiBwb3N0IG15IHJldmlldyBvZiB0aGF0IGRvYyBsYXRlcikuDQo+ID4gDQo+ID4g Q3VycmVudGx5IHdlIGhhdmU6DQo+ID4gDQo+ID4gICBpZXRmLWludGVyZmFjZXMtY29tbW9uDQo+ ID4gICBpZXRmLWludGVyZmFjZXMtZXRoZXJuZXQtbGlrZQ0KPiA+ICAgaWV0Zi1pZi1sMy12bGFu DQo+ID4gICBpZXRmLWZsZXhpYmxlLWVuY2Fwc3VsYXRpb24NCj4gPiANCj4gPiBJIHRoaW5rIHdl IHNob3VsZCBoYXZlIGNvbnNpc3RlbmN5LCBlaXRoZXI6DQo+ID4gDQo+ID4gICBpZXRmLWludGVy ZmFjZXMtY29tbW9uDQo+ID4gICBpZXRmLWludGVyZmFjZXMtZXRoZXJuZXQtbGlrZQ0KPiA+ICAg aWV0Zi1pbnRlcmZhY2VzLWwzLXZsYW4NCj4gPiAgIGlldGYtaW50ZXJmYWNlcy1mbGV4aWJsZS1l bmNhcHN1bGF0aW9uDQo+ID4gDQo+ID4gb3INCj4gPiANCj4gPiAgIGlldGYtaWYtY29tbW9uDQo+ ID4gICBpZXRmLWlmLWV0aGVybmV0LWxpa2UNCj4gPiAgIGlldGYtaWYtbDMtdmxhbg0KPiA+ICAg aWV0Zi1pZi1mbGV4aWJsZS1lbmNhcHN1bGF0aW9uDQo+ID4gDQo+IA0KPiBJIHByZWZlciB0aGUg c2hvcnRlciBuYW1lcyBwZXJzb25hbGx5Lg0KDQpPay4NCg0KDQovbWFydGluDQoNCg0KPiANCj4g VGhhbmtzLA0KPiBSb2INCj4gDQo+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiANCj4g PiA+DQo+ID4gPiBUaGFua3MgYWdhaW4gZm9yIHRoZSByZXZpZXcuICBJdCBpcyBhcHByZWNpYXRl ZC4NCj4gPiA+DQo+ID4gPiBSb2INCj4gPiA+DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAvVmxh ZGltaXINCj4gPiA+ID4NCj4gPiA+ID4gT24gMTAvMDcvMjAxOSAwMi4xNSwgS2VudCBXYXRzZW4g d3JvdGU6DQo+ID4gPiA+ID4gQWxsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBzdGFydHMg YSB0d2VsdmUtZGF5IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvcg0KPiA+ID4gPiA+IGRyYWZ0 LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmctMDcNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEp1bHkgMjEgKHRoZSBkYXkgYmVmb3JlIHRo ZQ0KPiA+ID4gPiA+IE5FVE1PRA0KPiA+ID4gPiAxMDUgc2Vzc2lvbnMpLiAgUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGUgd29ya2luZyBncm91cA0KPiA+ID4gPiBtYWlsaW5nIGxpc3Qu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZQ0KPiA+ID4gPiA+IGl0IGlzDQo+ID4gPiA+ IHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lISAgVGhpcyBpcyB1c2VmdWwgYW5k IGltcG9ydGFudCwNCj4gPiA+ID4gZXZlbiBmcm9tIGF1dGhvcnMuDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBUaGFuayB5b3UsDQo+ID4gPiA+ID4gTkVUTU9EIENoYWlycw0KPiA+ID4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPiA+DQo+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Mon Aug 26 04:37:41 2019 Return-Path: <noreply@ietf.org> X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B82120041; Mon, 26 Aug 2019 04:37:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org> To: "The IESG" <iesg@ietf.org> Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com> Message-ID: <156681945152.25367.12793164355343396320.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2019 04:37:31 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/67-wrGLWhLOGO0VWFdasY-bm8Jw> Subject: [netmod] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-netmod-artwork-folding-08=3A_=28with_COMMENT=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 26 Aug 2019 11:37:32 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-netmod-artwork-folding-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sometimes a small problem (like line folding) can be annoying... so thank you for authoring this document. Just a minor comment: - should 'pyang' and 'yanglint' be added to the references ? -éric From nobody Tue Aug 27 07:54:56 2019 Return-Path: <vladimir@transpacket.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00DB1200C7 for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woXVEGYeIarH for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 07:54:47 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F030120098 for <netmod@ietf.org>; Tue, 27 Aug 2019 07:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E365B4803A9F; Tue, 27 Aug 2019 16:54:44 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0InKAwyGqNSN; Tue, 27 Aug 2019 16:54:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id BA3DC4803AA0; Tue, 27 Aug 2019 16:54:44 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZOQ3ZKZ8nI9N; Tue, 27 Aug 2019 16:54:44 +0200 (CEST) Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id 8E8004803A9A; Tue, 27 Aug 2019 16:54:44 +0200 (CEST) To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> From: Vladimir Vassilev <vladimir@transpacket.com> Message-ID: <783a4e9b-397d-c34e-dd18-2c350d8181e1@transpacket.com> Date: Tue, 27 Aug 2019 16:54:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pcLflQNGHFoYpL0bM0Vm2a3vct4> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Aug 2019 14:54:50 -0000 On 22/08/2019 12.13, Rob Wilton (rwilton) wrote: > Hi Vladimir, > > Thanks for your detailed review. Sorry for the slow reply, I've been a= way. I'm also about to be away again for a couple of days. > > Please see my comments inline ... > > I'll also track these issues to closure on https://github.com/netmod-wg= /interface-extensions-yang/issues > >> -----Original Message----- >> From: netmod <netmod-bounces@ietf.org> On Behalf Of Vladimir Vassilev >> Sent: 13 August 2019 17:05 >> To: Kent Watsen <kent+ietf@watsen.net>; netmod@ietf.org >> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 >> >> I have reviewed the draft. I have the following (19) IMO useful propos= als: >> >> 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the oper- >> status debouncing/dampening functionality currently in ietf-interfaces= - >> common.yang. > I don't think that we want a proliferation of too many separate YANG mo= dules for small features. Each of the areas of different functionality w= ithin this module are already conditional on if-feature, so I don't think= that there is a strong justification to separating this out as a separat= e module. I still think that especially the "dampening" mechanism is not common=20 enough and is quite complex to be added to ietf-interfaces-common. If a=20 feature is not common or does not enable the use of generic modeling=20 mechanism (like sub-interfaces etc.) it should not be in=20 ietf-interfaces-common. I do not think "dampening" (maybe at some point=20 we should go back to damping instead e.g. rfc2439 ... seems there is=20 difference between dampening and damping and damping seems to be the=20 correct one) is that common to deserve a place in ietf-interfaces-common. > >> 2. In sec "3.1 Carrier delay" use of the under-defined "Carrier" >> definition can be replaced with direct reference to the oper-status le= af >> (which is what is actually targeted by the algorithm) "Operational sta= tus >> transition debouncing". > I think that different vendors have different names for this technology= . I've just used the one that our products use. I think that this is ju= st a name, rather than something that has to be defined. I could add a c= omment that this feature is sometimes called hold time? I looked for precedents -=C2=A0 "carrier-delay" leaf Cisco,=20 "debouncing-interval" leaf Juniper, "interface-phys-holdtime-config"=20 leaf OpenConfig. I think "Carrier" is confusing since what is delayed actually is the=20 transition of the oper-status. >> 3. "timer-running" and "suppressed" leafs are both "config false" and = have >> "default" statements. Although this is valid YANG I do not think the >> "default" statements are intended. > I think that this is a more general question that needs a bit more disc= ussion. Here, I am using defaults for the config false node to document = what the normal value is expected. Well not a real issue but I thought it was an unusual use of default. > > >> 4. Dedicated module (ietf-if-loopback.yang) for the loopback functiona= lity >> currently in ietf-interfaces-common.yang. > Same answer as for 1. I don't think that we should have too many really= small modules. If the loopback was modeled as a boolean leaf (as in OpenConfig) I would=20 have agreed. However even small modules that define base identities=20 benefit from dedicated namespace. For me ietf-if-loopback.yang will pay=20 off since loopback=3D'internal' is better then=20 loopback=3D'loopback-internal' and there are going to be many test cases=20 that use that line. An last but not least I never had problems with too=20 much modularity. > >> 5. Less verbose loopback identities. With dedicated module the >> (loopback-* identities can be shortened skipping the prefix). > I think that it is normal to bind the identity names to the common base= identity. I don't see that the length of the identities should really b= e an issue. For me the length of identities does matter since I often use command=20 line tools. But it is mostly the irritation caused by the tautology=20 loopback=3D'loopback-internal' that everyone writing network interconnect= =20 testcases is going to be stuck with forever if we leave the loopback=20 control model as part of ietf-interfaces-common and not separate=20 ietf-if-loopback. What do others think? > >> 6. The draft introduces "loopback-internal", "loopback-line" and >> "loopback-connector" loopback identities. What is confusing is that >> "internal loopback" is historically the opposite of "external loopback= " >> which is a loopback with a connector. I think terminology already in u= se >> like "near-end" and "far-end" is less confusing. > The internal/line loopback configuration has been used in parts of the = industry for at least 20 years, so this terminology is already in use. > > I'm not sure that "near-end" and "far-end" would be less confusing. As= suming that "loopback far-end" was equivalent to "loopback-line" then it = would be somewhat of a misnomer since it acts on the near end, not the fa= r end. > > I.e. both loopback internal, and loopback line act on the local interfa= ce, the only difference is in which direction they reflect the signals, i= .e. Egress -> Ingress (internal), or Ingress -> Egress (line). I can live with local/line/connector but I do not agree=20 near-end/far-end/connector=C2=A0 is more confusing. > > Perhaps the description text could be slightly clarified here to help a= void confusion? > > OLD: > > The following loopback modes are defined: > > o Internal loopback - All egress traffic on the interface is > internally looped back within the interface to be received on th= e > ingress path. > > o Line loopback - All ingress traffic received on the interface is > internally looped back within the interface to the egress path. > > o Loopback Connector - The interface has a physical loopback > connector attached that loops all egress traffic back into the > interface's ingress path, with equivalent semantics to internal > loopback. > > NEW: > > The following loopback modes are defined: > > o Internal loopback - All frames that egress out of the interface > are looped back internally within the interface hardware > to be received on the ingress path. > > o Line loopback - All ingress frames received on the interface fro= m > the line are looped back within the interface hardware and > transmitted back out of the interface. > > o Loopback connector - The interface has a physical loopback > connector attached that loops all egress frames back into the > interface's ingress path, with equivalent semantics to internal > loopback. Adding frames excludes continuous stream (no frame) devices like legacy=20 serial links and high speed transceivers, optical links. Loopback is=20 applicable there too. IMO the OLD text was better. >> 7. I am not sure standardizing the "loopback-connector" identity is >> justified. All usecases of connecting a loopback connector I can think= of >> require the system to not be aware there is special external loopback >> connector on the interface. > I think that it will depend on how smart of dumb the external loopback = connector is. If it is just a dumb electrical or optical loopback then t= he source and destination MAC addresses need to be swapped, or otherwise = any egress frames out of the interface will fail the destination MAC addr= ess filter when they are looped around. OK > > Some implementations also use this configuration to force self ping pac= kets out through the interface, so that the full datapath is tested, rath= er than the packets being looped internally within the L3 forwarding code= . > > >> 8. Some interfaces that implement "loopback-internal" do not implement >> "loopback-line" - e.g. classical ethernetCsmacd (Carrier-sense multipl= e >> access with collision detection) has a physical layer that by design c= an >> not implement such loopback. Maybe introducing a dedicated feature to >> enable the "loopback-line" is a good idea. > I'm not sure on this one, i.e. whether it really helps or just adds ext= ra clutter. > Realistically, I think that ethernetCsmacd is dead. Do you have other = examples of interface types that do support loopback, but not in both dir= ections? All interfaces that are not point-to-point (e.g. common wifi). > This might be something better handled via a deviation, or the device f= ailing the configuration when it is verified. OK > As a side note, one of the limitations of features and deviations is th= at the apply to all interfaces on the device, but the actual properties o= f an interface might vary depending on the speed, type and hardware assoc= iated with the interface. > > >> 9. Appropriate entry in the "11. Security Considerations" noting the >> possibility of DoS attacks and broadcast traffic storms resulting from >> loopbacks: >> >> OLD: >> >> =C2=A0=C2=A0 The following leaf could cause the interface to go down= , and stop >> =C2=A0=C2=A0 processing any ingress or egress traffic on the interfa= ce: >> >> =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback >> >> NEW: >> >> =C2=A0=C2=A0 The following leaf could cause the interface to go down= , and stop >> =C2=A0=C2=A0 processing any ingress or egress traffic on the interfa= ce. It could >> =C2=A0=C2=A0 cause broadcast traffic storms. >> >> =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback >> > Ack. > > > >> 10. Introducing config true "forwarding-mode" leaf breaks clients that >> support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs >> e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) b= y >> introducing this new module with a new leaf they know nothing about. I >> support this leaf as config false. If NETCONF was not transactional a >> global leaf enabling the forwarding configuration would be a feature. >> But NETCONF is transactional. > I don't get the relevance of transactions, but it isn't intended to bre= ak existing clients/YANG modules. > > The idea of this leaf is that if it is configured then the system can u= se it to check other constraints. E.g. to validate that an L2 QoS policy= isn=E2=80=99t being configured on an L3 interface. If the leaf isn't co= nfigured then those constraints are not checked. If this leaf is only enabling optional additional constrains (and this=20 is the only backward compatible option) It won't be that useful as=20 config true. > > >> 11. The "forwarding-mode" leaf has the following set of identities >> {optical-layer, l2-forwarding, network-layer}. We could make the ident= ity >> names shorter and consistent. l1,l2,l3 or physical,data-link,network. > I've tried to use names here that network engineers are most likely to = be familiar with. > > I think that using the OSI layer names (e.g. l1, l2, l3) would be too t= erse. > > We could change "l2-forwarding" to "data-link-layer", but I would think= that people would be more familiar with "l2-forwarding" as a term. E.g.= related to L2VPN. > > >> 12. I do not agree we need this text. Normally NETCONF devices should >> accept transactions to any valid configuration: >> >> OLD: >> =C2=A0=C2=A0 ... >> =C2=A0=C2=A0 Normally devices will not allow the parent-interface le= af to be >> =C2=A0=C2=A0 changed after the interfce has been created.=C2=A0 If a= n implementation >> =C2=A0=C2=A0 did allow the parent-interface leaf to be changed then = it could cause >> =C2=A0=C2=A0 all traffic on the affected interface to be dropped.=C2= =A0 The affected >> =C2=A0=C2=A0 leaf is: >> >> =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface >> =C2=A0=C2=A0 ... >> >> NEW: >> =C2=A0=C2=A0 ... >> =C2=A0=C2=A0 Changing the parent-interface leaf could cause >> =C2=A0=C2=A0 all traffic on the affected interface to be dropped. >> =C2=A0=C2=A0 The affected leaf is: >> >> =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface >> =C2=A0=C2=A0 ... > This isn't about transactions so much as valid configuration. > > Normally, the name of the sub-interface is tightly bound to the parent = interface. E.g. if the parent in "Ethernet0/1" then the sub-interface wo= uld be "Ethernet0/1.1". If you tried to change the parent-interface leaf= of "Ethernet0/1.1" to "Ethernet2/2" then I would expect the system to re= ject that change (because the configuration is invalid not because of tra= nsactions). > > >> 13. The in-drop-unknown-dest-mac-pkts changes the behavior of the in- >> unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not agree a= ny >> discarded packets in the forwarding process should be subtracted from = the >> interface counters. >> >> Here is the current description: >> >> OLD: >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 For consistency, frames counted against this drop >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 counters are also counted against the IETF interfac= es >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 statistics.=C2=A0 In particular, they are included = in >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 in-octets and in-discards, but are not included in >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 in-unicast-pkts, in-multicast-pkts or in-broadcast-= pkts, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 because they are not delivered to a higher layer. >> NEW: >> =C2=A0=C2=A0=C2=A0=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 implementation of this counter does not >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 change the behavior of the counters defined in >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 IETF interfaces statistics. >> > It is not changing the definitions of those counters at all. It is jus= t explaining the relationship between them. The problem I see is that today there are existing systems that=20 implement ietf-interfaces and discard packets because they have unknown=20 MAC destination. But those systems do not subtract the number of=20 discarded packets from the "in-unicast-pkts" counter. Those systems will=20 have to change their behavior in a non-backward compatible way to be=20 able to implement the in-drop-unknown-dest-mac-pkts with this=20 description. In my view this text changes the definition of=20 in-unicast-pkts enforcing certain design that was not enforced before. > > > >> >> 14. I propose the in-pkts and out-pkts counters standardized too. >> https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ie= tf- >> interfaces-ext.yang. >> And yes someone forgot to update the boilerplate text. > This one I think that we need to get further input on. > > https://github.com/YangModels/yang/blob/master/standard/ieee/published/= 802.3/ieee802-ethernet-interface.yang > > defines in-frames and out-frames, but these are only for Ethernet, but = you are probably looking for a counter across all interface types. Yes. in-pkts and out-pkts are used by OpenFlow, OpenDaylight,=20 OpenConfig, Cisco etc. Those are interface independent. It is impossible=20 to implement ietf-interfaces for devices that provide only in-pkts and=20 out-pkts (that would be all OpenFlow switches) which is a good argument=20 to have the counters standardized. > >> 15. I propose that new "ietf-interfaces-common:in-discards-overflow" >> counter is added. Currently the "ietf-interfaces:in-discards" can cont= ain >> both discards like the ones accumulated in in-drop-unknown-dest-mac-pk= ts >> and discards caused by overflows (performance related loss of packets = like >> freeing buffer space in devices that in certain cases are forwarding >> slower then the line speed). Turns out knowing if device is discarding >> (loosing) packets due to performance shortage and discarding (filterin= g) >> unwanted packets are two different events that one needs to differenti= ate >> between are currently in the same in-discards counter. We can fix that >> with the introduction of in-discards-overflow counter. > This one I think that we need to get further input on. I think that th= is might be useful. But we might need some care to ensure that it fits c= leanly with QoS drops. > > If we were to add this then the definition of "ietf-interfaces:in-disca= rds" cannot change. i.e. In-discards-overflow would be a subset of "in-d= iscards". OK > > >> 16. We can replace >> "ietf-interfaces-ethernet-like:in-drop-unknown-dest-mac-pkts" with (in= - >> discards - in-discards-overflow) for MAC Bridges or any other Ethernet >> interface plus save us the introduction of technology specific similar >> counters for the rest of the Bridges and non-Ethernet interfaces. > For Ethernet, having a technology specific in-drop-unknown-dest-mac-pkt= s is useful. > > In the WG discussion, there was agreement to also add a drop counter fo= r packets that are dropped because they cannot be demuxed to any sub-inte= rface. > > Personally, I think that it is useful to have an overall drop counter t= hat captures everything, along with more specific drop counters that some= times give more information as to what has causes specific drops. Specif= ically, just because a more specific drop counter has been defined, that = doesn't mean that it shouldn't also be included in the general drop count= er. IMO the in-discards counter should be incremented in very rare=20 circumstances (e.g. ingress clock frequency above supported) and ideally=20 reserved for reporting performance issues in the MAC that should=20 normally not exist. The "unknown-dest-mac" and "packets that are dropped=20 because they cannot be demuxed to any sub-interface" should be handled=20 at another "sub-layer" and do not need to be subtracted from the=20 ietf-interfaces in-*-pkt counters because this is very confusing. But=20 probably there are systems out there that already use "in-discards" for=20 all sorts of discards. > > >> 17. I have separately posted my arguments against introduction of leaf >> named l2-mtu and the need of a config false leaf that has similar >> semantics as the ifMtu object from IF-MIB. > OK, lets keep this issue on that other thread. OK > > >> 18. Some references to relevant IEEE standards and IEEE maintained YAN= G >> modules should be added (in the scope of ietf-interfaces-ethernet-like= ). >> Also a few lines explaining the policy change and why none of the >> RFC3635 managed objects are part of the new ietf-interfaces-ethernet-l= ike >> YANG module. > Yes, OK. > > >> 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of ietf= - >> interfaces-common.yang and ietf-interfaces-ethernet-like.yang. >> Setting a shorter naming precedent for future modules augmenting ietf- >> interfaces. > I'm not opposed to shorter names, but would be interested in the views = of others in the WG. OK /Vladimir > > Thanks again for the review. It is appreciated. > > Rob > > >> /Vladimir From nobody Tue Aug 27 09:03:53 2019 Return-Path: <ietf.dmytro@shytyi.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5C120823 for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 09:03:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.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 epkNwfah2K70 for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 09:03:49 -0700 (PDT) Received: from sender-of-o52.zoho.eu (sender-of-o52.zoho.eu [31.186.226.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7B6120820 for <netmod@ietf.org>; Tue, 27 Aug 2019 09:03:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566921824; cv=none; d=zohomail.eu; s=zohoarc; b=gQEanlI7fFagjlp0VNZ+cGoe/XeLDyVKxkixykgCV/pl5EXo+eEykP1I1QlcKIohgrp3UggKsWHayBaBvMFt+9Q824fkr3GVXFDZ8wfce0k+7nmj5dB9oicEJEM2TQlR6MND4eMX5j5nHId9fb+nVNeUYaSBJXqpf47rs7bQp8g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1566921824; h=Content-Type:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=gsS9SFEmOzqbQ52BA97K11Toa5pdH+ZQoVZk+8prbJQ=; b=QrbIfLNxrqjjCcLV47Z/uWE4A27aU/lekrg42xQPa+J84lbjGHANlmQF1T585H0nhMA2QHHXoTxe/mjr5rtlHZw14OtgzO3I7p4L83YcZ0C0Xanrd86AP6R/iqhmc2l4T7c9FzraAXO2bF9iKYwNI1aDugcwUkYJDVH2TY+A4ew= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from=<ietf.dmytro@shytyi.net> header.from=<ietf.dmytro@shytyi.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1566921824; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=7503; bh=gsS9SFEmOzqbQ52BA97K11Toa5pdH+ZQoVZk+8prbJQ=; b=ddGtnJCKOoNAhS/Sazr5k3DDPyZHkRgBOfmhKO88Z92p1W3ukfcczeLwm2e/PKTs FzGZytAlSoytc34hqIGP/Hs6wKVbPfna1FLIrtZrPhdfJDIqYIJRrll/sCHIWHKO3eh 8orKLZRiLxD8Sm4cKSUpwC7dr0MpX+t64rMuJWgw= Received: from sender.zoho.eu (172.26.23.78 [172.26.23.78]) by mx.zoho.eu with SMTPS id 1566921823064921.3335827241524; Tue, 27 Aug 2019 18:03:43 +0200 (CEST) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1566921822984548.8837861899998; Tue, 27 Aug 2019 18:03:42 +0200 (CEST) Date: Tue, 27 Aug 2019 18:03:42 +0200 From: Dmytro Shytyi <ietf.dmytro@shytyi.net> To: "netmod" <netmod@ietf.org> Message-Id: <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> In-Reply-To: <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> References: <155377227553.1573.8548464832229347361.idtracker@ietfa.amsl.com> <16caabd07ae.de4789c8151923.6368018099125205208@shytyi.net> <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_990334_1685904034.1566921822981" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/oCetiXzDYa88yBP-Lj0zBJlGrFE> Subject: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Aug 2019 16:03:52 -0000 ------=_Part_990334_1685904034.1566921822981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I am one of the authors of ID VYSM and I would like to draw your attention = to the evolution of the draft=C2=A0https://www.ietf.org/internet-drafts/dra= ft-shytyi-netmod-vysm-01.txt. Recently we produced (but did not submitted yet) a new version of ID (02) a= nd I beleive it fits the netmod working group. We would be gratefull if you could suggest if the new version(02) of the do= cument=C2=A0 could become an official work item of the WG? =C2=A0 =C2=A0 =C2=A0 If yes, could you please indicate which modifications = must be done in the document before submition. After reading the=C2=A0https://tools.ietf.org/html/rfc2026=C2=A0it seems th= e document may fit multiple different "Intended statuses".=C2=A0Currentry i= t has "Informational" intended status. Could you please express your sugges= tion: which intended status is more appropriate for the current document? S= hoult it be Experimental or BCP? Thank you for your time. Best Regards, ______________ Dmytro SHYTYI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded message =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From: <mailto:internet-drafts@ietf.org> To: "Dmytro Shytyi"<mailto:ietf.dmytro@shytyi.net> Date: Thu, 28 Mar 2019 12:24:35 +0100 Subject: New Version Notification for draft-shytyi-netmod-vysm-01.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded message =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A new version of I-D, draft-shytyi-netmod-vysm-01.txt=20 has been successfully submitted by Dmytro Shytyi and posted to the=20 IETF repository.=20 =20 Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-shytyi-netmod-vy= sm=20 Revision:=C2=A0=C2=A0=C2=A0=C2=A001=20 Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Virtualization YANG S= ervise Model (VYSM)=20 Document date:=C2=A0=C2=A0=C2=A0=C2=A02019-03-27=20 Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Individual Submission= =20 Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A09=20 URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt= =20 Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/=20 Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-01=20 Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm=20 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-shytyi-netmod-vysm-01=20 =20 Abstract:=20 This document provides a specification of the Virtual Network=20 Functions YANG Service Model (VYSM). The VNF YANG Service Model=20 serves as a base framework for managing an universal Customer-=20 Premises Equipment (uCPE) NFV subsystem from the Orchestrator. ------=_Part_990334_1685904034.1566921822981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>= <meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h= ead><body ><div style=3D"font-family: Verdana, Arial, Helvetica, sans-serif= ; font-size: 10pt;"><div style=3D"" class=3D"zmail_extra"><div><div style= =3D"font-family: Verdana, Arial, Helvetica, sans-serif;font-size: 10.0pt;">= <div>Dear All,<br></div><div><br></div><div>I am one of the authors of ID V= YSM and I would like to draw your attention to the evolution of the draft&n= bsp;<a href=3D"https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vys= m-01.txt" target=3D"_blank">https://www.ietf.org/internet-drafts/draft-shyt= yi-netmod-vysm-01.txt</a>.<br></div><div>Recently we produced (but did not = submitted yet) a new version of ID (02) and I beleive it fits the netmod wo= rking group.<br></div><div><br></div><div>We would be gratefull if you coul= d suggest if the new version(02) of the document  could become an offi= cial work item of the WG?<br></div><div>      If yes, could = you please indicate which modifications must be done in the document before= submition.<br></div><div><br></div><div>After reading the <a href=3D"= https://tools.ietf.org/html/rfc2026" target=3D"_blank">https://tools.ietf.o= rg/html/rfc2026</a> it seems the document may fit multiple different "= Intended statuses". Currentry it has "Informational" intended status. = Could you please express your suggestion: which intended status is more app= ropriate for the current document? Shoult it be Experimental or BCP?<br></d= iv><div><br></div><div>Thank you for your time.<br></div><div><br></div><di= v>Best Regards,<br></div><div id=3D""><div>______________<br><b>Dmytro SHYT= YI</b></div><div><br></div><div><br></div></div><div><br></div><div class= =3D"x_-1728004881zmail_extra"><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Forwarded message =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>From= : <<a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">intern= et-drafts@ietf.org</a>><br>To: "Dmytro Shytyi"<<a href=3D"mailto:ietf= .dmytro@shytyi.net" target=3D"_blank">ietf.dmytro@shytyi.net</a>><br>Dat= e: Thu, 28 Mar 2019 12:24:35 +0100<br>Subject: New Version Notification for= draft-shytyi-netmod-vysm-01.txt<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fo= rwarded message =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></div></div></div><div><b= r></div></div><blockquote style=3D"border-left: 1.0px solid rgb(204,204,204= );padding-left: 6.0px;margin: 0.0px 0.0px 0.0px 5.0px;"><div><br>A new vers= ion of I-D, draft-shytyi-netmod-vysm-01.txt <br>has been successfully submi= tted by Dmytro Shytyi and posted to the <br>IETF repository. <br> <br>Name:=         draft-shytyi-netmod-vysm <b= r>Revision:    01 <br>Title:    &nb= sp;   Virtualization YANG Servise Model (VYSM) <br>Document = date:    2019-03-27 <br>Group:    &= nbsp;   Individual Submission <br>Pages:   &n= bsp;    9 <br>URL: <a target=3D"_blank" href=3D"https:/= /www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt">https://www.= ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt</a> <br>Status: <a= target=3D"_blank" href=3D"https://datatracker.ietf.org/doc/draft-shytyi-ne= tmod-vysm/">https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/</a> = <br>Htmlized: <a target=3D"_blank" href=3D"https://tools.ietf.org/html/draf= t-shytyi-netmod-vysm-01">https://tools.ietf.org/html/draft-shytyi-netmod-vy= sm-01</a> <br>Htmlized: <a target=3D"_blank" href=3D"https://datatracker.ie= tf.org/doc/html/draft-shytyi-netmod-vysm">https://datatracker.ietf.org/doc/= html/draft-shytyi-netmod-vysm</a> <br>Diff: <a target=3D"_blank" href=3D"ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-shytyi-netmod-vysm-01">https://www.= ietf.org/rfcdiff?url2=3Ddraft-shytyi-netmod-vysm-01</a> <br> <br>Abstract: = <br> This document provides a specification of the Virtual Network <br> Fun= ctions YANG Service Model (VYSM). The VNF YANG Service Model <br> serves a= s a base framework for managing an universal Customer- <br> Premises Equipm= ent (uCPE) NFV subsystem from the Orchestrator. <br></div></blockquote></di= v><div><br></div></div><br></body></html> ------=_Part_990334_1685904034.1566921822981-- From nobody Tue Aug 27 16:44:13 2019 Return-Path: <nite@hq.sk> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8C120044 for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 16:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk 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 NO_j0VurfFvY for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 16:44:09 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E1C120013 for <netmod@ietf.org>; Tue, 27 Aug 2019 16:44:08 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id DDC3F241FD4; Wed, 28 Aug 2019 01:44:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1566949445; bh=HfjF8PfTppZ9gXPK5GgJzXkVHIpl8qq4ei3acy842X0=; h=Subject:To:References:From:Date:In-Reply-To; b=eCQ+/v9h2OJBODezdo4CnQxAaUazGR7mxVTmCkl37koOBHuoyvCfPiLlr+KWq44ZT ieYPhNAaRwr6TDY4T3S1Nq5aAGEIWROU3BJSSzrjg5KtSQ1O06BQCXLIIik8z7Lk6l 9upMMrYbN1loVT9x/gMM1uY/Ps2uwD8DhIlmb92A= To: Dmytro Shytyi <ietf.dmytro@shytyi.net>, netmod <netmod@ietf.org> References: <155377227553.1573.8548464832229347361.idtracker@ietfa.amsl.com> <16caabd07ae.de4789c8151923.6368018099125205208@shytyi.net> <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> From: Robert Varga <nite@hq.sk> Openpgp: preference=signencrypt Message-ID: <5219ac80-b607-b4b4-8c77-72950d4c5137@hq.sk> Date: Wed, 28 Aug 2019 01:44:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ccF1IvsLWmLDVhTDFVTzyGGpyii9Ptbuc" Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/80ej2GI_AD__-oknr7IlTCSfHao> Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Aug 2019 23:44:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ccF1IvsLWmLDVhTDFVTzyGGpyii9Ptbuc Content-Type: multipart/mixed; boundary="E7wQK5mXBK86ZeiisO2PCMO57HubHKLPe"; protected-headers="v1" From: Robert Varga <nite@hq.sk> To: Dmytro Shytyi <ietf.dmytro@shytyi.net>, netmod <netmod@ietf.org> Message-ID: <5219ac80-b607-b4b4-8c77-72950d4c5137@hq.sk> Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. References: <155377227553.1573.8548464832229347361.idtracker@ietfa.amsl.com> <16caabd07ae.de4789c8151923.6368018099125205208@shytyi.net> <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> In-Reply-To: <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> --E7wQK5mXBK86ZeiisO2PCMO57HubHKLPe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 27/08/2019 18:03, Dmytro Shytyi wrote: > Dear All, >=20 > I am one of the authors of ID VYSM and I would like to draw your > attention to the evolution of the > draft=C2=A0https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vys= m-01.txt. > Recently we produced (but did not submitted yet) a new version of ID > (02) and I beleive it fits the netmod working group. >=20 > We would be gratefull if you could suggest if the new version(02) of th= e > document=C2=A0 could become an official work item of the WG? > =C2=A0 =C2=A0 =C2=A0 If yes, could you please indicate which modificati= ons must be done > in the document before submition. Hmm, looking over the model, it would seem there is quite a bit of overlap with RFC8345 -- to the point I believe the model could be formulated in terms of RFC8345 specialization: virtualization -> networks/network device/links/interfaces/switches/vms are probably a mix of node/termmination-point/link extensions with conjunction with supporting-{topology,node,link}. How would the draft relate to RFC8345? Should it perhaps call out it is a different take on the similar problem, specialized to a particular use-case? Regards, Robert (with RFC8345 co-author hat on) --E7wQK5mXBK86ZeiisO2PCMO57HubHKLPe-- --ccF1IvsLWmLDVhTDFVTzyGGpyii9Ptbuc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAl1lwEULHG5pdGVAaHEu c2sACgkQJKB0S2uuNdvx7g//daGBcrOzSryMi8j/o30QlHKg2VwkU8uD1C57dLGX CFz/3cI1avO0NcskQ4otJX39/acANCNjfMqlKHt2L3dOl1L54cF+eIJn9DlRzAuo 6VaCPHsEtgHUtVk/m4QIF+qzONowa4A3B7W+jHyqpY9yXgqH3lVoz9jqSSdbiE8s gpJyCHprOX3j1M4/maO2imG6tTXnTCB+JWJbheiZA4y6P4TxLa0XyCvgIEFv2FcI EvRYFQ3ntK1jDPLLXKWd0FAmJpFnxWrBbVicwX33tinFh9/8F37vFYOE/HCiWlLB P3wfch+8Sc4L7rRtFM3t3VfFRjjljzOuqt9fBHg2v3AIz0FFKD/SyuaeqATRpzDe A2f8tKprtntdrciAFwd2W4VylGANY10e3HxL12FKBVtm+vCSP/dya8qxWgPSYegR 07BCCizgSBj6WPBtXvH16ye/+zIIwRsDr8SHk40bsCeLv1jhqcxskgUTEH09JEMT CodFR8aHJqFjs15XRgVQ7szo3ZHC4NmKf/dw2+QIc+Ij2BgkK7GauTCd2glfU2nx josPQzO7GH2oP2QEeOb/HHE0McZ3Cp/cJG1cb4tmPUA3tv5zrr8reUeKs0w0TIqV mNW1GhMuMje/E/UqzTh9XeefSXUyF4aF/hUaIvSdFwrPYtf4afx3oEOQVQiQvC71 vbk= =6EKS -----END PGP SIGNATURE----- --ccF1IvsLWmLDVhTDFVTzyGGpyii9Ptbuc-- From nobody Tue Aug 27 18:12:54 2019 Return-Path: <bill.wu@huawei.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F712081D for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 18:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEwNVmXpT-bz for <netmod@ietfa.amsl.com>; Tue, 27 Aug 2019 18:12:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E697120816 for <netmod@ietf.org>; Tue, 27 Aug 2019 18:12:50 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1479D5C405D184086845 for <netmod@ietf.org>; Wed, 28 Aug 2019 02:12:48 +0100 (IST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 28 Aug 2019 02:12:47 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.9]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Wed, 28 Aug 2019 09:12:41 +0800 From: Qin Wu <bill.wu@huawei.com> To: Robert Varga <nite@hq.sk>, Dmytro Shytyi <ietf.dmytro@shytyi.net>, netmod <netmod@ietf.org> Thread-Topic: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. Thread-Index: AdVdPV/8T7gox5PfSzOuFAPYBpWldA== Date: Wed, 28 Aug 2019 01:12:40 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABAA92B372E@dggeml511-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9F4muFiM4aoP3eZyNugu5nYh1Aw> Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Aug 2019 01:12:52 -0000 KzEsIGluIGFkZGl0aW9uLCBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHRoaXMgaXMgc29tZXRoaW5n IHJlbGF0ZWQgdG8gb3ZlcmxheSB0b3BvbG9neSBtb2RlbCwgaWYgeWVzLCBob3cgaXQgaXMgZGlm ZmVyZW50IGZyb20gREMgRmFicmljIHRvcG9sb2d5IG1vZGVsIGRlZmluZWQgaW4gUkZDODU0Mj8N Cg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFJvYmVydCBWYXJnYQ0K5Y+R6YCB5pe2 6Ze0OiAyMDE55bm0OOaciDI45pelIDc6NDQNCuaUtuS7tuS6ujogRG15dHJvIFNoeXR5aSA8aWV0 Zi5kbXl0cm9Ac2h5dHlpLm5ldD47IG5ldG1vZCA8bmV0bW9kQGlldGYub3JnPg0K5Li76aKYOiBS ZTogW25ldG1vZF0gTmV3IFZlcnNpb24gZHJhZnQtc2h5dHlpLW5ldG1vZC12eXNtLTAyLnR4dCBh cyBXb3JraW5nIEdyb3VwIGRvY3VtZW50Lg0KDQpPbiAyNy8wOC8yMDE5IDE4OjAzLCBEbXl0cm8g U2h5dHlpIHdyb3RlOg0KPiBEZWFyIEFsbCwNCj4gDQo+IEkgYW0gb25lIG9mIHRoZSBhdXRob3Jz IG9mIElEIFZZU00gYW5kIEkgd291bGQgbGlrZSB0byBkcmF3IHlvdXIgDQo+IGF0dGVudGlvbiB0 byB0aGUgZXZvbHV0aW9uIG9mIHRoZSBkcmFmdMKgDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1zaHl0eWktbmV0bW9kLXZ5c20tMDEudHh0Lg0KPiBSZWNlbnRs eSB3ZSBwcm9kdWNlZCAoYnV0IGRpZCBub3Qgc3VibWl0dGVkIHlldCkgYSBuZXcgdmVyc2lvbiBv ZiBJRA0KPiAoMDIpIGFuZCBJIGJlbGVpdmUgaXQgZml0cyB0aGUgbmV0bW9kIHdvcmtpbmcgZ3Jv dXAuDQo+IA0KPiBXZSB3b3VsZCBiZSBncmF0ZWZ1bGwgaWYgeW91IGNvdWxkIHN1Z2dlc3QgaWYg dGhlIG5ldyB2ZXJzaW9uKDAyKSBvZiANCj4gdGhlIGRvY3VtZW50wqAgY291bGQgYmVjb21lIGFu IG9mZmljaWFsIHdvcmsgaXRlbSBvZiB0aGUgV0c/DQo+IMKgIMKgIMKgIElmIHllcywgY291bGQg eW91IHBsZWFzZSBpbmRpY2F0ZSB3aGljaCBtb2RpZmljYXRpb25zIG11c3QgYmUgDQo+IGRvbmUg aW4gdGhlIGRvY3VtZW50IGJlZm9yZSBzdWJtaXRpb24uDQoNCkhtbSwgbG9va2luZyBvdmVyIHRo ZSBtb2RlbCwgaXQgd291bGQgc2VlbSB0aGVyZSBpcyBxdWl0ZSBhIGJpdCBvZiBvdmVybGFwIHdp dGggUkZDODM0NSAtLSB0byB0aGUgcG9pbnQgSSBiZWxpZXZlIHRoZSBtb2RlbCBjb3VsZCBiZSBm b3JtdWxhdGVkIGluIHRlcm1zIG9mIFJGQzgzNDUgc3BlY2lhbGl6YXRpb246DQoNCnZpcnR1YWxp emF0aW9uIC0+IG5ldHdvcmtzL25ldHdvcmsNCg0KZGV2aWNlL2xpbmtzL2ludGVyZmFjZXMvc3dp dGNoZXMvdm1zIGFyZSBwcm9iYWJseSBhIG1peCBvZiBub2RlL3Rlcm1taW5hdGlvbi1wb2ludC9s aW5rIGV4dGVuc2lvbnMgd2l0aCBjb25qdW5jdGlvbiB3aXRoIHN1cHBvcnRpbmcte3RvcG9sb2d5 LG5vZGUsbGlua30uDQoNCkhvdyB3b3VsZCB0aGUgZHJhZnQgcmVsYXRlIHRvIFJGQzgzNDU/IFNo b3VsZCBpdCBwZXJoYXBzIGNhbGwgb3V0IGl0IGlzIGEgZGlmZmVyZW50IHRha2Ugb24gdGhlIHNp bWlsYXIgcHJvYmxlbSwgc3BlY2lhbGl6ZWQgdG8gYSBwYXJ0aWN1bGFyIHVzZS1jYXNlPw0KDQpS ZWdhcmRzLA0KUm9iZXJ0ICh3aXRoIFJGQzgzNDUgY28tYXV0aG9yIGhhdCBvbikNCg0K From nobody Wed Aug 28 06:46:05 2019 Return-Path: <ietf.dmytro@shytyi.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA6120041 for <netmod@ietfa.amsl.com>; Wed, 28 Aug 2019 06:46:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.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 P76uD9_Of1_n for <netmod@ietfa.amsl.com>; Wed, 28 Aug 2019 06:46:01 -0700 (PDT) Received: from sender-of-o52.zoho.eu (sender-of-o52.zoho.eu [31.186.226.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980A6120059 for <netmod@ietf.org>; Wed, 28 Aug 2019 06:46:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566999941; cv=none; d=zohomail.eu; s=zohoarc; b=dgbsPA8wP/odp426PxwBidyJkMJ+QyheabzIT3khEyB82JtfqGIYLqfm8TJEOBtkos4qjF1Pu68E6w8c3C48yl9iTaKpLsPmxC9iTJ4P5LSpt7aer8YLvPmz+JoC0FYZv60WqJGPXVwpHkX4Zvy2TcFlP3Ydu/9n5xnUh+2m/co= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1566999941; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=55Pojq/tarHWkh5IldVjCbYcnuzpYh4kE+VPP8dEzA8=; b=cuQK7PLuPaOXuos4/0gWQZz5BCgMgbkmY/cKBqN0Id/xe8pg+vyMeD1sf251I+JqLaKM84Ho9gf6THr7BZDGW+ERbno/xHpSxz9NhIJ12ShLtqe9JKhlSKOR2XE0jF+ffA62QZLzUOa9+fzANpAnUfqDLmLoC71nwGjoN2d3yHE= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from=<ietf.dmytro@shytyi.net> header.from=<ietf.dmytro@shytyi.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1566999941; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=13140; bh=55Pojq/tarHWkh5IldVjCbYcnuzpYh4kE+VPP8dEzA8=; b=T6M4PLvrxVpJ42aGqtw7iwjT3Cr6HSV+j9SrD014ihsw9Vm+x51iEWw1SC6gXf6P RsIClnqM3jU80cuina7maS7kGWGMNAWPsJtxU59wmQONA90R5tafJ5P27cCHtE8FLbD gW68XDvx8dS4x823EI8n6+0FK+/3QsaA0X5NGPp4= Received: from sender.zoho.eu (172.26.23.79 [172.26.23.79]) by mx.zoho.eu with SMTPS id 1566999940046215.864047056338; Wed, 28 Aug 2019 15:45:40 +0200 (CEST) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 156699993997155.762287354506384; Wed, 28 Aug 2019 15:45:39 +0200 (CEST) Date: Wed, 28 Aug 2019 15:45:39 +0200 From: Dmytro Shytyi <ietf.dmytro@shytyi.net> To: "Robert Varga" <nite@hq.sk>, "billwu" <bill.wu@huawei.com> Cc: "netmod" <netmod@ietf.org> Message-Id: <16cd8798b80.b402ce899813.5192375594519800096@shytyi.net> In-Reply-To: <5219ac80-b607-b4b4-8c77-72950d4c5137@hq.sk> References: <155377227553.1573.8548464832229347361.idtracker@ietfa.amsl.com> <16caabd07ae.de4789c8151923.6368018099125205208@shytyi.net> <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> <5219ac80-b607-b4b4-8c77-72950d4c5137@hq.sk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29082_1382235135.1566999939968" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6Xpq6UVK44VZrle2QcgKjdaYkZ8> Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Aug 2019 13:46:03 -0000 ------=_Part_29082_1382235135.1566999939968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Please find comments inline. >On 27/08/2019 18:03, Dmytro Shytyi wrote: >> Dear All, >> >> I am one of the authors of ID VYSM and I would like to draw your >> attention to the evolution of the >> draft=C2=A0https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm= -01.txt. >> Recently we produced (but did not submitted yet) a new version of ID >> (02) and I beleive it fits the netmod working group. >> >> We would be gratefull if you could suggest if the new version(02) of the >> document=C2=A0 could become an official work item of the WG? >> =C2=A0 =C2=A0 =C2=A0 If yes, could you please indicate which modificatio= ns must be done >> in the document before submition. > >Hmm, looking over the model, it would seem there is quite a bit of >overlap with RFC8345 -- to the point I believe the model could be >formulated in terms of RFC8345 specialization: First of all I would like to thank you for this comment.=C2=A0=20 -Dmytro >virtualization -> networks/network > >device/links/interfaces/switches/vms are probably a mix of >node/termmination-point/link extensions with conjunction with >supporting-{topology,node,link}. I can imagine mapping: virtualization (ID) -> networks/network (RFC 8345) links (ID)- >link;(RFC 8345) ports (ID)-> termination points;(RFC 8345) But still.. it seems here we have to create extension of the model proposed= in RFC 8345. Precisely for node (RFC 8345) we may add types (switches, vms) and futer ad= d leafs /listsfor type if required (ex: #RAM,#vCPUs and other leafs for VMs= ) -Dmytro >How would the draft relate to RFC8345? Should it perhaps call out it is >a different take on the similar problem, specialized to a particular >use-case? One can suggest that=C2=A0 in the RFC8345 Figure 1, the block "service Topo= logy model" can include the proposed in the draft network service descripto= r with appropriate modification of mapping according to the RFC8345.=20 Meanwhile I find that the proposed solution(ID) try to solve the problem de= scibed below: The uCPE management mechanism may involve not only YANG modules but=C2=A0 a= lso the speficif logic written in programming languages. The proposed organ= isation of yang model is an attempt to find the best fit=C2=A0 for combinat= ion (YANG modules + specific logic written in python for example )=C2=A0 to= manage different existing NFVIs in the uCPE (by the orchestrator).=20 In the case of uCPE, the mapping (w/wo additinal logic) of "variables " bet= ween service yang modules (in the orchestrator) and NETCONF payload(that is= sent to the uCPE) will be more complex (requires additional transformation= s in the logic) with generic approach, then the solution presented in the I= D, that is tailored to the uCPE.=C2=A0 Therefore I find the proposed solution as a stadalone generic approach to m= anage multiple vendor uCPE that appears to be a particular case tailored fo= r uCPE NFVIs that may be not nesseraly follows RFC8345. I would be pleased = if you could comment this. -Dmytro >Regards, >Robert (with RFC8345 co-author hat on) >+1, in addition, I am wondering whether this is something related to overl= ay topology model, if yes, how it is different from DC Fabric topology mode= l defined in RFC8542?=C2=A0 >-Qin=C2=A0 Thank you for your comment. The RFC8542 condisers PODs in the DC network. u= CPE is located on the customer site. if we consider that uCPE is A POD (wit= h links and nodes like VMs and swithces) then in the RFC8542 describes diff= erent PODs in the network that are interconnected with links. The yang mod= el proposed in the ID ifocuses only on the uCPE interiour network service, = not the interconnection between the uCPEs. Aslo, I explained the difference= about extension neded for type of nodes,vms leafs and furter complexity in= the mapping logic in the reponce to Robert. -Dmytro Best regards, Dmytro. ------=_Part_29082_1382235135.1566999939968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>= <meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h= ead><body ><div style=3D"font-family: Verdana, Arial, Helvetica, sans-serif= ; font-size: 10pt;"><div><div style=3D"font-family: Verdana, Arial, Helveti= ca, sans-serif;font-size: 10.0pt;"><div><div style=3D"font-family: Verdana,= Arial, Helvetica, sans-serif;font-size: 10.0pt;"><div class=3D"x_-48709802= 1zmail_extra">Hello,<br></div><div class=3D"x_-487098021zmail_extra">Please= find comments inline.<br></div><div class=3D"x_-487098021zmail_extra"><br>= </div><div>>On 27/08/2019 18:03, Dmytro Shytyi wrote:<br></div><div>>= > Dear All,<br></div><div>>><br></div><div>>> I am one of th= e authors of ID VYSM and I would like to draw your<br></div><div>>> a= ttention to the evolution of the<br></div><div>>> draft <a targe= t=3D"_blank" href=3D"https://www.ietf.org/internet-drafts/draft-shytyi-netm= od-vysm-01.txt">https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vy= sm-01.txt</a>.<br></div><div>>> Recently we produced (but did not sub= mitted yet) a new version of ID<br></div><div>>> (02) and I beleive i= t fits the netmod working group.<br></div><div>>><br></div><div>>&= gt; We would be gratefull if you could suggest if the new version(02) of th= e<br></div><div>>> document  could become an official work item = of the WG?<br></div><div>>>       If yes, could you pl= ease indicate which modifications must be done<br></div><div>>> in th= e document before submition.<br></div><div>><br></div><div>>Hmm, look= ing over the model, it would seem there is quite a bit of<br></div><div>>= ;overlap with RFC8345 -- to the point I believe the model could be<br></div= ><div>>formulated in terms of RFC8345 specialization:<br></div><div><br>= </div><div>First of all I would like to thank you for this comment. <s= pan class=3D"font" style=3D"font-family:Verdana, Arial, Helvetica, sans-ser= if, sans-serif"><span class=3D"size" style=3D"font-size:13px"><span class= =3D"colour" style=3D"color:rgb(0, 0, 0)"><span class=3D"x_-487098021highlig= ht"> <br></span></span></span></span></div><div class=3D"x_-487098021align-= left" style=3D"text-align: left;">-Dmytro</div><div class=3D"x_-487098021al= ign-left" style=3D"text-align: left;"><span class=3D"font" style=3D"font-fa= mily:Verdana, Arial, Helvetica, sans-serif, sans-serif"><span class=3D"size= " style=3D"font-size:13px"><span class=3D"colour" style=3D"color:rgb(0, 0, = 0)"><span class=3D"x_-487098021highlight">>virtualization -> networks= /network<br></span></span></span></span></div><div style=3D"text-align: lef= t;" class=3D"x_-487098021align-left"><span class=3D"font" style=3D"font-fam= ily:Verdana, Arial, Helvetica, sans-serif, sans-serif"><span class=3D"size"= style=3D"font-size:13px"><span class=3D"colour" style=3D"color:rgb(0, 0, 0= )"><span class=3D"x_-487098021highlight">></span></span></span></span><b= r></div><div>>device/links/interfaces/switches/vms are probably a mix of= <br></div><div>>node/termmination-point/link extensions with conjunction= with<br></div><div>>supporting-{topology,node,link}.<br></div><div><br>= </div><div>I can imagine mapping:<br></div><div style=3D"text-align: left;"= class=3D"x_-487098021align-left"><span class=3D"font" style=3D"font-family= :Verdana, Arial, Helvetica, sans-serif, sans-serif"><span class=3D"size" st= yle=3D"font-size:13px"><span class=3D"colour" style=3D"color:rgb(0, 0, 0)">= <span class=3D"x_-487098021highlight">virtualization (ID) -> networks/ne= twork (RFC 8345)</span></span></span></span><br></div><div class=3D"x_-4870= 98021align-left" style=3D"text-align: left;">links (ID)- >link;<span cla= ss=3D"font" style=3D"font-family:Verdana, Arial, Helvetica, sans-serif, san= s-serif"><span class=3D"size" style=3D"font-size:13px"><span class=3D"colou= r" style=3D"color:rgb(0, 0, 0)"><span class=3D"x_-487098021highlight">(RFC = 8345)</span></span></span></span><br></div><div class=3D"x_-487098021align-= left" style=3D"text-align: left;">ports (ID)-> termination points;<span = class=3D"font" style=3D"font-family:Verdana, Arial, Helvetica, sans-serif, = sans-serif"><span class=3D"size" style=3D"font-size:13px"><span class=3D"co= lour" style=3D"color:rgb(0, 0, 0)"><span class=3D"x_-487098021highlight">(R= FC 8345)</span></span></span></span><br></div><div class=3D"x_-487098021ali= gn-left" style=3D"text-align: left;"><br></div><div class=3D"x_-487098021al= ign-left" style=3D"text-align: left;">But still.. it seems here we have to = create extension of the model proposed in <span class=3D"font" style=3D"fon= t-family:Verdana, Arial, Helvetica, sans-serif, sans-serif"><span class=3D"= size" style=3D"font-size:13px"><span class=3D"colour" style=3D"color:rgb(0,= 0, 0)"><span class=3D"x_-487098021highlight">RFC 8345</span></span></span>= </span>.<br></div><div class=3D"x_-487098021align-left" style=3D"text-align= : left;">Precisely for node (RFC 8345) we may add types (switches, vms) and= futer add leafs /listsfor type if required (ex: #RAM,#vCPUs and other leaf= s for VMs)<br></div><div class=3D"x_-487098021align-left" style=3D"text-ali= gn: left;">-Dmytro</div><div class=3D"x_-487098021align-left" style=3D"text= -align: left;"><br></div><div class=3D"x_-487098021align-left" style=3D"tex= t-align: left;">>How would the draft relate to RFC8345? Should it perhap= s call out it is<br></div><div>>a different take on the similar problem,= specialized to a particular<br></div><div>>use-case?<br></div><div><br>= </div><div>One can suggest that  in the RFC8345 Figure 1, the block "s= ervice Topology model" can include the proposed in the draft network servic= e descriptor with appropriate modification of mapping according to the RFC8= 345. <br></div><div><br></div><div>Meanwhile I find that the proposed solut= ion(ID) try to solve the problem descibed below:<br></div><div><br></div><d= iv>The uCPE management mechanism may involve not only YANG modules but = ; also the speficif logic written in programming languages. The proposed or= ganisation of yang model is an attempt to find the best fit  for combi= nation (YANG modules + specific logic written in python for example ) = to manage different existing NFVIs in the uCPE (by the orchestrator). <br>= </div><div>In the case of uCPE, the mapping (w/wo additinal logic) of "vari= ables " between service yang modules (in the orchestrator) and NETCONF payl= oad(that is sent to the uCPE) will be more complex (requires additional tra= nsformations in the logic) with generic approach, then the solution present= ed in the ID, that is tailored to the uCPE. <br></div><div><br></div><= div>Therefore I find the proposed solution as a stadalone generic approach = to manage multiple vendor uCPE that appears to be a particular case tailore= d for uCPE NFVIs that may be not nesseraly follows RFC8345. I would be plea= sed if you could comment this.<br></div><div>-Dmytro<br></div><div><br></di= v><div>>Regards,<br></div><div>>Robert (with RFC8345 co-author hat on= )<br></div><div><br></div><div class=3D"x_-487098021zmail_extra"><div>>+= 1, in addition, I am wondering whether this is something related to overlay= topology model, if yes, how it is different from DC Fabric topology model = defined in RFC8542? <br></div><div>>-Qin <br></div><div><br></= div><div>Thank you for your comment. The RFC8542 condisers PODs in the DC n= etwork. uCPE is located on the customer site. if we consider that uCPE is A= POD (with links and nodes like VMs and swithces) then in the RFC8542 descr= ibes different PODs in the network that are interconnected with links. The= yang model proposed in the ID ifocuses only on the uCPE interiour network = service, not the interconnection between the uCPEs. Aslo, I explained the d= ifference about extension neded for type of nodes,vms leafs and furter comp= lexity in the mapping logic in the reponce to Robert.<br></div><div>-Dmytro= </div></div></div></div></div></div><meta content=3D"text/html; charset=3Du= tf-8"><div><div style=3D"font-family: Verdana, Arial, Helvetica, sans-serif= ;font-size: 10.0pt;"><meta><div><div style=3D"font-family: Verdana, Arial, = Helvetica, sans-serif;font-size: 10.0pt;"><div><br></div><div><br></div><di= v>Best regards,<br></div><div>Dmytro.<br></div></div></div><div><br></div><= /div><div><br></div></div><div><br></div></div><br></body></html> ------=_Part_29082_1382235135.1566999939968-- From nobody Wed Aug 28 11:50:40 2019 Return-Path: <noreply@ietf.org> X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CFF12002E; Wed, 28 Aug 2019 11:50:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alexey Melnikov via Datatracker <noreply@ietf.org> To: "The IESG" <iesg@ietf.org> Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm> Message-ID: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2019 11:50:38 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ydaAlCqWrZnjdxfQJk8qW72ANBE> Subject: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Aug 2019 18:50:39 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-netmod-artwork-folding-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for your document. It might be just me, but I think your examples in 9.4.1 with trailing \ don’t seem to match the folding algorithm in section 7, as it doesn’t describe special handling of trailing \. From nobody Wed Aug 28 15:03:42 2019 Return-Path: <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04E012010D; Wed, 28 Aug 2019 15:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 i-MU_GvKlep7; Wed, 28 Aug 2019 15:03:29 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3247A1200E3; Wed, 28 Aug 2019 15:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567029807; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=50MhbOXsep97IwFuJ58RFL36kd81reZMca7Pg5rVTlk=; b=mxLbrH7Xwuy+QC6E7L+vnJy5mqYtu+VnMut3maQEjIObKCuXIFoF+RFqfxW68LxY 9uOl0jHsq54UIgCwcVKd163zwb3JXDmavPL0gh0sMc9wPcL0vaTfCS8VwmIyIwCpmod xBNlh3TH44GJPRByx2iy6bK/LjaEOise+uoYvyrs= From: Kent Watsen <kent+ietf@watsen.net> Message-ID: <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F7E2CAA7-7696-4A02-8403-29AEE7DF07BE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 28 Aug 2019 22:03:27 +0000 In-Reply-To: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> To: Alexey Melnikov <aamelnikov@fastmail.fm> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.28-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rkb9oAgi0lMkm1edSNdaOTwMpbU> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Aug 2019 22:03:32 -0000 --Apple-Mail=_F7E2CAA7-7696-4A02-8403-29AEE7DF07BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alexey, Response at bottom. Kent > On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <noreply@ietf.org> wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-netmod-artwork-folding-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for your document. >=20 > It might be just me, but I think your examples in 9.4.1 with trailing = \ don=E2=80=99t > seem to match the folding algorithm in section 7, as it doesn=E2=80=99t = describe > special handling of trailing \. Can you be more specific regarding what it is you think doesn't match? = Step (2) says, at the location where the fold is to occur, insert '\' = followed by '\n'. That appears to be what is shown in 9.4.1, yes? FWIW, the text in Section 9.4.1 (as with all the examples in the draft) = was dynamically-generated (at draft build time) by feeding the text in = Section 9.4 into the script in the Appendix A. Kent // co-author --Apple-Mail=_F7E2CAA7-7696-4A02-8403-29AEE7DF07BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D""><div>Hi Alexey,</div><div><br class=3D""></div><div>Response = at bottom.</div><div><br class=3D""></div><div>Kent</div><div><br = class=3D""></div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D"">On Aug 28, 2019, at 2:50 PM, Alexey Melnikov = via Datatracker <<a href=3D"mailto:noreply@ietf.org" = class=3D"">noreply@ietf.org</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Alexey= Melnikov has entered the following ballot position for<br = class=3D"">draft-ietf-netmod-artwork-folding-08: Discuss<br class=3D""><br= class=3D"">When responding, please keep the subject line intact and = reply to all<br class=3D"">email addresses included in the To and CC = lines. (Feel free to cut this<br class=3D"">introductory paragraph, = however.)<br class=3D""><br class=3D""><br class=3D"">Please refer to <a = href=3D"https://www.ietf.org/iesg/statement/discuss-criteria.html" = class=3D"">https://www.ietf.org/iesg/statement/discuss-criteria.html</a><b= r class=3D"">for more information about IESG DISCUSS and COMMENT = positions.<br class=3D""><br class=3D""><br class=3D"">The document, = along with other ballot positions, can be found here:<br class=3D""><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding= /" = class=3D"">https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/</a><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">---------------------------------------------------------------= -------<br class=3D"">DISCUSS:<br = class=3D"">---------------------------------------------------------------= -------<br class=3D""><br class=3D"">Thank you for your document.<br = class=3D""><br class=3D"">It might be just me, but I think your examples = in 9.4.1 with trailing \ don=E2=80=99t<br class=3D"">seem to match the = folding algorithm in section 7, as it doesn=E2=80=99t describe<br = class=3D"">special handling of trailing \.<br = class=3D""></div></div></blockquote><br class=3D""></div><div>Can you be = more specific regarding what it is you think doesn't match?   Step = (2) says, at the location where the fold is to occur, insert '\' = followed by '\n'.  That appears to be what is shown in 9.4.1, = yes?</div><div><br class=3D""></div><div>FWIW, the text in Section 9.4.1 = (as with all the examples in the draft) was dynamically-generated (at = draft build time) by feeding the text in Section 9.4 into the script in = the Appendix A.</div><br class=3D""><div class=3D"">Kent  // = co-author</div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div></body></html>= --Apple-Mail=_F7E2CAA7-7696-4A02-8403-29AEE7DF07BE-- From nobody Wed Aug 28 19:00:17 2019 Return-Path: <bill.wu@huawei.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263D120013 for <netmod@ietfa.amsl.com>; Wed, 28 Aug 2019 19:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7task75kopzh for <netmod@ietfa.amsl.com>; Wed, 28 Aug 2019 19:00:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B0612024E for <netmod@ietf.org>; Wed, 28 Aug 2019 19:00:09 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B880F93C90382BDC0A7A for <netmod@ietf.org>; Thu, 29 Aug 2019 03:00:06 +0100 (IST) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Aug 2019 03:00:05 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.9]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Thu, 29 Aug 2019 10:00:01 +0800 From: Qin Wu <bill.wu@huawei.com> To: Dmytro Shytyi <ietf.dmytro@shytyi.net>, Robert Varga <nite@hq.sk> CC: netmod <netmod@ietf.org> Thread-Topic: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. Thread-Index: AdVeDF89q2Md3X/ZSm+HIiSGbAazXg== Date: Thu, 29 Aug 2019 02:00:01 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABAA92B5866@dggeml511-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA92B5866dggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/aTvQyan8L5QDeVqffBgdzUY0Nk8> Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 02:00:13 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA92B5866dggeml511mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG15dHJvOg0K5Y+R5Lu25Lq6OiBEbXl0cm8gU2h5dHlpIFttYWlsdG86aWV0Zi5kbXl0cm9Ac2h5 dHlpLm5ldF0NCuWPkemAgeaXtumXtDogMjAxOeW5tDjmnIgyOOaXpSAyMTo0Ng0K5pS25Lu25Lq6 OiBSb2JlcnQgVmFyZ2EgPG5pdGVAaHEuc2s+OyBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4N CuaKhOmAgTogbmV0bW9kIDxuZXRtb2RAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbbmV0bW9kXSBO ZXcgVmVyc2lvbiBkcmFmdC1zaHl0eWktbmV0bW9kLXZ5c20tMDIudHh0IGFzIFdvcmtpbmcgR3Jv dXAgZG9jdW1lbnQuDQoNCkhlbGxvLA0KUGxlYXNlIGZpbmQgY29tbWVudHMgaW5saW5lLg0KDQo+ T24gMjcvMDgvMjAxOSAxODowMywgRG15dHJvIFNoeXR5aSB3cm90ZToNCj4+IERlYXIgQWxsLA0K Pj4NCj4+IEkgYW0gb25lIG9mIHRoZSBhdXRob3JzIG9mIElEIFZZU00gYW5kIEkgd291bGQgbGlr ZSB0byBkcmF3IHlvdXINCj4+IGF0dGVudGlvbiB0byB0aGUgZXZvbHV0aW9uIG9mIHRoZQ0KPj4g ZHJhZnQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNoeXR5aS1u ZXRtb2QtdnlzbS0wMS50eHQuDQo+PiBSZWNlbnRseSB3ZSBwcm9kdWNlZCAoYnV0IGRpZCBub3Qg c3VibWl0dGVkIHlldCkgYSBuZXcgdmVyc2lvbiBvZiBJRA0KPj4gKDAyKSBhbmQgSSBiZWxlaXZl IGl0IGZpdHMgdGhlIG5ldG1vZCB3b3JraW5nIGdyb3VwLg0KPj4NCj4+IFdlIHdvdWxkIGJlIGdy YXRlZnVsbCBpZiB5b3UgY291bGQgc3VnZ2VzdCBpZiB0aGUgbmV3IHZlcnNpb24oMDIpIG9mIHRo ZQ0KPj4gZG9jdW1lbnQgIGNvdWxkIGJlY29tZSBhbiBvZmZpY2lhbCB3b3JrIGl0ZW0gb2YgdGhl IFdHPw0KPj4gICAgICAgSWYgeWVzLCBjb3VsZCB5b3UgcGxlYXNlIGluZGljYXRlIHdoaWNoIG1v ZGlmaWNhdGlvbnMgbXVzdCBiZSBkb25lDQo+PiBpbiB0aGUgZG9jdW1lbnQgYmVmb3JlIHN1Ym1p dGlvbi4NCj4NCj5IbW0sIGxvb2tpbmcgb3ZlciB0aGUgbW9kZWwsIGl0IHdvdWxkIHNlZW0gdGhl cmUgaXMgcXVpdGUgYSBiaXQgb2YNCj5vdmVybGFwIHdpdGggUkZDODM0NSAtLSB0byB0aGUgcG9p bnQgSSBiZWxpZXZlIHRoZSBtb2RlbCBjb3VsZCBiZQ0KPmZvcm11bGF0ZWQgaW4gdGVybXMgb2Yg UkZDODM0NSBzcGVjaWFsaXphdGlvbjoNCg0KRmlyc3Qgb2YgYWxsIEkgd291bGQgbGlrZSB0byB0 aGFuayB5b3UgZm9yIHRoaXMgY29tbWVudC4NCi1EbXl0cm8NCj52aXJ0dWFsaXphdGlvbiAtPiBu ZXR3b3Jrcy9uZXR3b3JrDQo+DQo+ZGV2aWNlL2xpbmtzL2ludGVyZmFjZXMvc3dpdGNoZXMvdm1z IGFyZSBwcm9iYWJseSBhIG1peCBvZg0KPm5vZGUvdGVybW1pbmF0aW9uLXBvaW50L2xpbmsgZXh0 ZW5zaW9ucyB3aXRoIGNvbmp1bmN0aW9uIHdpdGgNCj5zdXBwb3J0aW5nLXt0b3BvbG9neSxub2Rl LGxpbmt9Lg0KDQpJIGNhbiBpbWFnaW5lIG1hcHBpbmc6DQp2aXJ0dWFsaXphdGlvbiAoSUQpIC0+ IG5ldHdvcmtzL25ldHdvcmsgKFJGQyA4MzQ1KQ0KbGlua3MgKElEKS0gPmxpbms7KFJGQyA4MzQ1 KQ0KcG9ydHMgKElEKS0+IHRlcm1pbmF0aW9uIHBvaW50czsoUkZDIDgzNDUpDQoNCkJ1dCBzdGls bC4uIGl0IHNlZW1zIGhlcmUgd2UgaGF2ZSB0byBjcmVhdGUgZXh0ZW5zaW9uIG9mIHRoZSBtb2Rl bCBwcm9wb3NlZCBpbiBSRkMgODM0NS4NClByZWNpc2VseSBmb3Igbm9kZSAoUkZDIDgzNDUpIHdl IG1heSBhZGQgdHlwZXMgKHN3aXRjaGVzLCB2bXMpIGFuZCBmdXRlciBhZGQgbGVhZnMgL2xpc3Rz Zm9yIHR5cGUgaWYgcmVxdWlyZWQgKGV4OiAjUkFNLCN2Q1BVcyBhbmQgb3RoZXIgbGVhZnMgZm9y IFZNcykNCi1EbXl0cm8NCg0KPkhvdyB3b3VsZCB0aGUgZHJhZnQgcmVsYXRlIHRvIFJGQzgzNDU/ IFNob3VsZCBpdCBwZXJoYXBzIGNhbGwgb3V0IGl0IGlzDQo+YSBkaWZmZXJlbnQgdGFrZSBvbiB0 aGUgc2ltaWxhciBwcm9ibGVtLCBzcGVjaWFsaXplZCB0byBhIHBhcnRpY3VsYXINCj51c2UtY2Fz ZT8NCg0KT25lIGNhbiBzdWdnZXN0IHRoYXQgIGluIHRoZSBSRkM4MzQ1IEZpZ3VyZSAxLCB0aGUg YmxvY2sgInNlcnZpY2UgVG9wb2xvZ3kgbW9kZWwiIGNhbiBpbmNsdWRlIHRoZSBwcm9wb3NlZCBp biB0aGUgZHJhZnQgbmV0d29yayBzZXJ2aWNlIGRlc2NyaXB0b3Igd2l0aCBhcHByb3ByaWF0ZSBt b2RpZmljYXRpb24gb2YgbWFwcGluZyBhY2NvcmRpbmcgdG8gdGhlIFJGQzgzNDUuDQoNCk1lYW53 aGlsZSBJIGZpbmQgdGhhdCB0aGUgcHJvcG9zZWQgc29sdXRpb24oSUQpIHRyeSB0byBzb2x2ZSB0 aGUgcHJvYmxlbSBkZXNjaWJlZCBiZWxvdzoNCg0KVGhlIHVDUEUgbWFuYWdlbWVudCBtZWNoYW5p c20gbWF5IGludm9sdmUgbm90IG9ubHkgWUFORyBtb2R1bGVzIGJ1dCAgYWxzbyB0aGUgc3BlZmlj aWYgbG9naWMgd3JpdHRlbiBpbiBwcm9ncmFtbWluZyBsYW5ndWFnZXMuIFRoZSBwcm9wb3NlZCBv cmdhbmlzYXRpb24gb2YgeWFuZyBtb2RlbCBpcyBhbiBhdHRlbXB0IHRvIGZpbmQgdGhlIGJlc3Qg Zml0ICBmb3IgY29tYmluYXRpb24gKFlBTkcgbW9kdWxlcyArIHNwZWNpZmljIGxvZ2ljIHdyaXR0 ZW4gaW4gcHl0aG9uIGZvciBleGFtcGxlICkgIHRvIG1hbmFnZSBkaWZmZXJlbnQgZXhpc3Rpbmcg TkZWSXMgaW4gdGhlIHVDUEUgKGJ5IHRoZSBvcmNoZXN0cmF0b3IpLg0KSW4gdGhlIGNhc2Ugb2Yg dUNQRSwgdGhlIG1hcHBpbmcgKHcvd28gYWRkaXRpbmFsIGxvZ2ljKSBvZiAidmFyaWFibGVzICIg YmV0d2VlbiBzZXJ2aWNlIHlhbmcgbW9kdWxlcyAoaW4gdGhlIG9yY2hlc3RyYXRvcikgYW5kIE5F VENPTkYgcGF5bG9hZCh0aGF0IGlzIHNlbnQgdG8gdGhlIHVDUEUpIHdpbGwgYmUgbW9yZSBjb21w bGV4IChyZXF1aXJlcyBhZGRpdGlvbmFsIHRyYW5zZm9ybWF0aW9ucyBpbiB0aGUgbG9naWMpIHdp dGggZ2VuZXJpYyBhcHByb2FjaCwgdGhlbiB0aGUgc29sdXRpb24gcHJlc2VudGVkIGluIHRoZSBJ RCwgdGhhdCBpcyB0YWlsb3JlZCB0byB0aGUgdUNQRS4NCg0KVGhlcmVmb3JlIEkgZmluZCB0aGUg cHJvcG9zZWQgc29sdXRpb24gYXMgYSBzdGFkYWxvbmUgZ2VuZXJpYyBhcHByb2FjaCB0byBtYW5h Z2UgbXVsdGlwbGUgdmVuZG9yIHVDUEUgdGhhdCBhcHBlYXJzIHRvIGJlIGEgcGFydGljdWxhciBj YXNlIHRhaWxvcmVkIGZvciB1Q1BFIE5GVklzIHRoYXQgbWF5IGJlIG5vdCBuZXNzZXJhbHkgZm9s bG93cyBSRkM4MzQ1LiBJIHdvdWxkIGJlIHBsZWFzZWQgaWYgeW91IGNvdWxkIGNvbW1lbnQgdGhp cy4NCi1EbXl0cm8NCg0KPlJlZ2FyZHMsDQo+Um9iZXJ0ICh3aXRoIFJGQzgzNDUgY28tYXV0aG9y IGhhdCBvbikNCg0KPisxLCBpbiBhZGRpdGlvbiwgSSBhbSB3b25kZXJpbmcgd2hldGhlciB0aGlz IGlzIHNvbWV0aGluZyByZWxhdGVkIHRvIG92ZXJsYXkgdG9wb2xvZ3kgbW9kZWwsIGlmIHllcywg aG93IGl0IGlzIGRpZmZlcmVudCBmcm9tIERDIEZhYnJpYyB0b3BvbG9neSBtb2RlbCBkZWZpbmVk IGluIFJGQzg1NDI/DQo+LVFpbg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4gVGhlIFJG Qzg1NDIgY29uZGlzZXJzIFBPRHMgaW4gdGhlIERDIG5ldHdvcmsuIHVDUEUgaXMgbG9jYXRlZCBv biB0aGUgY3VzdG9tZXIgc2l0ZS4gaWYgd2UgY29uc2lkZXIgdGhhdCB1Q1BFIGlzIEEgUE9EICh3 aXRoIGxpbmtzIGFuZCBub2RlcyBsaWtlIFZNcyBhbmQgc3dpdGhjZXMpIHRoZW4gaW4gdGhlIFJG Qzg1NDIgZGVzY3JpYmVzIGRpZmZlcmVudCBQT0RzIGluIHRoZSBuZXR3b3JrIHRoYXQgYXJlIGlu dGVyY29ubmVjdGVkIHdpdGggbGlua3MuIFRoZSB5YW5nIG1vZGVsIHByb3Bvc2VkIGluIHRoZSBJ RCBpZm9jdXNlcyBvbmx5IG9uIHRoZSB1Q1BFIGludGVyaW91ciBuZXR3b3JrIHNlcnZpY2UsIG5v dCB0aGUgaW50ZXJjb25uZWN0aW9uIGJldHdlZW4gdGhlIHVDUEVzLiBBc2xvLCBJIGV4cGxhaW5l ZCB0aGUgZGlmZmVyZW5jZSBhYm91dCBleHRlbnNpb24gbmVkZWQgZm9yIHR5cGUgb2Ygbm9kZXMs dm1zIGxlYWZzIGFuZCBmdXJ0ZXIgY29tcGxleGl0eSBpbiB0aGUgbWFwcGluZyBsb2dpYyBpbiB0 aGUgcmVwb25jZSB0byBSb2JlcnQuDQotRG15dHJvDQoNCltRaW5dOlNvIHlvdSBmb2N1cyBvbiBp bnRlcmNvbm5lY3Rpb24gYmV0d2VlbiBsb2NhbCB2UEUgYW5kIHJlbW90ZSB2UEU/DQpJdCBpcyBu b3QgY2xlYXIgd2hldGhlciB3ZSBzaG91bGQgZGlzdGluZ3Vpc2ggVk0gZnJvbSBzd2l0Y2guIElu IG15IHVuZGVyc3RhbmRpbmcsIFVwb24gVk5GIGlzIGluc3RhbnRpYXRlZCwgdGhlcmUgaXMgbm8g ZGlmZmVyZW5jZSBiZXR3ZWVuIHZpcnR1YWwgYW5kIHBoeXNpY2FsIHdvcmxkcy4NClZORiBsaWZl Y3ljbGUgbWFuYWdlbWVudCBpcyBzZXBhcmF0ZWQgZnJvbSB0b3BvbG9neSBjb25zdHJ1Y3Rpb24s IHdyb25nPw0KDQoNCkJlc3QgcmVnYXJkcywNCkRteXRyby4NCg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABAA92B5866dggeml511mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZm9udA0KCXtt c28tc3R5bGUtbmFtZTpmb250O30NCnNwYW4uc2l6ZQ0KCXttc28tc3R5bGUtbmFtZTpzaXplO30N CnNwYW4uY29sb3VyDQoJe21zby1zdHlsZS1uYW1lOmNvbG91cjt9DQpzcGFuLngtNDg3MDk4MDIx aGlnaGxpZ2h0DQoJe21zby1zdHlsZS1uYW1lOnhfLTQ4NzA5ODAyMWhpZ2hsaWdodDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EbXl0cm86 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+IERteXRybyBTaHl0eWkgW21haWx0bzppZXRmLmRteXRyb0BzaHl0eWku bmV0XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+IDIwMTk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFu IGxhbmc9IkVOLVVTIj44PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yODwvc3Bhbj7ml6U8 c3BhbiBsYW5nPSJFTi1VUyI+DQogMjE6NDY8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUm9iZXJ0IFZhcmdh ICZsdDtuaXRlQGhxLnNrJmd0OzsgUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJy Pg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IG5ldG1vZCAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjwvc3Bhbj48 Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBSZTogW25ldG1vZF0gTmV3IFZlcnNpb24gZHJhZnQtc2h5dHlpLW5ldG1vZC12eXNtLTAyLnR4 dCBhcyBXb3JraW5nIEdyb3VwIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlBsZWFzZSBm aW5kIGNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7T24gMjcvMDgvMjAxOSAxODow MywgRG15dHJvIFNoeXR5aSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7Jmd0OyBEZWFyIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IEkgYW0gb25l IG9mIHRoZSBhdXRob3JzIG9mIElEIFZZU00gYW5kIEkgd291bGQgbGlrZSB0byBkcmF3IHlvdXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBhdHRlbnRpb24gdG8gdGhl IGV2b2x1dGlvbiBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyBkcmFmdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zaHl0eWktbmV0bW9kLXZ5c20tMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNoeXR5aS1uZXRtb2QtdnlzbS0w MS50eHQ8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IFJlY2Vu dGx5IHdlIHByb2R1Y2VkIChidXQgZGlkIG5vdCBzdWJtaXR0ZWQgeWV0KSBhIG5ldyB2ZXJzaW9u IG9mIElEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgKDAyKSBhbmQg SSBiZWxlaXZlIGl0IGZpdHMgdGhlIG5ldG1vZCB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDsgV2Ugd291bGQgYmUgZ3JhdGVmdWxsIGlmIHlvdSBjb3VsZCBzdWdn ZXN0IGlmIHRoZSBuZXcgdmVyc2lvbigwMikgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDsgZG9jdW1lbnQmbmJzcDsgY291bGQgYmVjb21lIGFuIG9mZmljaWFs IHdvcmsgaXRlbSBvZiB0aGUgV0c/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWYgeWVzLCBjb3VsZCB5b3UgcGxlYXNlIGluZGlj YXRlIHdoaWNoIG1vZGlmaWNhdGlvbnMgbXVzdCBiZSBkb25lPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyZndDsgaW4gdGhlIGRvY3VtZW50IGJlZm9yZSBzdWJtaXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDtIbW0sIGxvb2tpbmcgb3ZlciB0aGUgbW9kZWwsIGl0IHdvdWxk IHNlZW0gdGhlcmUgaXMgcXVpdGUgYSBiaXQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7b3ZlcmxhcCB3aXRoIFJGQzgzNDUgLS0gdG8gdGhlIHBvaW50IEkgYmVsaWV2ZSB0 aGUgbW9kZWwgY291bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Zm9y bXVsYXRlZCBpbiB0ZXJtcyBvZiBSRkM4MzQ1IHNwZWNpYWxpemF0aW9uOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PkZpcnN0IG9mIGFsbCBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgeW91IGZvciB0aGlzIGNvbW1lbnQu Jm5ic3A7PHNwYW4gY2xhc3M9IngtNDg3MDk4MDIxaGlnaGxpZ2h0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPg0KPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPi1EbXl0 cm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0ieC00ODcwOTgwMjFoaWdobGlnaHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDt2aXJ0dWFsaXphdGlvbiAtJmd0OyBuZXR3b3Jrcy9uZXR3b3JrPC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0ieC00ODcwOTgwMjFoaWdobGln aHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDs8L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7ZGV2aWNlL2xpbmtzL2ludGVyZmFjZXMvc3dpdGNoZXMvdm1zIGFyZSBw cm9iYWJseSBhIG1peCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDtub2Rl L3Rlcm1taW5hdGlvbi1wb2ludC9saW5rIGV4dGVuc2lvbnMgd2l0aCBjb25qdW5jdGlvbiB3aXRo PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O3N1cHBvcnRpbmcte3RvcG9sb2d5 LG5vZGUsbGlua30uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBjYW4gaW1hZ2luZSBtYXBwaW5nOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 IngtNDg3MDk4MDIxaGlnaGxpZ2h0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj52aXJ0dWFsaXphdGlvbiAoSUQpIC0mZ3Q7IG5ldHdvcmtzL25ldHdvcmsgKFJGQyA4 MzQ1KTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+bGlua3MgKElEKS0gJmd0O2xpbms7PHNwYW4gY2xhc3M9IngtNDg3MDk4MDIxaGln aGxpZ2h0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPihSRkMgODM0NSk8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPnBvcnRzIChJRCktJmd0OyB0ZXJtaW5hdGlvbiBwb2ludHM7PHNw YW4gY2xhc3M9IngtNDg3MDk4MDIxaGlnaGxpZ2h0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PihSRkMgODM0NSk8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPkJ1dCBzdGlsbC4uIGl0IHNlZW1zIGhlcmUgd2UgaGF2ZSB0byBjcmVhdGUgZXh0 ZW5zaW9uIG9mIHRoZSBtb2RlbCBwcm9wb3NlZCBpbg0KPHNwYW4gY2xhc3M9IngtNDg3MDk4MDIx aGlnaGxpZ2h0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJGQyA4MzQ1PC9zcGFuPjwvc3Bh bj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+UHJlY2lzZWx5IGZvciBub2RlIChSRkMgODM0NSkgd2UgbWF5 IGFkZCB0eXBlcyAoc3dpdGNoZXMsIHZtcykgYW5kIGZ1dGVyIGFkZCBsZWFmcyAvbGlzdHNmb3Ig dHlwZSBpZiByZXF1aXJlZCAoZXg6ICNSQU0sI3ZDUFVzIGFuZCBvdGhlciBsZWFmcyBmb3IgVk1z KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPi1EbXl0cm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7SG93IHdvdWxkIHRoZSBkcmFmdCByZWxhdGUgdG8gUkZDODM0NT8gU2hv dWxkIGl0IHBlcmhhcHMgY2FsbCBvdXQgaXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 O2EgZGlmZmVyZW50IHRha2Ugb24gdGhlIHNpbWlsYXIgcHJvYmxlbSwgc3BlY2lhbGl6ZWQgdG8g YSBwYXJ0aWN1bGFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O3VzZS1jYXNl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPk9uZSBjYW4gc3VnZ2VzdCB0aGF0Jm5ic3A7IGluIHRoZSBSRkM4MzQ1 IEZpZ3VyZSAxLCB0aGUgYmxvY2sgJnF1b3Q7c2VydmljZSBUb3BvbG9neSBtb2RlbCZxdW90OyBj YW4gaW5jbHVkZSB0aGUgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IG5ldHdvcmsgc2VydmljZSBkZXNj cmlwdG9yIHdpdGggYXBwcm9wcmlhdGUNCiBtb2RpZmljYXRpb24gb2YgbWFwcGluZyBhY2NvcmRp bmcgdG8gdGhlIFJGQzgzNDUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPk1lYW53aGlsZSBJIGZpbmQgdGhhdCB0 aGUgcHJvcG9zZWQgc29sdXRpb24oSUQpIHRyeSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBkZXNjaWJl ZCBiZWxvdzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdUNQRSBtYW5hZ2VtZW50IG1lY2hhbmlzbSBtYXkg aW52b2x2ZSBub3Qgb25seSBZQU5HIG1vZHVsZXMgYnV0Jm5ic3A7IGFsc28gdGhlIHNwZWZpY2lm IGxvZ2ljIHdyaXR0ZW4gaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLiBUaGUgcHJvcG9zZWQgb3Jn YW5pc2F0aW9uIG9mIHlhbmcNCiBtb2RlbCBpcyBhbiBhdHRlbXB0IHRvIGZpbmQgdGhlIGJlc3Qg Zml0Jm5ic3A7IGZvciBjb21iaW5hdGlvbiAoWUFORyBtb2R1bGVzICYjNDM7IHNwZWNpZmljIGxv Z2ljIHdyaXR0ZW4gaW4gcHl0aG9uIGZvciBleGFtcGxlICkmbmJzcDsgdG8gbWFuYWdlIGRpZmZl cmVudCBleGlzdGluZyBORlZJcyBpbiB0aGUgdUNQRSAoYnkgdGhlIG9yY2hlc3RyYXRvcikuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgY2FzZSBvZiB1Q1BFLCB0aGUg bWFwcGluZyAody93byBhZGRpdGluYWwgbG9naWMpIG9mICZxdW90O3ZhcmlhYmxlcyAmcXVvdDsg YmV0d2VlbiBzZXJ2aWNlIHlhbmcgbW9kdWxlcyAoaW4gdGhlIG9yY2hlc3RyYXRvcikgYW5kIE5F VENPTkYgcGF5bG9hZCh0aGF0IGlzIHNlbnQgdG8NCiB0aGUgdUNQRSkgd2lsbCBiZSBtb3JlIGNv bXBsZXggKHJlcXVpcmVzIGFkZGl0aW9uYWwgdHJhbnNmb3JtYXRpb25zIGluIHRoZSBsb2dpYykg d2l0aCBnZW5lcmljIGFwcHJvYWNoLCB0aGVuIHRoZSBzb2x1dGlvbiBwcmVzZW50ZWQgaW4gdGhl IElELCB0aGF0IGlzIHRhaWxvcmVkIHRvIHRoZSB1Q1BFLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZXJlZm9yZSBJIGZpbmQgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGFzIGEgc3RhZGFsb25lIGdlbmVy aWMgYXBwcm9hY2ggdG8gbWFuYWdlIG11bHRpcGxlIHZlbmRvciB1Q1BFIHRoYXQgYXBwZWFycyB0 byBiZSBhIHBhcnRpY3VsYXIgY2FzZSB0YWlsb3JlZCBmb3IgdUNQRSBORlZJcw0KIHRoYXQgbWF5 IGJlIG5vdCBuZXNzZXJhbHkgZm9sbG93cyBSRkM4MzQ1LiBJIHdvdWxkIGJlIHBsZWFzZWQgaWYg eW91IGNvdWxkIGNvbW1lbnQgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4t RG15dHJvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O1JlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0O1JvYmVydCAod2l0aCBSRkM4MzQ1IGNvLWF1dGhvciBoYXQgb24pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmIzQzOzEsIGluIGFkZGl0aW9uLCBJIGFtIHdvbmRlcmluZyB3 aGV0aGVyIHRoaXMgaXMgc29tZXRoaW5nIHJlbGF0ZWQgdG8gb3ZlcmxheSB0b3BvbG9neSBtb2Rl bCwgaWYgeWVzLCBob3cgaXQgaXMgZGlmZmVyZW50IGZyb20gREMgRmFicmljIHRvcG9sb2d5IG1v ZGVsIGRlZmluZWQNCiBpbiBSRkM4NTQyPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDstUWluJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3VyIGNv bW1lbnQuIFRoZSBSRkM4NTQyIGNvbmRpc2VycyBQT0RzIGluIHRoZSBEQyBuZXR3b3JrLiB1Q1BF IGlzIGxvY2F0ZWQgb24gdGhlIGN1c3RvbWVyIHNpdGUuIGlmIHdlIGNvbnNpZGVyIHRoYXQgdUNQ RSBpcyBBIFBPRCAod2l0aCBsaW5rcyBhbmQNCiBub2RlcyBsaWtlIFZNcyBhbmQgc3dpdGhjZXMp IHRoZW4gaW4gdGhlIFJGQzg1NDIgZGVzY3JpYmVzIGRpZmZlcmVudCBQT0RzIGluIHRoZSBuZXR3 b3JrIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIHdpdGggbGlua3MuIFRoZSB5YW5nIG1vZGVsIHBy b3Bvc2VkIGluIHRoZSBJRCBpZm9jdXNlcyBvbmx5IG9uIHRoZSB1Q1BFIGludGVyaW91ciBuZXR3 b3JrIHNlcnZpY2UsIG5vdCB0aGUgaW50ZXJjb25uZWN0aW9uIGJldHdlZW4gdGhlIHVDUEVzLiBB c2xvLA0KIEkgZXhwbGFpbmVkIHRoZSBkaWZmZXJlbmNlIGFib3V0IGV4dGVuc2lvbiBuZWRlZCBm b3IgdHlwZSBvZiBub2Rlcyx2bXMgbGVhZnMgYW5kIGZ1cnRlciBjb21wbGV4aXR5IGluIHRoZSBt YXBwaW5nIGxvZ2ljIGluIHRoZSByZXBvbmNlIHRvIFJvYmVydC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj4tRG15dHJvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+W1Fpbl06U28geW91IGZvY3VzIG9uIGludGVyY29ubmVjdGlvbiBiZXR3ZWVuIGxvY2FsIHZQ RSBhbmQgcmVtb3RlIHZQRT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGlzIG5v dCBjbGVhciB3aGV0aGVyIHdlIHNob3VsZCBkaXN0aW5ndWlzaCBWTSBmcm9tIHN3aXRjaC4gSW4g bXkgdW5kZXJzdGFuZGluZywgVXBvbiBWTkYgaXMgaW5zdGFudGlhdGVkLCB0aGVyZSBpcyBubyBk aWZmZXJlbmNlIGJldHdlZW4gdmlydHVhbA0KIGFuZCBwaHlzaWNhbCB3b3JsZHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5WTkYgbGlmZWN5Y2xlIG1hbmFnZW1lbnQgaXMgc2VwYXJh dGVkIGZyb20gdG9wb2xvZ3kgY29uc3RydWN0aW9uLCB3cm9uZz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5EbXl0cm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAA92B5866dggeml511mbxchi_-- From nobody Thu Aug 29 01:55:19 2019 Return-Path: <aamelnikov@fastmail.fm> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8B120103; Thu, 29 Aug 2019 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=fastmail.fm header.b=YhUeBSsN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VnEOAQS1 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 TyTUFcw_YtIB; Thu, 29 Aug 2019 01:55:08 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFE31200FF; Thu, 29 Aug 2019 01:55:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5B8764F1; Thu, 29 Aug 2019 04:55:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 29 Aug 2019 04:55:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=q F2wnSKIwIYDagdAEy3D8aQwhbdw34CmcqcCWfT+538=; b=YhUeBSsNeiYHyB+86 f/7N12ErQXxsGXlM5Jzl0LIGC7gcwe86dR33N21Ktr8QCjfwEsOlSMrqYyLkFmZX fu45dQVz7tj7QR6V1m77VcIMnHYX59OyoYoKvmEuTc+1tNgSIhdauD+rkdBjpmYI GorgxLZABnW7Bi/QVW1tnDcUUyHN9NCCJ/FBU8XY3tfzryQe48XTErSftZ1pnZrT 7Nt6MFFyqechhxs8KO/4/i44qp4/pDfRD5GZrKteTxx+AtggX2GflwQLfE54azhz 2P800acyaIoe6nFebt5JWNm+SeXjXchqYh6Ik7JZegFxDV1P+4pCwVKRnIocBxGG kOT4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=qF2wnSKIwIYDagdAEy3D8aQwhbdw34CmcqcCWfT+5 38=; b=VnEOAQS1HUUC4J9V/vkLv3BqB4vLMwjI/N62/+2f7n1zJ1RISS5etxgfd z9qWlNzd9BHt8Pi8tgPGUQKovRvUEWtQ5SoQcMuXZLA3XobnC7RYn+qRNirzbj28 5xIFnOC+tDCiL1lhSLmqy8FRnaDGNHp3n6UutOXGS/vbMQyCj5POaBpOPbXORyFD VTMcpzytMhHfngqDuLX3/zAKez/zB61OzFerNcHeB/3W5t43HWbLYdfW8isy8v7J CCIRYIHkIhsv9n+oBuWdQfz1eD4fw3aeY2+qWvcpr5apn5kQcEMg2F+xSlQcg+Vg AGwCmhJUQtuCoWM1BF/SE3atIyo4Q== X-ME-Sender: <xms:6pJnXalPt64-KiLVHL3dPfXkYnXULErL--9iKUViGPlgyzY_etofsA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeivddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhofgjfffgkfhfvfesrgejmherhhdtjeenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepkeeirddugedurddvtdekrddu heeinecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmh grihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: <xmx:6pJnXZS4PMVOR5o9H91D99EJHh8k9A3FAfaU9aoyeXni9gLXa53Omg> <xmx:6pJnXWCXnT3biRZuL5PGAuqXBjRhB5bH7dj8HU2chZuxZyZyR1iB5w> <xmx:6pJnXYQ3ZIfbPqbOWQsJw8FIA3mVcPTdufI_w2dtQp9kDEYqnPEpRQ> <xmx:6pJnXZJnoWj129hKYNwJs-ITPvZHWQ3axKsBIpL1celhRVfvUouDag> Received: from [192.168.1.243] (host86-141-208-156.range86-141.btcentralplus.com [86.141.208.156]) by mail.messagingengine.com (Postfix) with ESMTPA id A250880062; Thu, 29 Aug 2019 04:55:05 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0413B323-0299-4203-8EF7-7A833FE63C1D Mime-Version: 1.0 (1.0) From: Alexey Melnikov <aamelnikov@fastmail.fm> X-Mailer: iPad Mail (16G102) In-Reply-To: <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> Date: Thu, 29 Aug 2019 09:55:03 +0100 Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> Content-Transfer-Encoding: 7bit Message-Id: <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> To: Kent Watsen <kent+ietf@watsen.net> Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PzTQDzogn06zoCzMT293b9VPsNs> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 08:55:12 -0000 --Apple-Mail-0413B323-0299-4203-8EF7-7A833FE63C1D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kent, > On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: >=20 > Hi Alexey, >=20 > Response at bottom. >=20 > Kent >=20 >=20 >> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker <noreply@iet= f.org> wrote: >>=20 >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-netmod-artwork-folding-08: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Thank you for your document. >>=20 >> It might be just me, but I think your examples in 9.4.1 with trailing \ d= on=E2=80=99t >> seem to match the folding algorithm in section 7, as it doesn=E2=80=99t d= escribe >> special handling of trailing \. >=20 > Can you be more specific regarding what it is you think doesn't match? S= tep (2) says, at the location where the fold is to occur, insert '\' followe= d by '\n'. That appears to be what is shown in 9.4.1, yes? In the HTML version (in datatracker) I am seeing: =E2=80=9CThis line ends with a backslash \\=E2=80=9D followed by an empty line. So I see 2 trailing \ followed by end of line, in= stead of \, end of line, and then \. >=20 > FWIW, the text in Section 9.4.1 (as with all the examples in the draft) wa= s dynamically-generated (at draft build time) by feeding the text in Section= 9.4 into the script in the Appendix A. >=20 > Kent // co-author >=20 >=20 --Apple-Mail-0413B323-0299-4203-8EF7-7A833FE63C1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">Hi K= ent,</div><div dir=3D"ltr"><br>On 28 Aug 2019, at 23:03, Kent Watsen <<a h= ref=3D"mailto:kent+ietf@watsen.net">kent+ietf@watsen.net</a>> wrote:<br><= br></div><blockquote type=3D"cite"><div dir=3D"ltr"><meta http-equiv=3D"Cont= ent-Type" content=3D"text/html; charset=3Dutf-8"><div>Hi Alexey,</div><div><= br class=3D""></div><div>Response at bottom.</div><div><br class=3D""></div>= <div>Kent</div><div><br class=3D""></div><div><br class=3D""><blockquote typ= e=3D"cite" class=3D""><div class=3D"">On Aug 28, 2019, at 2:50 PM, Alexey Me= lnikov via Datatracker <<a href=3D"mailto:noreply@ietf.org" class=3D"">no= reply@ietf.org</a>> wrote:</div><br class=3D"Apple-interchange-newline"><= div class=3D""><div class=3D"">Alexey Melnikov has entered the following bal= lot position for<br class=3D"">draft-ietf-netmod-artwork-folding-08: Discuss= <br class=3D""><br class=3D"">When responding, please keep the subject line i= ntact and reply to all<br class=3D"">email addresses included in the To and C= C lines. (Feel free to cut this<br class=3D"">introductory paragraph, howeve= r.)<br class=3D""><br class=3D""><br class=3D"">Please refer to <a href=3D"h= ttps://www.ietf.org/iesg/statement/discuss-criteria.html" class=3D"">https:/= /www.ietf.org/iesg/statement/discuss-criteria.html</a><br class=3D"">for mor= e information about IESG DISCUSS and COMMENT positions.<br class=3D""><br cl= ass=3D""><br class=3D"">The document, along with other ballot positions, can= be found here:<br class=3D""><a href=3D"https://datatracker.ietf.org/doc/dr= aft-ietf-netmod-artwork-folding/" class=3D"">https://datatracker.ietf.org/do= c/draft-ietf-netmod-artwork-folding/</a><br class=3D""><br class=3D""><br cl= ass=3D""><br class=3D"">----------------------------------------------------= ------------------<br class=3D"">DISCUSS:<br class=3D"">--------------------= --------------------------------------------------<br class=3D""><br class=3D= "">Thank you for your document.<br class=3D""><br class=3D"">It might be jus= t me, but I think your examples in 9.4.1 with trailing \ don=E2=80=99t<br cl= ass=3D"">seem to match the folding algorithm in section 7, as it doesn=E2=80= =99t describe<br class=3D"">special handling of trailing \.<br class=3D""></= div></div></blockquote><br class=3D""></div><div>Can you be more specific re= garding what it is you think doesn't match?   Step (2) says, at the loc= ation where the fold is to occur, insert '\' followed by '\n'.  That ap= pears to be what is shown in 9.4.1, yes?</div></div></blockquote><div><br></= div>In the HTML version (in datatracker) I am seeing:<div><br></div><div><pr= e style=3D"box-sizing: border-box; overflow: auto; padding: 10px; margin-top= : 0px; margin-bottom: 10.5px; line-height: 1.214; word-break: break-all; wor= d-wrap: break-word; border: 1px solid rgb(204, 204, 204); border-top-left-ra= dius: 4px; border-top-right-radius: 4px; border-bottom-right-radius: 4px; bo= rder-bottom-left-radius: 4px;"><font face=3D"UICTFontTextStyleTallBody"><spa= n style=3D"white-space: normal; background-color: rgba(255, 255, 255, 0);">=E2= =80=9CThis line ends with a backslash \\=E2=80=9D</span></font><span style=3D= "font-family: "PT Mono", Monaco, monospace; font-size: 14px; -webk= it-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; ba= ckground-color: rgb(255, 253, 245);"> </span></pre><div>followed by an empty line. So I see 2 trailing \ followed b= y end of line, instead of \, end of line, and then \.</div><blockquote type=3D= "cite"><div dir=3D"ltr"><div><br class=3D""></div><div>FWIW, the text in Sec= tion 9.4.1 (as with all the examples in the draft) was dynamically-generated= (at draft build time) by feeding the text in Section 9.4 into the script in= the Appendix A.</div><br class=3D""><div class=3D"">Kent  // co-author= </div><div class=3D""><br class=3D""></div><div class=3D""><br class=3D""></= div></div></blockquote></div></body></html>= --Apple-Mail-0413B323-0299-4203-8EF7-7A833FE63C1D-- From nobody Thu Aug 29 01:55:40 2019 Return-Path: <aamelnikov@fastmail.fm> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC6120103; Thu, 29 Aug 2019 01:55:30 -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, FREEMAIL_FROM=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=fastmail.fm header.b=dGA1kUls; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qllbne2t 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 NAE0HeA8Rg8k; Thu, 29 Aug 2019 01:55:28 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CD81200D8; Thu, 29 Aug 2019 01:55:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id A5491548; Thu, 29 Aug 2019 04:55:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 29 Aug 2019 04:55:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=B EcnYQI/xqOtToSa3oL9ofQ81wHQ0tcNImzJIpmEyDo=; b=dGA1kUlsGNmx0G5bn R/+R4G61yZK94b+oiCD4llgDou5awcgokSp2nkZOqt825+IkiwAxA8M/ZRz3xrj6 HCSQOzaEibUNz9fyPA9hdLXQRbjvh/i0LZxdZCkIIYFOQi1qS0EsnTugToILVlIr 3FjkrBB6QRHZQ5QPCu0Po0yjYmd2AhgHqf9RuaqYUit2kttNSv50t6yZ8W69YZ54 OMN6hxQ2BDksAyzFNcicu/R/uGq8v5tdFt2pP0uX1ZWJ3VvQJi8mWunCHpVWwORq riSg/bUEPeyvSzsnLVmH0k3mZVRSd9WrW3iqbfQkWyJFC0V+zovgSHx0J7AbF8SB h6SaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BEcnYQI/xqOtToSa3oL9ofQ81wHQ0tcNImzJIpmEy Do=; b=Qllbne2tSXE63Wc9BDT+jKozM8wbnWGGMPC/zZzHUYOID5pUTNDrRH7x+ 6h/Lmapb6HLR+4yufdzqazX+ZDlqz5qiAwwsOR8p629cH0yNxtsNQtsuL6upIc9W FY2wFxjkfNrgEwRlzG4nEoAi9oHv1pDShI7MjZIKigYLyM6HhKDMsdPzAu/QVDDi XDi6nmYvss1sp+CSuA/Z2b7cYZ0Ib9ykkpPN+DOb/IvhCgVAQmtEqZ5kB8pMXder 0kepGedthW/HTsXMf3Nchos7sVeZWh8bRsO1iVPDj2QbWF5E8nje+OQ3pJ0p2NnL Mftjd3aPI4kQEbm623HRCn5FmuFUg== X-ME-Sender: <xms:_5JnXehvdCMkD5Kb1AmhgVz8cM5RA7z_oLLsWsUYDhM45wP69ZEy5Q> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeivddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhofgjfffgkfhfvfesthhqmhdthhdtvdenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecukfhppeekiedrudeguddrvddtkedrudehieenucfrrghrrghmpehmrghilhhfrhho mheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: <xmx:_5JnXZwmKmdKTLxBDt4ooO_Pf_nWDA1Z0uNUkDLjzb2HgtlXu__U1w> <xmx:_5JnXU9oFbj2TruIgfbXjLszBcxe7N2tD2OVeTjjUEq59uUzaIcjtw> <xmx:_5JnXeC88OPxtLxooj1Q6eN5paiCS7MpP_5U3XZjOB0rbOY2G3G2ag> <xmx:_5JnXQawnIT6JDjXelg7il8sWxa8mdgzLoOKquWvhoIq_H-InRYT4Q> Received: from [192.168.1.243] (host86-141-208-156.range86-141.btcentralplus.com [86.141.208.156]) by mail.messagingengine.com (Postfix) with ESMTPA id BD6F18005A; Thu, 29 Aug 2019 04:55:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov <aamelnikov@fastmail.fm> X-Mailer: iPad Mail (16G102) In-Reply-To: <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> Date: Thu, 29 Aug 2019 09:55:26 +0100 Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <468975AA-16AA-481B-B6E2-1FD4FC380747@fastmail.fm> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> To: Kent Watsen <kent+ietf@watsen.net> Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hvOt5QUoX517LpX7QWl9lFn6-yI> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 08:55:31 -0000 > On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: >=20 > FWIW, the text in Section 9.4.1 (as with all the examples in the draft) wa= s dynamically-generated (at draft build time) by feeding the text in Section= 9.4 into the script in the Appendix A. This is a fantastic news!= From nobody Thu Aug 29 02:29:51 2019 Return-Path: <rwilton@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E93E120103 for <netmod@ietfa.amsl.com>; Thu, 29 Aug 2019 02:29:50 -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 header.b=Cip4GsVZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=czolgNpQ 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 XkxDmn2A8jZL for <netmod@ietfa.amsl.com>; Thu, 29 Aug 2019 02:29:47 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BA31200A4 for <netmod@ietf.org>; Thu, 29 Aug 2019 02:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8189; q=dns/txt; s=iport; t=1567070987; x=1568280587; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kSYp7jEQSwfrv+dQgLfmr7JHdyC0+24NNhTo+2Eu0+g=; b=Cip4GsVZZkoFkiXHliYo79YXzTuqmtJEkcQXkclGdGueEg5NTDpGxyoY zjarlrH84ziYH5+XiPYZDxkRbIxKwMVLLpW7poyUJYR/rMSJXJMP4XmX4 qO4S7SYipKMAhOlqjxUKLHnk9FdE4clD8x+hF33Jn222X24ByesVyCTZZ o=; IronPort-PHdr: =?us-ascii?q?9a23=3AS65EWx8QBz2/9v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgB8mmdd/5NdJa1cCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgWeBRSQsA21WIAQLKgqHXgOKcE2CD36WbIFCgRADVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGDekUCglgjOBMCAwgBAQQBAQECAQYEbYUuDIVKAQEBAQIBAQEQKAY?= =?us-ascii?q?BASwEAgYEBwQCAQgOAwEDAQEfECcLFwYIAgQBEggTB4MBgWoDDg8BAgyeewK?= =?us-ascii?q?BOIhhgiWCfAEBBYUOGIIWAwaBNIt3GIFAP4ERRoIXNT6CYQEBgSYREhqDO4I?= =?us-ascii?q?mlGKIao1QbQkCgh6Gbo1+gjKWK41tgTaGOZBIAgQCBAUCDgEBBYFnIYFYcBU?= =?us-ascii?q?aIYJsgkIJAxeDT4UUhT9ygSmNEQGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,442,1559520000"; d="scan'208";a="320883195" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 09:29:46 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x7T9Tkjx007094 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 09:29:46 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 04:29:45 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 05:29:45 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 05:29:45 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TipjkQ1ZGPqyWhmqXOFEYFvdGr/rY2edTAszAOENs5lYTMLHsx5fH3E59YbP/tFcsaphtAXgyO+6qY++aHxt/BzWNeOaH4GKtNSHSxWc1N8mTQPFPZvpE9lsUMohh5bGJgwajp/0u0ONEOFi4FXImHHAQNOa4Ww3rHwGm2iHvzxPnsMm33wZrvLNaXirKH9S5w/7tAbhX9VGc6MKlC/olebHMzEdSquGBf1EEYWvhQBPUxfUaiNyDrc/aB1tnfaokfE2H6yRzgBgknIWqnmNKsIuAGzOI3N0SGYuha0IpRG4O2xsqmEJKqk2tsaf1t/1dkPdHNKnIAvoixRmHNQdIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhrxnGyJWqE5XKfaYyN0gK63180fUrEdFvVjObJFLlw=; b=T8t2RU4qmTBIIm1mmFz0v4nUR/SpiOYHc0ZTIXFHfnpC1Uto7dg7Hz5MWfw3Hi19Mpt7GvmvspVvjTtvB6WZxo1Bjnn8AOgUUO+md9URkzy6WomYWiBtWg9CFs/o1l7gQgvV6wf14AxhQxqNKTz8Dr2EL8dZSESEUdVtX6NKmP0MjKxR1etjggX9rH5/FNusIX8pikbO/UxwBAVue0LRe15pf+xFkwlyehM4bbw0Dw1zdDnyyQ0wGUKbefkrLqD2ZNGwfzSVP8pX25J9V8fjt92BFB6gkplqENt3ydexzsfyYxGHTxljsyoQxMVa1qK85Hg/GKya3azoOPkBb8M+AA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhrxnGyJWqE5XKfaYyN0gK63180fUrEdFvVjObJFLlw=; b=czolgNpQ0lF1zTLV+pn+b/Cdscj7lJj2e7b1w74MtLoJ6uQhkAv3KqVuVNEB+h4mq9oNI5qAkfyPjSE7zCTI12N0WRmL8y0hokguS+mEplmOP7JSTrpj0nm/9DQGAaod2blMVdQhGhQsy4mIkEYnpeuZrpu0xsF9/6OTepfFuPQ= Received: from BY5PR11MB4355.namprd11.prod.outlook.com (52.132.254.141) by BY5PR11MB3991.namprd11.prod.outlook.com (10.255.160.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.18; Thu, 29 Aug 2019 09:29:43 +0000 Received: from BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4590:1fad:4b16:7abd]) by BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4590:1fad:4b16:7abd%3]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 09:29:43 +0000 From: "Rob Wilton (rwilton)" <rwilton@cisco.com> To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6cF4/wAgAFWQZA= Date: Thu, 29 Aug 2019 09:29:43 +0000 Message-ID: <BY5PR11MB4355684E068D399D3BF2B4ADB5A20@BY5PR11MB4355.namprd11.prod.outlook.com> References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <20190821.155950.1596034237173159188.mbj@tail-f.com> In-Reply-To: <20190821.155950.1596034237173159188.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50accbb3-c8c0-48be-242c-08d72c636cfa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR11MB3991; x-ms-traffictypediagnostic: BY5PR11MB3991: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: <BY5PR11MB3991FDD8E64CC184E14D1148B5A20@BY5PR11MB3991.namprd11.prod.outlook.com> x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(136003)(366004)(199004)(189003)(51444003)(13464003)(51914003)(11346002)(486006)(476003)(446003)(14444005)(71190400001)(71200400001)(256004)(478600001)(6116002)(3846002)(26005)(102836004)(6506007)(53546011)(186003)(7696005)(76176011)(74316002)(305945005)(7736002)(8936002)(8676002)(81166006)(81156014)(14454004)(99286004)(966005)(2501003)(110136005)(316002)(229853002)(86362001)(76116006)(33656002)(66946007)(66476007)(66446008)(64756008)(66556008)(53936002)(9686003)(55016002)(6306002)(25786009)(6246003)(5660300002)(52536014)(66574012)(66066001)(2906002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB3991; H:BY5PR11MB4355.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JOyAqn2Xhf7uPUR+mpY3bnVhEOHN6hijzg9TC6yb/Iwq4DVIvr/emolEUKnEhJCwhUQIuToNVe4wLlNt3RLhbM83sHNAQLLknXsEzC5Kz77LNo1vg2ZkRHZYLT+myh/1fLDaWFjgqJ57Ks3A/pH9ng1s3C51ryQeI6mBBFG4l4nw543NoE4U0i62UxK8AgSYwRq3479kLDTGNWznlNz6q9ZYvYM7EdDfe2D5vRaCD/CBH/8bsfaRgqNq9L/L1UssVTwntIgA7lPjcoQbov0fdmuYR3sJBWVy40xQl234LjDuA8S2MNasTSbrR4/8cCAvFcKWfGEEAMtP+eBo0LT3J0zO0UBpzK5ydSRv9fuD0rzz5BEX6xHYUOi0xqhqf3ILvEEdKpH1iQyMR4vjBoCYlIBt0D+LreilniZtrdiZxWo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50accbb3-c8c0-48be-242c-08d72c636cfa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 09:29:43.5932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a5G2O0k/0MrbmJnkEXvsZztO2cpGlzOdnLKnlsJRA2Nv5591CbZaHRJeZIusf9F9GjquVKVW8ra0TA7px6oXkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3991 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o7LVTVggTAy8aI2t39r_TwYi1-Q> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 09:29:50 -0000 Hi Martin, Thanks for the review. Mostly just updated, a couple of comments/questions= inline below. Latest source XML and txt are at: https://github.com/netmod-wg/interface-ex= tensions-yang/tree/wglc > -----Original Message----- > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund > Sent: 21 August 2019 15:00 > To: netmod@ietf.org > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 >=20 > Hi, >=20 > Here is my (late) review of draft-ietf-netmod-intf-ext-yang-07. It is a > well-written document and my comments are mostly minor. >=20 >=20 > o Abstract >=20 > OLD: >=20 > The YANG data model in this document conforms to the Network > Management Datastore Architecture (NMDA) defined in RFC 8342. >=20 > NEW: >=20 > The YANG modules in this document conform to the Network > Management Datastore Architecture (NMDA) defined in RFC 8342. >=20 OK. >=20 > o Section 1 >=20 > One of the aims of this draft is to provide a standard namespace and > path for these configuration items regardless of the underlying > interface type. For example a standard namespace and path for >=20 > "standard namespace and path" sounds a bit clumsy. In section 2 you > use "standard definition", perhaps that can be use here. >=20 OK.=20 >=20 > o General >=20 > s/this internet draft/this document/g > s/this draft/this document/g >=20 OK. >=20 > o Section 2 >=20 > It seems this short section mostly says what is already said in > section 1. Remove? >=20 At this stage yes, I think that this can be removed. >=20 > o 3 >=20 > The text says: >=20 > o A parent interface leaf useable for all types of sub-interface > that are children of parent interfaces. >=20 > I suggest you add before that bullet: >=20 > o A generic "sub-interface" identity that an interface identity > defintion can derive from if it defines a sub-interface. >=20 OK. >=20 > o 3.1 >=20 > The text says: >=20 > E.g. in the > case that the link state transition is suppressed then there is no > change of the /if:interfaces-state/if:interface/oper-status or > /if:interfaces-state/if:interfaces/last-change leaves for the > interface that the feature is operating on. >=20 > This should be: >=20 > no change of the /if:interfaces/if:interface/oper-status or > /if:interfaces/if:interfaces/last-change leaves for the > interface that the feature is operating on. >=20 OK. >=20 > o 3.2 >=20 > It took me some time to understand the dampening algorithm. Why is > it important to talk about nominal values and that a device doesn't > have to use 1000 as the penalty, as long as they scale the given > values? Wouldn't it be easier to describe the algorithm w/o any > nominal values, and then explain that an implementation is free to > implement this algorithm in any way it wants (which of course is > true for everything we do...) That makes sense. I have tweaked the description. >=20 > Otherwise, the text currently says: >=20 > Implementations are not required to use a penalty of 1000 units in > their dampening algorithm, but should ensure that the Suppress > Threshold and Reuse Threshold values are scaled relative to the > nominal 1000 unit penalty to ensure that the same configuration > values provide consistent behaviour. >=20 > Should "should" in this text be "SHOULD"? Or perhaps "MUST"? >=20 I've just removed this text. As you say above, this is just a definition o= f an API, and vendors are free to implement however they wish as long as th= ey are consistent with the API. >=20 > o 3.2.1 >=20 > The text says: >=20 > When the accumulated penalty reaches the default or > configured suppress threshold, the interface is placed in a dampened > state. >=20 > The term "dampended state" occurs twice, in 3.2.1 and 3.2.3. It is > not used in the YANG model. I suspect the leaf "suppressed" > reflects this. Perhaps align naming. >=20 I've changed this to suppressed. >=20 > o 4 >=20 > It would be useful with a sentence that describes the relationship > to /if:interfaces/if:interface/if:phys-address. >=20 > It seems that the mac-address leaf is useful when the mac address > can be configured; otherwise if:phys-address should be sufficient, > right? Yes, if not configured, it returns the same value as if:phys-address (but c= onstrained to being exactly 6 bytes long). Perhaps a better long term solution here would be to allow if:phys-address = to be configurable, and add a hw-phys-address config false leaf to indicate= the default hardware value? Should the mac-address leaf have a feature, or can we expect > all implementations to support configurable mac addresses? No, I don't think that all Ethernet interfaces will necessarily support con= figurable MAC addresses, e.g. I suspect that a lightbulb or simple home rou= ter probably does not allow it to be configured. But I would expect Linux = and more sophisticated network devices to allow MAC addresses to be configu= red. Hence making this conditional on a feature makes sense. leaf mac-address { type yang:mac-address; description "The MAC address of the interface."; } In terms of the relationship to phy-address, I would suggest the following = update: leaf mac-address { if-feature "configurable-mac-address"; type yang:mac-address; description "The MAC address of the interface. The operational value matches the if:phys-address leaf defined in ietf-interface.yang"; } =20 >=20 >=20 > o 4 >=20 > You add a container 'statistics' under 'ethernet-like', so we have: >=20 > +--rw interfaces > +--rw interface* [name] > ... > +--ro statistics > ... > +--rw ethlike:ethernet-like > +--ro ethlike:statistics > ... >=20 > Did you consider augmenting the container if:statistics instead? I > think it can be useful to have all statistics in the same container > in this case. I think that given that we are only adding one counters and they are probab= ly widely useful for Ethernet interfaces then I think that augmenting the e= xisting statistics container makes sense. I will change this. If we end up defining Ethernet histogram counters (which we are not doing n= ow, and would be a separate draft), then we might want to think carefully w= hether or not to put those counters under the main interface statistics con= tainer, because I suspect that most of the time clients probably won't be i= nterested in those values. >=20 >=20 > o 7.2 >=20 > Perhaps show the (related) 'if:oper-status' leaf as well. >=20 Yes. >=20 > o 7.3 >=20 > Perhaps show the (related) if:phys-address' leaf as well in the > first and third examples. OK. >=20 > Before the second example, perhaps change: >=20 > The following example shows an explicit MAC address being configured > on interface eth0. >=20 > to: >=20 > The following example shows the intended configuration for > interface eth0 with an explicit MAC address being configured. >=20 Fixed. >=20 > o YANG nits >=20 > Both YANG modules list the WG chairs; we don't do that anymore. Fixed. >=20 > Both YANG modules have the IETF Trust Copyright statement, but not > exactly as it should be (try: pyang --ietf and/or pyang --ietf-help) >=20 > Many descriptions are full sentences w/o the ending ".". >=20 Fixed, I think. > The reference in the revision statement should be changed to "RFC > XXXX: <title>" >=20 Fixed. Thanks, Rob >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Aug 29 05:12:00 2019 Return-Path: <noreply@ietf.org> X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A651200D5; Thu, 29 Aug 2019 05:11:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org> To: "The IESG" <iesg@ietf.org> Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger <lberger@labn.net>, netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net> Message-ID: <156708071159.21028.1905801879067407892.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 05:11:51 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jhZJOrpsAktaF9PnrhIdr2dG7wg> Subject: [netmod] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-iet?= =?utf-8?q?f-netmod-artwork-folding-08=3A_=28with_COMMENT=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 12:11:52 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-netmod-artwork-folding-08: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't think this draft is in scope of the charter of the netmod working group. I've seen in the shepherd write-up that input from the RSE was received, therefore I don't necessarily assume that a different publication path would have produced a different outcome and I decided not to block publication, however, given the publication path taken it is not visible to me if sufficient feedback from the right people that are impacted or targeted by this document has been received. In general I don't think it is okay to publish a document that is out-of scope for a working group, especially when the scope of the document impacts other work in the IETF so broadly (while I do understand that this was written with main focus on YANG). Given the current situation I would eventually rather go for informational than BCP. From nobody Thu Aug 29 06:32:11 2019 Return-Path: <barryleiba@gmail.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA11200EF; Thu, 29 Aug 2019 06:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_7Vlvl27LNb; Thu, 29 Aug 2019 06:32:00 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 156A11200B5; Thu, 29 Aug 2019 06:32:00 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id x4so6792318iog.13; Thu, 29 Aug 2019 06:31:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xcH+wgOgQqc9YzTOvnRbdsPUVeCQORHhNw0v1uy1K8E=; b=ANtTOrCPf7Jibuvmbpr2xx49CUidV+Ub2V7/VFzzdSjsg4GD2qzVeeLc41qPvZj4Xv nSp6wfB1i7zWlMMXnrXmOFSBJX+fzP6v59rk3EvwIYSro1fasXyNLH+bALzE0P19DnUw asnw9N0zdg2kbbhRScNMsQhaNQ/q+BVkswor2mBkpAlPPpM16AtSS15/mp88I7N2F/Ar ApNw8VK5EH8gxZT8csHsrEyxy3ay19Bp46Az5gpjkjLcUpj8SrgLTt7vet/ai4+WPyxr p8asFXPOHqsEPW7oG5RtOpGrY/h820buonOIrn78xNmUgX9Vtro12BSTDeR0KfOqNyl9 nCag== X-Gm-Message-State: APjAAAWZGU0+xopzIRydM0WTwUSBDGn6TFbhnTsbZzp374ijz2RASdlt ZycFzyp8O6e4KGZyYOrps4vHQ+ns2CMSxcRYE5Q= X-Google-Smtp-Source: APXvYqwfJp5X88xJ0ZA61qzn4k6omVeOb1tiX9WQ/lXjLtild2UFG+9fczHAWGxrxsBzygqFaAC9vMTeqbYns6b9LkI= X-Received: by 2002:a02:9a12:: with SMTP id b18mr4124016jal.70.1567085518985; Thu, 29 Aug 2019 06:31:58 -0700 (PDT) MIME-Version: 1.0 References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> In-Reply-To: <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> From: Barry Leiba <barryleiba@computer.org> Date: Thu, 29 Aug 2019 09:31:47 -0400 Message-ID: <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> To: Alexey Melnikov <aamelnikov@fastmail.fm> Cc: Kent Watsen <kent+ietf@watsen.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, The IESG <iesg@ietf.org>, Lou Berger <lberger@labn.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HTQPbyBubnp3TTez42viCHF4iRc> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 13:32:02 -0000 The example is set up so that the source is in 9.4, 9.4.1 is the result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" of 9.4. So the original source (in 9.4) was "This line ends with a backslash \". The result of "\ folding" gives "This line ends with a backslash \\", because the backslash had to be escaped. Barry On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov <aamelnikov@fastmail.fm> wr= ote: > > Hi Kent, > > On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: > > Hi Alexey, > > Response at bottom. > > Kent > > > On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker <noreply@iet= f.org> wrote: > > Alexey Melnikov has entered the following ballot position for > draft-ietf-netmod-artwork-folding-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for your document. > > It might be just me, but I think your examples in 9.4.1 with trailing \ d= on=E2=80=99t > seem to match the folding algorithm in section 7, as it doesn=E2=80=99t d= escribe > special handling of trailing \. > > > Can you be more specific regarding what it is you think doesn't match? = Step (2) says, at the location where the fold is to occur, insert '\' follo= wed by '\n'. That appears to be what is shown in 9.4.1, yes? > > > In the HTML version (in datatracker) I am seeing: > > =E2=80=9CThis line ends with a backslash \\=E2=80=9D > > followed by an empty line. So I see 2 trailing \ followed by end of line,= instead of \, end of line, and then \. > > > FWIW, the text in Section 9.4.1 (as with all the examples in the draft) w= as dynamically-generated (at draft build time) by feeding the text in Secti= on 9.4 into the script in the Appendix A. > > Kent // co-author > > From nobody Thu Aug 29 06:37:42 2019 Return-Path: <aamelnikov@fastmail.fm> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD8120071; Thu, 29 Aug 2019 06:37:33 -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, FREEMAIL_FROM=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=fastmail.fm header.b=QscPLXKr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y7s7mcSm 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 8Wf3w_DceQq4; Thu, 29 Aug 2019 06:37:31 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E8512004A; Thu, 29 Aug 2019 06:37:31 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id AE1424F9; Thu, 29 Aug 2019 09:37:30 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 29 Aug 2019 09:37:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm1; bh=HUOTy 1OLe2orS1IThaRK9WNg72qwMTQHtiIrbzqfovE=; b=QscPLXKrnpeDyxN8Su2kb E4jITwDgmKHbAXDmcaNgyLcSUnoIPJ3VOAvigu7H56ELSMFzkJ0LRm/ywoT6s/2l EX3sx+pNywboioYzWKTgZsyyfB6LhN6ZaEyJh9FaG0T5gOMT4PeYnOCPuB8DHpcN 3JxyZGQeJJrTthxf89BPEg3XH2g5lN88bdAEkc4/q8+DEi4g7BUiO29+Z73cNe/P J2XwHzFuOFbB1Gn3SISVZmJf35VokAg/7YS2+jLaK4ShER9b8K7c9UD1kigYkn7h EInGVTK/qoLXUgo8zyjyUFQOY3iAnoBE0ipIxe60xJYqD1CevVlaCUX37o/WbsmU g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=HUOTy1OLe2orS1IThaRK9WNg72qwMTQHtiIrbzqfo vE=; b=y7s7mcSm03Xb7lPYS+AbT8CJNUu2t6aUOWsIUlLml5wZ/fyasyerVDwlC 4nYDJOHnFu98ZmlXnKRgZacZadqimePhJ8ASVBLL1RGFJgIhnT0kJ0nl5JRJJb37 sESXo7zVQJlub9pXU+d/cVEHa8QZ9SugJXENJfbnGqcXzWaWZfNdPm72H0It471g cSrdD+LjqeNN7pd6e77RVcfoksJOpF+nnSZm+1A5se+EePpTZpQoIeJtTUmeb5Qh OeL+Iq4KsN91NHGgoLdm+s+Pvo/1Y8p3kSmAKDAk3f+XxW2s8LwsbhmlyZh3pwNc v4xAYyvhhMlOAEFS1zxmbOZxRW0ww== X-ME-Sender: <xms:GdVnXS2cLaZenLic_oqejGWiuUwEkLy14hIqmi-SKa2-gc0w83m_bA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeivddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: <xmx:GdVnXctIEi-QsDvUl5jfRI2YIgFIrmStXVoX9cikvmaX1Li6mhOpCg> <xmx:GdVnXYhbvCvuSLxNgfo_INvCpNseXx7OvOZvqoYt38VdGt4PivVqLg> <xmx:GdVnXd_mW75r09sMjMuoPzeyg1qglj5ofC9BHgI9oQpCJelSi91LHw> <xmx:GtVnXQL7foMoihePUhkDM09UT__fTS2pKjTJOfemjP1zN2SkkpZG0A> Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9D254C200A5; Thu, 29 Aug 2019 09:37:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-154-gfa7592a-fmstable-20190829v1 Mime-Version: 1.0 Message-Id: <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> In-Reply-To: <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> Date: Thu, 29 Aug 2019 14:36:11 +0100 From: "Alexey Melnikov" <aamelnikov@fastmail.fm> To: "Barry Leiba" <barryleiba@computer.org> Cc: "Kent Watsen" <kent+ietf@watsen.net>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, "The IESG" <iesg@ietf.org>, "Lou Berger" <lberger@labn.net> Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/oxWNTmpmLRvHFWJ8i-xdMPZ3w5M> Subject: Re: [netmod] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-net?= =?utf-8?q?mod-artwork-folding-08=3A_=28with_DISCUSS=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 13:37:33 -0000 On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote: > The example is set up so that the source is in 9.4, 9.4.1 is the > result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" > of 9.4. >=20 > So the original source (in 9.4) was "This line ends with a backslash \= ". > The result of "\ folding" gives "This line ends with a backslash \\", > because the backslash had to be escaped. But the algorithm described in prose says absolutely nothing about escap= ing trailing "\"! So why the example is Ok, it just doesn't match the fo= lding algorithm. > Barry >=20 > On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov <aamelnikov@fastmail.f= m> wrote: > > > > Hi Kent, > > > > On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: > > > > Hi Alexey, > > > > Response at bottom. > > > > Kent > > > > > > On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker <norepl= y@ietf.org> wrote: > > > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-netmod-artwork-folding-08: Discuss > > > > When responding, please keep the subject line intact and reply to al= l > > email addresses included in the To and CC lines. (Feel free to cut t= his > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= .html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > > > > > > > --------------------------------------------------------------------= -- > > DISCUSS: > > --------------------------------------------------------------------= -- > > > > Thank you for your document. > > > > It might be just me, but I think your examples in 9.4.1 with trailin= g \ don=E2=80=99t > > seem to match the folding algorithm in section 7, as it doesn=E2=80=99= t describe > > special handling of trailing \. > > > > > > Can you be more specific regarding what it is you think doesn't matc= h? Step (2) says, at the location where the fold is to occur, insert '= \' followed by '\n'. That appears to be what is shown in 9.4.1, yes? > > > > > > In the HTML version (in datatracker) I am seeing: > > > > =E2=80=9CThis line ends with a backslash \\=E2=80=9D > > > > followed by an empty line. So I see 2 trailing \ followed by end of = line, instead of \, end of line, and then \. > > > > > > FWIW, the text in Section 9.4.1 (as with all the examples in the dra= ft) was dynamically-generated (at draft build time) by feeding the text = in Section 9.4 into the script in the Appendix A. > > > > Kent // co-author > > > > > From nobody Thu Aug 29 06:39:30 2019 Return-Path: <0100016cdd99dcf3-5dcc1baf-bbcb-46ab-aa22-e2818c28dddc-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE67B120123; Thu, 29 Aug 2019 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 evA_lFv8h412; Thu, 29 Aug 2019 06:39:06 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D4912081C; Thu, 29 Aug 2019 06:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567085944; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=8g2T+DrGANWeQCiPXPCV0BpM1yFZHy2pKpISxAIF9Os=; b=Zj045w5I+wuzcY7m0sjOG5d4JphpT5CoxYFRDwL1fy/Z2UskYmYf9pwdIxsM85Jg 6RG8NBMHS2P0J2XViCzH6u/8yEvporwpaLnYsGbiqLd0gD/R0I1iQYppk8b6H5UYWJ6 c6HlhnelXJgZFZl5aYPr/OepGQY9PqyOzASrMmok= From: Kent Watsen <kent+ietf@watsen.net> Message-ID: <0100016cdd99dcf3-5dcc1baf-bbcb-46ab-aa22-e2818c28dddc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AC973797-E66B-4429-A8A8-7490ACC92D79" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 13:39:04 +0000 In-Reply-To: <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, The IESG <iesg@ietf.org>, Lou Berger <lberger@labn.net> To: Barry Leiba <barryleiba@computer.org> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.29-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vrsSf3gcuXQpnWDgkSZEKeaVmfM> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 13:39:20 -0000 --Apple-Mail=_AC973797-E66B-4429-A8A8-7490ACC92D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Correct and, to be even more clear, the location where the fold occurred = was between the '\' and '\n' in the original input, thus producing the = sequence: '\' + '\' + '\n' + '\n', where the first and last characters = are from the input and the inner-two characters were introduced by the = folding process. Alexey, does this explanation clear your DISCUSS? Kent // co-author > On Aug 29, 2019, at 9:31 AM, Barry Leiba <barryleiba@computer.org> = wrote: >=20 > The example is set up so that the source is in 9.4, 9.4.1 is the > result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" > of 9.4. >=20 > So the original source (in 9.4) was "This line ends with a backslash = \". > The result of "\ folding" gives "This line ends with a backslash \\", > because the backslash had to be escaped. >=20 > Barry >=20 > On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov = <aamelnikov@fastmail.fm> wrote: >>=20 >> Hi Kent, >>=20 >> On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: >>=20 >> Hi Alexey, >>=20 >> Response at bottom. >>=20 >> Kent >>=20 >>=20 >> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <noreply@ietf.org> wrote: >>=20 >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-netmod-artwork-folding-08: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thank you for your document. >>=20 >> It might be just me, but I think your examples in 9.4.1 with trailing = \ don=E2=80=99t >> seem to match the folding algorithm in section 7, as it doesn=E2=80=99t= describe >> special handling of trailing \. >>=20 >>=20 >> Can you be more specific regarding what it is you think doesn't = match? Step (2) says, at the location where the fold is to occur, = insert '\' followed by '\n'. That appears to be what is shown in 9.4.1, = yes? >>=20 >>=20 >> In the HTML version (in datatracker) I am seeing: >>=20 >> =E2=80=9CThis line ends with a backslash \\=E2=80=9D >>=20 >> followed by an empty line. So I see 2 trailing \ followed by end of = line, instead of \, end of line, and then \. >>=20 >>=20 >> FWIW, the text in Section 9.4.1 (as with all the examples in the = draft) was dynamically-generated (at draft build time) by feeding the = text in Section 9.4 into the script in the Appendix A. >>=20 >> Kent // co-author >>=20 >>=20 --Apple-Mail=_AC973797-E66B-4429-A8A8-7490ACC92D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D"">Correct and, to be even more clear, the location where the = fold occurred was between the '\' and '\n' in the original input, thus = producing the sequence: '\' + '\' + '\n' + '\n', where the first and = last characters are from the input and the inner-two characters were = introduced by the folding process.<div class=3D""><br = class=3D""></div><div class=3D"">Alexey, does this explanation clear = your DISCUSS?<div class=3D""><br class=3D""></div><div class=3D"">Kent = // co-author</div><div class=3D""><br class=3D""></div><div class=3D""><br= class=3D""><div class=3D""><br class=3D""><div><br class=3D""><blockquote= type=3D"cite" class=3D""><div class=3D"">On Aug 29, 2019, at 9:31 AM, = Barry Leiba <<a href=3D"mailto:barryleiba@computer.org" = class=3D"">barryleiba@computer.org</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">The = example is set up so that the source is in 9.4, 9.4.1 is the<br = class=3D"">result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ = folding"<br class=3D"">of 9.4.<br class=3D""><br class=3D"">So the = original source (in 9.4) was "This line ends with a backslash \".<br = class=3D"">The result of "\ folding" gives "This line ends with a = backslash \\",<br class=3D"">because the backslash had to be escaped.<br = class=3D""><br class=3D"">Barry<br class=3D""><br class=3D"">On Thu, Aug = 29, 2019 at 4:55 AM Alexey Melnikov <<a = href=3D"mailto:aamelnikov@fastmail.fm" = class=3D"">aamelnikov@fastmail.fm</a>> wrote:<br class=3D""><blockquote= type=3D"cite" class=3D""><br class=3D"">Hi Kent,<br class=3D""><br = class=3D"">On 28 Aug 2019, at 23:03, Kent Watsen <<a = href=3D"mailto:kent+ietf@watsen.net" = class=3D"">kent+ietf@watsen.net</a>> wrote:<br class=3D""><br = class=3D"">Hi Alexey,<br class=3D""><br class=3D"">Response at = bottom.<br class=3D""><br class=3D"">Kent<br class=3D""><br class=3D""><br= class=3D"">On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <<a href=3D"mailto:noreply@ietf.org" = class=3D"">noreply@ietf.org</a>> wrote:<br class=3D""><br = class=3D"">Alexey Melnikov has entered the following ballot position = for<br class=3D"">draft-ietf-netmod-artwork-folding-08: Discuss<br = class=3D""><br class=3D"">When responding, please keep the subject line = intact and reply to all<br class=3D"">email addresses included in the To = and CC lines. (Feel free to cut this<br class=3D"">introductory = paragraph, however.)<br class=3D""><br class=3D""><br class=3D"">Please = refer to <a = href=3D"https://www.ietf.org/iesg/statement/discuss-criteria.html" = class=3D"">https://www.ietf.org/iesg/statement/discuss-criteria.html</a><b= r class=3D"">for more information about IESG DISCUSS and COMMENT = positions.<br class=3D""><br class=3D""><br class=3D"">The document, = along with other ballot positions, can be found here:<br class=3D""><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding= /" = class=3D"">https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/</a><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">---------------------------------------------------------------= -------<br class=3D"">DISCUSS:<br = class=3D"">---------------------------------------------------------------= -------<br class=3D""><br class=3D"">Thank you for your document.<br = class=3D""><br class=3D"">It might be just me, but I think your examples = in 9.4.1 with trailing \ don=E2=80=99t<br class=3D"">seem to match the = folding algorithm in section 7, as it doesn=E2=80=99t describe<br = class=3D"">special handling of trailing \.<br class=3D""><br = class=3D""><br class=3D"">Can you be more specific regarding what it is = you think doesn't match?   Step (2) says, at the location = where the fold is to occur, insert '\' followed by '\n'.  That = appears to be what is shown in 9.4.1, yes?<br class=3D""><br = class=3D""><br class=3D"">In the HTML version (in datatracker) I am = seeing:<br class=3D""><br class=3D"">=E2=80=9CThis line ends with a = backslash \\=E2=80=9D<br class=3D""><br class=3D"">followed by an empty = line. So I see 2 trailing \ followed by end of line, instead of \, end = of line, and then \.<br class=3D""><br class=3D""><br class=3D"">FWIW, = the text in Section 9.4.1 (as with all the examples in the draft) was = dynamically-generated (at draft build time) by feeding the text in = Section 9.4 into the script in the Appendix A.<br class=3D""><br = class=3D"">Kent  // co-author<br class=3D""><br class=3D""><br = class=3D""></blockquote></div></div></blockquote></div><br = class=3D""></div></div></div></body></html>= --Apple-Mail=_AC973797-E66B-4429-A8A8-7490ACC92D79-- From nobody Thu Aug 29 06:44:49 2019 Return-Path: <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A41F1200DF; Thu, 29 Aug 2019 06:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 EmYBd3cI2ICo; Thu, 29 Aug 2019 06:44:37 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DC812008D; Thu, 29 Aug 2019 06:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567086275; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6RlosOP5G593qawjkf7AoO5OPP3w+GcBqUndo4BTrmw=; b=m9jJCW3T6cxr+qaOgockzIlNeN9t4IeHe45Qh7Wt/BJv7WqPs9c8eBy3IvsgA8Oe rpkYomgbOtc3YVq6s0k+PJLG8E22ChLdpSdyV2ft6TnEpel2S1bKmrImrcqkrOWizcz vypkuSSCuaHxXRQ7qJUnW3zTmi3ibv/crSNNLyUk= From: Kent Watsen <kent+ietf@watsen.net> Message-ID: <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7C5407D-D14F-447C-BF0B-7C7485CFBEAC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 13:44:35 +0000 In-Reply-To: <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> Cc: Barry Leiba <barryleiba@computer.org>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, The IESG <iesg@ietf.org>, Lou Berger <lberger@labn.net> To: Alexey Melnikov <aamelnikov@fastmail.fm> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.29-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NT9SlfiafTLcZA5xvkIunrISvDg> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 13:44:40 -0000 --Apple-Mail=_E7C5407D-D14F-447C-BF0B-7C7485CFBEAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 29, 2019, at 9:36 AM, Alexey Melnikov <aamelnikov@fastmail.fm> = wrote: >=20 > On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote: >> The example is set up so that the source is in 9.4, 9.4.1 is the >> result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" >> of 9.4. >>=20 >> So the original source (in 9.4) was "This line ends with a backslash = \". >> The result of "\ folding" gives "This line ends with a backslash \\", >> because the backslash had to be escaped. >=20 > But the algorithm described in prose says absolutely nothing about = escaping trailing "\"! So why the example is Ok, it just doesn't match = the folding algorithm. The word "escape" is a bit misleading, even though, in a way, that is = what is happening (e.g., working around a special character), but it's = not "escaping" in the traditional sense (i.e., the first '\' is in no = way giving special significance to the second '\'). What's really going = on is better described as a forced folding on a line that contains an = invalid end-of-line sequence. Makes sense? Kent // co-author >=20 >> Barry >>=20 >> On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov = <aamelnikov@fastmail.fm> wrote: >>>=20 >>> Hi Kent, >>>=20 >>> On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: >>>=20 >>> Hi Alexey, >>>=20 >>> Response at bottom. >>>=20 >>> Kent >>>=20 >>>=20 >>> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <noreply@ietf.org> wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-netmod-artwork-folding-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Thank you for your document. >>>=20 >>> It might be just me, but I think your examples in 9.4.1 with = trailing \ don=E2=80=99t >>> seem to match the folding algorithm in section 7, as it doesn=E2=80=99= t describe >>> special handling of trailing \. >>>=20 >>>=20 >>> Can you be more specific regarding what it is you think doesn't = match? Step (2) says, at the location where the fold is to occur, = insert '\' followed by '\n'. That appears to be what is shown in 9.4.1, = yes? >>>=20 >>>=20 >>> In the HTML version (in datatracker) I am seeing: >>>=20 >>> =E2=80=9CThis line ends with a backslash \\=E2=80=9D >>>=20 >>> followed by an empty line. So I see 2 trailing \ followed by end of = line, instead of \, end of line, and then \. >>>=20 >>>=20 >>> FWIW, the text in Section 9.4.1 (as with all the examples in the = draft) was dynamically-generated (at draft build time) by feeding the = text in Section 9.4 into the script in the Appendix A. >>>=20 >>> Kent // co-author >>>=20 >>>=20 >>=20 --Apple-Mail=_E7C5407D-D14F-447C-BF0B-7C7485CFBEAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Aug 29, 2019, at 9:36 AM, Alexey Melnikov <<a = href=3D"mailto:aamelnikov@fastmail.fm" = class=3D"">aamelnikov@fastmail.fm</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">On = Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote:<br = class=3D""><blockquote type=3D"cite" class=3D"">The example is set up so = that the source is in 9.4, 9.4.1 is the<br class=3D"">result of "\ = folding" of 9.4, and 9.4.2 is the result of "\\ folding"<br class=3D"">of = 9.4.<br class=3D""><br class=3D"">So the original source (in 9.4) was = "This line ends with a backslash \".<br class=3D"">The result of "\ = folding" gives "This line ends with a backslash \\",<br class=3D"">because= the backslash had to be escaped.<br class=3D""></blockquote><br = class=3D"">But the algorithm described in prose says absolutely nothing = about escaping trailing "\"! So why the example is Ok, it just doesn't = match the folding algorithm.<br = class=3D""></div></div></blockquote><div><br class=3D""></div><div>The = word "escape" is a bit misleading, even though, in a way, that is what = is happening (e.g., working around a special character), but it's not = "escaping" in the traditional sense (i.e., the first '\' is in no way = giving special significance to the second '\').  What's really = going on is better described as a forced folding on a line that contains = an invalid end-of-line sequence.  Makes sense?</div><div><br = class=3D""></div><div>Kent // co-author</div><div><br class=3D""></div><br= class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">Barry<br = class=3D""><br class=3D"">On Thu, Aug 29, 2019 at 4:55 AM Alexey = Melnikov <<a href=3D"mailto:aamelnikov@fastmail.fm" = class=3D"">aamelnikov@fastmail.fm</a>> wrote:<br class=3D""><blockquote= type=3D"cite" class=3D""><br class=3D"">Hi Kent,<br class=3D""><br = class=3D"">On 28 Aug 2019, at 23:03, Kent Watsen <<a = href=3D"mailto:kent+ietf@watsen.net" = class=3D"">kent+ietf@watsen.net</a>> wrote:<br class=3D""><br = class=3D"">Hi Alexey,<br class=3D""><br class=3D"">Response at = bottom.<br class=3D""><br class=3D"">Kent<br class=3D""><br class=3D""><br= class=3D"">On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <<a href=3D"mailto:noreply@ietf.org" = class=3D"">noreply@ietf.org</a>> wrote:<br class=3D""><br = class=3D"">Alexey Melnikov has entered the following ballot position = for<br class=3D"">draft-ietf-netmod-artwork-folding-08: Discuss<br = class=3D""><br class=3D"">When responding, please keep the subject line = intact and reply to all<br class=3D"">email addresses included in the To = and CC lines. (Feel free to cut this<br class=3D"">introductory = paragraph, however.)<br class=3D""><br class=3D""><br class=3D"">Please = refer to <a = href=3D"https://www.ietf.org/iesg/statement/discuss-criteria.html" = class=3D"">https://www.ietf.org/iesg/statement/discuss-criteria.html</a><b= r class=3D"">for more information about IESG DISCUSS and COMMENT = positions.<br class=3D""><br class=3D""><br class=3D"">The document, = along with other ballot positions, can be found here:<br class=3D""><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding= /" = class=3D"">https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/</a><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">---------------------------------------------------------------= -------<br class=3D"">DISCUSS:<br = class=3D"">---------------------------------------------------------------= -------<br class=3D""><br class=3D"">Thank you for your document.<br = class=3D""><br class=3D"">It might be just me, but I think your examples = in 9.4.1 with trailing \ don=E2=80=99t<br class=3D"">seem to match the = folding algorithm in section 7, as it doesn=E2=80=99t describe<br = class=3D"">special handling of trailing \.<br class=3D""><br = class=3D""><br class=3D"">Can you be more specific regarding what it is = you think doesn't match?   Step (2) says, at the location = where the fold is to occur, insert '\' followed by '\n'.  That = appears to be what is shown in 9.4.1, yes?<br class=3D""><br = class=3D""><br class=3D"">In the HTML version (in datatracker) I am = seeing:<br class=3D""><br class=3D"">=E2=80=9CThis line ends with a = backslash \\=E2=80=9D<br class=3D""><br class=3D"">followed by an empty = line. So I see 2 trailing \ followed by end of line, instead of \, end = of line, and then \.<br class=3D""><br class=3D""><br class=3D"">FWIW, = the text in Section 9.4.1 (as with all the examples in the draft) was = dynamically-generated (at draft build time) by feeding the text in = Section 9.4 into the script in the Appendix A.<br class=3D""><br = class=3D"">Kent  // co-author<br class=3D""><br class=3D""><br = class=3D""></blockquote><br = class=3D""></blockquote></div></div></blockquote></div><br = class=3D""></body></html>= --Apple-Mail=_E7C5407D-D14F-447C-BF0B-7C7485CFBEAC-- From nobody Thu Aug 29 06:45:55 2019 Return-Path: <aamelnikov@fastmail.fm> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8106E120071; Thu, 29 Aug 2019 06:45:43 -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=fastmail.fm header.b=fyoDgieD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l2Meucwe 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 Mwj9h0Vswllu; Thu, 29 Aug 2019 06:45:41 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205C012004A; Thu, 29 Aug 2019 06:45:41 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 0F1E74D3; Thu, 29 Aug 2019 09:45:39 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 29 Aug 2019 09:45:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=0YnBkahII+DjLQgfvmMVyWQhXAKv0KF 8ykS1IsOeAYw=; b=fyoDgieDfx9fz5mWMCi8CaYnLvZPE0wc/Y+ZweV9rvzq3Nj Lpb0gANLIJULuscN7NxEvi5IUrUhJt/KAf8wFofyhC+HERoM//gYquuw+LpPetJp b+SLCiDLyxC68aUaC2D13vQxXkKax34vIzLUUu6vexyuEDCrrFt/UAkFz16hIiwP 9zRZ+MVk1UlY7cg+9rkc+aKET0ehVB5d3R6BymFgAiFtmyCtc9davsjYHaKR7Fto 7HlX/ehhgACkH/dd9VkJUPkfXQJJXePJTMUXyPE2yBJj6g2fgR3Lh7SxXZwmysKP iIH3AGszowWpBhIhHYkK0GNBgG6wa1zNraNH+4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=0YnBka hII+DjLQgfvmMVyWQhXAKv0KF8ykS1IsOeAYw=; b=l2MeucweHvXYe9RwldjxnI D1PTGp7RaMxDXYjR69RXmGWqV/sCKh+k0dRTzR22kt5hJHcUxvzFrHOIF8D3ikyu u2/QNjGIUf2edAQI6C9i+/Epz8N2enRhPwskDphFkTDOVmfGpzNUa+ygg451iV0U kH2o5Dt/7NN5Mzu1ARVIXqt0qQ4bpUKKIGa69rOCNyjmPINr1ucENzzgoK5L/2iO P73aJoL2aF4j0FV6wxoTLQA1isYEtnxA5JnawhCPHdHsLWkpn1e4jtzyEi9XHmuO +/c6YRzBIiZhb4uZe329TIAzcKTBMpqYDSp9BoXT7FHQJhL6+tIvjB+GnXtr2xrg == X-ME-Sender: <xms:A9dnXV0Hk9yB29cIj8C5RgB8RWfexnETJC5Zmnw3dHQzC2VohaZ-nA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeivddgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhho mheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: <xmx:A9dnXc25ZrS5uUWBzPRtnuSfHeCRKwDn--mOQVuBW-LgrgOgBnGmXw> <xmx:A9dnXex5bFfDbuzlk3Q9Ib_rZVQ3l0U1POigW1m5S87509LMPmsxKg> <xmx:A9dnXauH6AHND16VJBL5mnMyqgOdKPx3y2izPU1o41BbJOkrudG5Ig> <xmx:A9dnXZBabPrjpZLcmBK8jj4jW3T8ADFDmKbdrQUYr-oaadUEoAKYRw> Received: by mailuser.nyi.internal (Postfix, from userid 501) id 69C00C200A5; Thu, 29 Aug 2019 09:45:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-154-gfa7592a-fmstable-20190829v1 Mime-Version: 1.0 Message-Id: <fc6e84d6-b79f-4127-bfb0-26711fadee29@www.fastmail.com> In-Reply-To: <0100016cdd99dcf3-5dcc1baf-bbcb-46ab-aa22-e2818c28dddc-000000@email.amazonses.com> References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <CALaySJJRm0BHrRBaaUB+cmMa2uhtzLvN_AinRHSw0Co6TVWPDQ@mail.gmail.com> <0100016cdd99dcf3-5dcc1baf-bbcb-46ab-aa22-e2818c28dddc-000000@email.amazonses.com> Date: Thu, 29 Aug 2019 14:44:22 +0100 From: "Alexey Melnikov" <aamelnikov@fastmail.fm> To: "Kent Watsen" <kent+ietf@watsen.net>, "Barry Leiba" <barryleiba@computer.org> Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, "The IESG" <iesg@ietf.org>, "Lou Berger" <lberger@labn.net> Content-Type: multipart/alternative; boundary=576ca74011364595a647d8f20500f286 Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-3tGbaU9YqzJbC5RiW2VA3Rqsf4> Subject: Re: [netmod] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-net?= =?utf-8?q?mod-artwork-folding-08=3A_=28with_DISCUSS=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 13:45:44 -0000 --576ca74011364595a647d8f20500f286 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 29, 2019, at 2:39 PM, Kent Watsen wrote: > Correct and, to be even more clear, the location where the fold occurr= ed was between the '\' and '\n' in the original input, thus producing th= e sequence: '\' + '\' + '\n' + '\n', where the first and last characters= are from the input and the inner-two characters were introduced by the = folding process. Hmm, Ok. That is not how I understood your folding algorithm, so I think= this is not very clear. > Alexey, does this explanation clear your DISCUSS? I would clear, but I suggest you should add more text explaining this. Best Regards, Alexey > Kent // co-author >=20 >> On Aug 29, 2019, at 9:31 AM, Barry Leiba <barryleiba@computer.org> wr= ote: >>=20 >> The example is set up so that the source is in 9.4, 9.4.1 is the >> result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding"= >> of 9.4. >>=20 >> So the original source (in 9.4) was "This line ends with a backslash = \". >> The result of "\ folding" gives "This line ends with a backslash \\",= >> because the backslash had to be escaped. >>=20 >> Barry >>=20 >> On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov <aamelnikov@fastmail.= fm> wrote: >>>=20 >>> Hi Kent, >>>=20 >>> On 28 Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote: >>>=20 >>> Hi Alexey, >>>=20 >>> Response at bottom. >>>=20 >>> Kent >>>=20 >>>=20 >>> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker <norepl= y@ietf.org> wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-netmod-artwork-folding-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to al= l >>> email addresses included in the To and CC lines. (Feel free to cut t= his >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= .html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>>=20 >>>=20 >>>=20 >>> --------------------------------------------------------------------= -- >>> DISCUSS: >>> --------------------------------------------------------------------= -- >>>=20 >>> Thank you for your document. >>>=20 >>> It might be just me, but I think your examples in 9.4.1 with trailin= g \ don=E2=80=99t >>> seem to match the folding algorithm in section 7, as it doesn=E2=80=99= t describe >>> special handling of trailing \. >>>=20 >>>=20 >>> Can you be more specific regarding what it is you think doesn't matc= h? Step (2) says, at the location where the fold is to occur, insert '\'= followed by '\n'. That appears to be what is shown in 9.4.1, yes? >>>=20 >>>=20 >>> In the HTML version (in datatracker) I am seeing: >>>=20 >>> =E2=80=9CThis line ends with a backslash \\=E2=80=9D >>>=20 >>> followed by an empty line. So I see 2 trailing \ followed by end of = line, instead of \, end of line, and then \. >>>=20 >>>=20 >>> FWIW, the text in Section 9.4.1 (as with all the examples in the dra= ft) was dynamically-generated (at draft build time) by feeding the text = in Section 9.4 into the script in the Appendix A. >>>=20 >>> Kent // co-author >>>=20 --576ca74011364595a647d8f20500f286 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><title>
Hi,
<= br>
On Thu, Aug 29, 2019, at 2:39 PM, Kent Watsen wrote:
Correct and, to be even mor= e clear, the location where the fold occurred was between the '\' and '\= n' in the original input, thus producing the sequence: '\' + '\' + '\n' = + '\n', where the first and last characters are from the input and the i= nner-two characters were introduced by the folding process.

Hmm, Ok. That is not how I understood your= folding algorithm, so I think this is not very clear.
Alexey, do= es this explanation clear your DISCUSS?

<= /div>
I would clear, but I suggest you should add more text explaini= ng this.

Best Regards,
Alexey=

Kent // co-author
<= br>
On Aug 29, 2019, at 9:31 AM, Barr= y Leiba <bar= ryleiba@computer.org> wrote:

The example is set up so that the source i= s in 9.4, 9.4.1 is the
result of "\ folding" of 9.4, and 9= .4.2 is the result of "\\ folding"
of 9.4.
<= br>
So the original source (in 9.4) was "This line ends with a= backslash \".
The result of "\ folding" gives "This line = ends with a backslash \\",
because the backslash had to be= escaped.

Barry

On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov <aamelnikov@fastmail.fm> wro= te:

Hi Kent,

On 28 Aug 2019, at 23:03, Kent Wa= tsen <kent+ietf= @watsen.net> wrote:

Hi Alexey,

Response at bottom.

Kent


On Aug 28, 2019, at 2:= 50 PM, Alexey Melnikov via Datatracker <noreply@ietf.org> wrote:

<= /div>
Alexey Melnikov has entered the following ballot position for<= br>
draft-ietf-netmod-artwork-folding-08: Discuss

When responding, please keep the subject line intact an= d reply to all
email addresses included in the To and CC l= ines. (Feel free to cut this
introductory paragraph, howev= er.)


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


The document, along with oth= er ballot positions, can be found here:



<= div>DISCUSS:



--576ca74011364595a647d8f20500f286-- From nobody Thu Aug 29 06:47:17 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE90120071; Thu, 29 Aug 2019 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfcYYzm1Jfl5; Thu, 29 Aug 2019 06:47:13 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 CA26512004A; Thu, 29 Aug 2019 06:47:13 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id q12so7030871iog.4; Thu, 29 Aug 2019 06:47:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RkW6TUi99lghqLQ6DDfsR9aG0Dlmo6E5hgt4ud+lGFA=; b=d7+7bL1iJkWhFg7PWXfF+KoaSotc0fDt9EculM8jpOfgVxeiLsbDDpVd+G1sAjQmMs RX0DK10AsE3/63JerCwpZe12HGHPeI7g47+UbA4zMu1LCvIq4osjoAyXj0hrxGiFfmSk v6IqYrpWMVrkgJ9EIYpEFo7lpo660lGL/WUTS0bZ5LHtmTlgjJyYUNEzx+adPrEY+Sxf /j3C/Y2nnLmqD/OeTmSvGqrqlgxNQrWMtdgbj75cQ6h++jfw0A8OYibBqCVJhi90Di3Q bJec7zT7GwwNyROObaqV5NlcRNx5QjLn3wA7kWEvRziiqmySD4Zh1oHsly6jTDw+zVXv GprA== X-Gm-Message-State: APjAAAVIBcKH7fJuSJeuLrVABzNW7/ywScdEixoFlF88fSMVqB9Ai5hN ekfBG8peOtg6zSKEU55yR/9C7H1MV99NdJ7Y9Sw= X-Google-Smtp-Source: APXvYqxjqy1+D3G2T8Rw57pGNlOMf8vvHDKc003uhZt4opsYKoZG+ZvdIvdo0Ky9Dj6X6M9zFXijKZm2mImGy3EpM2M= X-Received: by 2002:a02:37c6:: with SMTP id r189mr10725156jar.118.1567086432840; Thu, 29 Aug 2019 06:47:12 -0700 (PDT) MIME-Version: 1.0 References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@email.amazonses.com> In-Reply-To: <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@email.amazonses.com> From: Barry Leiba Date: Thu, 29 Aug 2019 09:47:01 -0400 Message-ID: To: Kent Watsen Cc: Alexey Melnikov , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, The IESG , Lou Berger Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 13:47:16 -0000 You're saying, then, that "This line ends with a backslash \\[EOL][EOL]" only loses the last "\" in unfolding, because there is no space character on the next line. Is that right? If so, Alexey is right that the algorithm doesn't say that. Barry On Thu, Aug 29, 2019 at 9:44 AM Kent Watsen wrote: > > > > On Aug 29, 2019, at 9:36 AM, Alexey Melnikov wro= te: > > On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote: > > The example is set up so that the source is in 9.4, 9.4.1 is the > result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" > of 9.4. > > So the original source (in 9.4) was "This line ends with a backslash \". > The result of "\ folding" gives "This line ends with a backslash \\", > because the backslash had to be escaped. > > > But the algorithm described in prose says absolutely nothing about escapi= ng trailing "\"! So why the example is Ok, it just doesn't match the foldin= g algorithm. > > > The word "escape" is a bit misleading, even though, in a way, that is wha= t is happening (e.g., working around a special character), but it's not "es= caping" in the traditional sense (i.e., the first '\' is in no way giving s= pecial significance to the second '\'). What's really going on is better d= escribed as a forced folding on a line that contains an invalid end-of-line= sequence. Makes sense? > > Kent // co-author > > > > Barry > > On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov = wrote: > > > Hi Kent, > > On 28 Aug 2019, at 23:03, Kent Watsen wrote: > > Hi Alexey, > > Response at bottom. > > Kent > > > On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker wrote: > > Alexey Melnikov has entered the following ballot position for > draft-ietf-netmod-artwork-folding-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for your document. > > It might be just me, but I think your examples in 9.4.1 with trailing \ d= on=E2=80=99t > seem to match the folding algorithm in section 7, as it doesn=E2=80=99t d= escribe > special handling of trailing \. > > > Can you be more specific regarding what it is you think doesn't match? = Step (2) says, at the location where the fold is to occur, insert '\' follo= wed by '\n'. That appears to be what is shown in 9.4.1, yes? > > > In the HTML version (in datatracker) I am seeing: > > =E2=80=9CThis line ends with a backslash \\=E2=80=9D > > followed by an empty line. So I see 2 trailing \ followed by end of line,= instead of \, end of line, and then \. > > > FWIW, the text in Section 9.4.1 (as with all the examples in the draft) w= as dynamically-generated (at draft build time) by feeding the text in Secti= on 9.4 into the script in the Appendix A. > > Kent // co-author > > > > From nobody Thu Aug 29 09:20:14 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8207F12096D for ; Thu, 29 Aug 2019 09:20:12 -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 header.b=IObQldHg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t7xGkz2e 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 CYMzqaQx9R8w for ; Thu, 29 Aug 2019 09:20:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8953F1200B8 for ; Thu, 29 Aug 2019 09:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33164; q=dns/txt; s=iport; t=1567095607; x=1568305207; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hSK6pcEejk9RzqSDvmo9qSTtc2F1kSuXY+39a/rJPVY=; b=IObQldHgwOKMYETLrlc6vGy3I8BYoF/3u5lpphD2M85d84xrCrKu79E3 mPfIlD6AjHPFO7B3NYTIRb/P7x72YE4pW0eWESUiWQwaCxdUrPEl1Tkgw YdDK05OwjBBSr9amarFuwbU/6wm0DYF+emYpqZl4RwkaJyGAlM+nln/On c=; IronPort-PHdr: =?us-ascii?q?9a23=3AXui6uxBK8X+Zjnn58v42UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AAC9+mdd/4gNJK1dAwYaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFWAgEBAQELAYFEUANtViAECyoKhBdigmUDinBNgg+XaoJ?= =?us-ascii?q?SA1QJAQEBDAEBJQgCAQGEPwIXgkIjNwYOAgMIAQEEAQEBAgEGBG2FLgyFSgE?= =?us-ascii?q?BAQECARIICQQNDAEBJQsIBAcEAgEGAhEEAQEBAgImAgICMBUICAIEARIIGoM?= =?us-ascii?q?BgWoDDg8BAgyPMpBhAoE4iGFzfzOCfAEBBYEyAYNZGIIWAwaBDCgBi3YYgUA?= =?us-ascii?q?/gVeCTD6CYQKBNxwQFRWCXzKCJownIAEjDwOCKYU+lygJAoIehm6OAIIyhzS?= =?us-ascii?q?Od41vgTaGOZBIAgQCBAUCDgEBBYFmIoFYcBWDJ4JCDBeDT4pTcoEpi3wrgQQ?= =?us-ascii?q?BgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="scan'208";a="321110835" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 16:20:06 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TGK4sH013655 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 16:20:05 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:20:03 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:20:03 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 11:20:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EgMjHXTvSl0dOp+M9/5XgRFbTsrXW1v7QZSRZ6AtXvJSvMU4wUYuhyyWjBK2IOn1xoUjb5VcGxLGY+5T51OWPwnZeLPj9wkQC/nBVnSTOz5pbhYl0LUEZIyLT3MUCh5g8oUOxzHpchXHBuNwTClNOdmk8wtnlACJMoscmQye/IscN5p+KYqo8zNh9CQtIqMzR5SX6vMb/JHoJvqPYPiQv4XC/5aQH7WGQTS6q3k8OQfEFF/25TkaJv8L3GmXDLHDy2ciUNQK+yYdoIKe3bLZsuxAg9ZIFf+GLH7UeuX4Pq15uHmh6XRPzIDX4mdHNhe3Ix4L0RVHpOmDbf4qhna3Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hSK6pcEejk9RzqSDvmo9qSTtc2F1kSuXY+39a/rJPVY=; b=fZ1YGo17bugpZx2FnHrFVsV1YJVh3gOrU2BmwXNGyMG/hOu5bkBnBxIeU7xZdXU+eMuXnKPn+uKmNYNPPr49Ffhxmo7ADJZbYmbRv9WfaFymBgkj/jQGZ3xoMrT6VGAEvsKrRTZrY7IUtYHwOMd272TJFYjDVVL0c1hJXrCXiR0RbITlbrX4ZZ7b1Uu3Tog31xm5gYF3Eh5OETkEMdfhFwEqKGN6PHUicj0UVfxhCqia54DRlOKVIcPeFlTTSb0XFAQIaJQFFa0zYeVvDXcqwgZhQAW3TDwaW96e4yZ0a7HICQQ504ERNC97xnLGMSaT3hIeqQFtCrxX+X2ufuv6vQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hSK6pcEejk9RzqSDvmo9qSTtc2F1kSuXY+39a/rJPVY=; b=t7xGkz2eZQSIL/BqAaeA6NHk7+On4ZOIcw79MLSjBh2mx6kFE9GV5bEHIvslerk5MiGm2PDbtly9r1ZSf4ENNQj/FBB9qs+ar4qu1nujU9t/AdOsMVRTSG8qCs4cy0CtGQClri+wcpByNqqdzta8jUL8RibO8Ag47+ZSC0hXX4E= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3727.namprd11.prod.outlook.com (20.178.252.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Thu, 29 Aug 2019 16:20:02 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 16:20:02 +0000 From: "Rob Wilton (rwilton)" To: Vladimir Vassilev , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6b5dGgAgAxs3iCACYAKAIACzdNA Date: Thu, 29 Aug 2019 16:20:02 +0000 Message-ID: References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <783a4e9b-397d-c34e-dd18-2c350d8181e1@transpacket.com> In-Reply-To: <783a4e9b-397d-c34e-dd18-2c350d8181e1@transpacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9d446df-8165-4c94-5563-08d72c9cbebf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3727; x-ms-traffictypediagnostic: MN2PR11MB3727: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(13464003)(51444003)(86362001)(76116006)(66476007)(66556008)(64756008)(66446008)(26005)(55016002)(71190400001)(66066001)(966005)(8676002)(478600001)(186003)(110136005)(81166006)(81156014)(229853002)(102836004)(53546011)(66946007)(71200400001)(14454004)(6116002)(305945005)(3846002)(74316002)(7736002)(6436002)(316002)(6306002)(5660300002)(25786009)(11346002)(30864003)(8936002)(76176011)(5024004)(2906002)(256004)(7696005)(486006)(2501003)(14444005)(53936002)(53946003)(9686003)(476003)(6506007)(99286004)(6246003)(446003)(52536014)(33656002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3727; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vFrEyrg6soB5i4B9YMSmA5FV7+3aX+hP/gCXwOWpToKhvDWkozBnl/mSGJ3lFF0fcvmq6TXJ0RQYZmDAlRzALyeqR5fDcunUf6809XHoezNa4U37xKvipDcnKdp794JrqyoB5EKnGOhcIRoZN19kzqpYE1/pZ4rWO2fECodZstQIBWry7Skp2m44wWna+DmUuAznwcw3CO12rGmTJJYM/X0XEe/Etu4GMnSYq/APnkc0W7c8gw29DSDc2iBsRb0m4HNYJSv5NrpUgm0SXu0ZQrMBjjdctHbML+GKzBR3RyPt0RGKm0ytgY1q4reGZHx/9iXt791HEStVp11nmyf5gIWskpR6gbjPvEeDU/6OQPHa55y4I0jOxeyskUsSeMMkEn6oNLmTrj0EdS1nhwL4BSobyzbHhwFs+czxWXiEKVc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d9d446df-8165-4c94-5563-08d72c9cbebf X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 16:20:02.1565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E+wqXbrjrUL7dmZOSiQv+psQ7CZgYRkCXPXZksz0dtesKTWxcIDZKZZd0nbUUgWfku31jsgtlzpigrxoUE/kWg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3727 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:20:13 -0000 SGkgVmxhZGltaXIsDQoNClBsZWFzZSBzZWUgaW5saW5lIC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFZsYWRpbWlyIFZhc3NpbGV2IDx2bGFkaW1pckB0cmFuc3Bh Y2tldC5jb20+DQo+IFNlbnQ6IDI3IEF1Z3VzdCAyMDE5IDE1OjU1DQo+IFRvOiBSb2IgV2lsdG9u IChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQt eWFuZy0wNw0KPiANCj4gT24gMjIvMDgvMjAxOSAxMi4xMywgUm9iIFdpbHRvbiAocndpbHRvbikg d3JvdGU6DQo+IA0KPiA+IEhpIFZsYWRpbWlyLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIGRl dGFpbGVkIHJldmlldy4gIFNvcnJ5IGZvciB0aGUgc2xvdyByZXBseSwgSSd2ZSBiZWVuDQo+IGF3 YXkuICBJJ20gYWxzbyBhYm91dCB0byBiZSBhd2F5IGFnYWluIGZvciBhIGNvdXBsZSBvZiBkYXlz Lg0KPiA+DQo+ID4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUgLi4uDQo+ID4NCj4gPiBJ J2xsIGFsc28gdHJhY2sgdGhlc2UgaXNzdWVzIHRvIGNsb3N1cmUgb24NCj4gPiBodHRwczovL2dp dGh1Yi5jb20vbmV0bW9kLXdnL2ludGVyZmFjZS1leHRlbnNpb25zLXlhbmcvaXNzdWVzDQo+ID4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbmV0bW9kIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFZsYWRpbWlyIFZhc3NpbGV2DQo+ID4+ IFNlbnQ6IDEzIEF1Z3VzdCAyMDE5IDE3OjA1DQo+ID4+IFRvOiBLZW50IFdhdHNlbiA8a2VudCtp ZXRmQHdhdHNlbi5uZXQ+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtuZXRt b2RdIFdHIExhc3QgQ2FsbDoNCj4gPj4gZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0w Nw0KPiA+Pg0KPiA+PiBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0LiBJIGhhdmUgdGhlIGZvbGxv d2luZyAoMTkpIElNTyB1c2VmdWwNCj4gcHJvcG9zYWxzOg0KPiA+Pg0KPiA+PiAxLiBEZWRpY2F0 ZWQgbW9kdWxlIChpZXRmLWlmLW9wZXItc3RhdHVzLWRlYm91bmNlLnlhbmcpIGZvciB0aGUgb3Bl ci0NCj4gPj4gc3RhdHVzIGRlYm91bmNpbmcvZGFtcGVuaW5nIGZ1bmN0aW9uYWxpdHkgY3VycmVu dGx5IGluDQo+ID4+IGlldGYtaW50ZXJmYWNlcy0gY29tbW9uLnlhbmcuDQo+ID4gSSBkb24ndCB0 aGluayB0aGF0IHdlIHdhbnQgYSBwcm9saWZlcmF0aW9uIG9mIHRvbyBtYW55IHNlcGFyYXRlIFlB TkcNCj4gbW9kdWxlcyBmb3Igc21hbGwgZmVhdHVyZXMuICBFYWNoIG9mIHRoZSBhcmVhcyBvZiBk aWZmZXJlbnQgZnVuY3Rpb25hbGl0eQ0KPiB3aXRoaW4gdGhpcyBtb2R1bGUgYXJlIGFscmVhZHkg Y29uZGl0aW9uYWwgb24gaWYtZmVhdHVyZSwgc28gSSBkb24ndCB0aGluaw0KPiB0aGF0IHRoZXJl IGlzIGEgc3Ryb25nIGp1c3RpZmljYXRpb24gdG8gc2VwYXJhdGluZyB0aGlzIG91dCBhcyBhIHNl cGFyYXRlDQo+IG1vZHVsZS4NCj4gDQo+IEkgc3RpbGwgdGhpbmsgdGhhdCBlc3BlY2lhbGx5IHRo ZSAiZGFtcGVuaW5nIiBtZWNoYW5pc20gaXMgbm90IGNvbW1vbg0KPiBlbm91Z2ggYW5kIGlzIHF1 aXRlIGNvbXBsZXggdG8gYmUgYWRkZWQgdG8gaWV0Zi1pbnRlcmZhY2VzLWNvbW1vbi4gSWYgYQ0K PiBmZWF0dXJlIGlzIG5vdCBjb21tb24gb3IgZG9lcyBub3QgZW5hYmxlIHRoZSB1c2Ugb2YgZ2Vu ZXJpYyBtb2RlbGluZw0KPiBtZWNoYW5pc20gKGxpa2Ugc3ViLWludGVyZmFjZXMgZXRjLikgaXQg c2hvdWxkIG5vdCBiZSBpbiBpZXRmLWludGVyZmFjZXMtDQo+IGNvbW1vbi4gSSBkbyBub3QgdGhp bmsgImRhbXBlbmluZyIgKG1heWJlIGF0IHNvbWUgcG9pbnQgd2Ugc2hvdWxkIGdvIGJhY2sNCj4g dG8gZGFtcGluZyBpbnN0ZWFkIGUuZy4gcmZjMjQzOSAuLi4gc2VlbXMgdGhlcmUgaXMgZGlmZmVy ZW5jZSBiZXR3ZWVuDQo+IGRhbXBlbmluZyBhbmQgZGFtcGluZyBhbmQgZGFtcGluZyBzZWVtcyB0 byBiZSB0aGUgY29ycmVjdCBvbmUpIGlzIHRoYXQNCj4gY29tbW9uIHRvIGRlc2VydmUgYSBwbGFj ZSBpbiBpZXRmLWludGVyZmFjZXMtY29tbW9uLg0KW1JXXSANCg0KSSd2ZSByZW5hbWVkIHRoZSBt b2R1bGUgdG8gaWV0Zi1pZi1leHRlbnNpb25zLnlhbmcuDQoNCkkgc3RpbGwgZG9uJ3Qgc2VlIHRo YXQgc3BsaXR0aW5nIHRoaXMgdG8gYSBzZXBhcmF0ZSBZQU5HIG1vZHVsZSBpcyBoZWxwZnVsLg0K DQoNCj4gDQo+ID4NCj4gPj4gMi4gSW4gc2VjICIzLjEgQ2FycmllciBkZWxheSIgdXNlIG9mIHRo ZSB1bmRlci1kZWZpbmVkICJDYXJyaWVyIg0KPiA+PiBkZWZpbml0aW9uIGNhbiBiZSByZXBsYWNl ZCB3aXRoIGRpcmVjdCByZWZlcmVuY2UgdG8gdGhlIG9wZXItc3RhdHVzDQo+ID4+IGxlYWYgKHdo aWNoIGlzIHdoYXQgaXMgYWN0dWFsbHkgdGFyZ2V0ZWQgYnkgdGhlIGFsZ29yaXRobSkNCj4gPj4g Ik9wZXJhdGlvbmFsIHN0YXR1cyB0cmFuc2l0aW9uIGRlYm91bmNpbmciLg0KPiA+IEkgdGhpbmsg dGhhdCBkaWZmZXJlbnQgdmVuZG9ycyBoYXZlIGRpZmZlcmVudCBuYW1lcyBmb3IgdGhpcyB0ZWNo bm9sb2d5Lg0KPiBJJ3ZlIGp1c3QgdXNlZCB0aGUgb25lIHRoYXQgb3VyIHByb2R1Y3RzIHVzZS4g IEkgdGhpbmsgdGhhdCB0aGlzIGlzIGp1c3QgYQ0KPiBuYW1lLCByYXRoZXIgdGhhbiBzb21ldGhp bmcgdGhhdCBoYXMgdG8gYmUgZGVmaW5lZC4gIEkgY291bGQgYWRkIGEgY29tbWVudA0KPiB0aGF0 IHRoaXMgZmVhdHVyZSBpcyBzb21ldGltZXMgY2FsbGVkIGhvbGQgdGltZT8NCj4gDQo+IEkgbG9v a2VkIGZvciBwcmVjZWRlbnRzIC3CoCAiY2Fycmllci1kZWxheSIgbGVhZiBDaXNjbywgImRlYm91 bmNpbmctDQo+IGludGVydmFsIiBsZWFmIEp1bmlwZXIsICJpbnRlcmZhY2UtcGh5cy1ob2xkdGlt ZS1jb25maWciDQo+IGxlYWYgT3BlbkNvbmZpZy4NCj4gDQo+IEkgdGhpbmsgIkNhcnJpZXIiIGlz IGNvbmZ1c2luZyBzaW5jZSB3aGF0IGlzIGRlbGF5ZWQgYWN0dWFsbHkgaXMgdGhlDQo+IHRyYW5z aXRpb24gb2YgdGhlIG9wZXItc3RhdHVzLg0KW1JXXQ0KDQpCdXQgaXQgaXMgbm90IGp1c3QgdGhl IG9wZXItc3RhdHVzIHRoYXQgaXMgZGVsYXllZCAod2hpY2ggd291bGQgb25seSBhZmZlY3QgbWFu YWdlYWJpbGl0eSkuDQoNCkluc3RlYWQsIGl0IGlzIHRoZSBpbnRlcm5hbCBub3RpZmljYXRpb24g dG8gdGhlIGhpZ2hlciBsYXllciBwcm90b2NvbHMgdGhhdCB0aGUgdW5kZXJseWluZyBpbnRlcmZh Y2UgbGluayBzdGF0ZSBoYXMgY2hhbmdlZC4gIEUuZy4gd2l0aCBjYXJyaWVyLWRlbGF5IGRvd24s IHRoZSBJUCBsYXllciBtYXkgc3RpbGwgdGhpbmsgdGhhdCB0aGUgaW50ZXJmYWNlIGlzIHVwIHdo ZW4gdGhlIEV0aGVybmV0IGxheWVyIHNpZ25hbGxpbmcgaW5kaWNhdGVzIHRoYXQgdGhlIGludGVy ZmFjZSBpcyBhY3R1YWxseSBkb3duLg0KDQpJJ2xsIGhhdmUgYSB0aGluayBhbmQgc2VlIGlmIEkg Y2FuIGNvbWUgdXAgd2l0aCBhIGNsZWFyZXIgbmFtZSBmb3IgdGhpcy4NCg0KDQo+IA0KPiA+PiAz LiAidGltZXItcnVubmluZyIgYW5kICJzdXBwcmVzc2VkIiBsZWFmcyBhcmUgYm90aCAiY29uZmln IGZhbHNlIiBhbmQNCj4gPj4gaGF2ZSAiZGVmYXVsdCIgc3RhdGVtZW50cy4gQWx0aG91Z2ggdGhp cyBpcyB2YWxpZCBZQU5HIEkgZG8gbm90IHRoaW5rDQo+ID4+IHRoZSAiZGVmYXVsdCIgc3RhdGVt ZW50cyBhcmUgaW50ZW5kZWQuDQo+ID4gSSB0aGluayB0aGF0IHRoaXMgaXMgYSBtb3JlIGdlbmVy YWwgcXVlc3Rpb24gdGhhdCBuZWVkcyBhIGJpdCBtb3JlDQo+IGRpc2N1c3Npb24uICBIZXJlLCBJ IGFtIHVzaW5nIGRlZmF1bHRzIGZvciB0aGUgY29uZmlnIGZhbHNlIG5vZGUgdG8NCj4gZG9jdW1l bnQgd2hhdCB0aGUgbm9ybWFsIHZhbHVlIGlzIGV4cGVjdGVkLg0KPiBXZWxsIG5vdCBhIHJlYWwg aXNzdWUgYnV0IEkgdGhvdWdodCBpdCB3YXMgYW4gdW51c3VhbCB1c2Ugb2YgZGVmYXVsdC4NCg0K DQoNCj4gPg0KPiA+DQo+ID4+IDQuIERlZGljYXRlZCBtb2R1bGUgKGlldGYtaWYtbG9vcGJhY2su eWFuZykgZm9yIHRoZSBsb29wYmFjaw0KPiA+PiBmdW5jdGlvbmFsaXR5IGN1cnJlbnRseSBpbiBp ZXRmLWludGVyZmFjZXMtY29tbW9uLnlhbmcuDQo+ID4gU2FtZSBhbnN3ZXIgYXMgZm9yIDEuIEkg ZG9uJ3QgdGhpbmsgdGhhdCB3ZSBzaG91bGQgaGF2ZSB0b28gbWFueSByZWFsbHkNCj4gc21hbGwg bW9kdWxlcy4NCj4gSWYgdGhlIGxvb3BiYWNrIHdhcyBtb2RlbGVkIGFzIGEgYm9vbGVhbiBsZWFm IChhcyBpbiBPcGVuQ29uZmlnKSBJIHdvdWxkDQo+IGhhdmUgYWdyZWVkLiBIb3dldmVyIGV2ZW4g c21hbGwgbW9kdWxlcyB0aGF0IGRlZmluZSBiYXNlIGlkZW50aXRpZXMNCj4gYmVuZWZpdCBmcm9t IGRlZGljYXRlZCBuYW1lc3BhY2UuIEZvciBtZSBpZXRmLWlmLWxvb3BiYWNrLnlhbmcgd2lsbCBw YXkNCj4gb2ZmIHNpbmNlIGxvb3BiYWNrPSdpbnRlcm5hbCcgaXMgYmV0dGVyIHRoZW4gbG9vcGJh Y2s9J2xvb3BiYWNrLWludGVybmFsJw0KPiBhbmQgdGhlcmUgYXJlIGdvaW5nIHRvIGJlIG1hbnkg dGVzdCBjYXNlcyB0aGF0IHVzZSB0aGF0IGxpbmUuIEFuIGxhc3QgYnV0DQo+IG5vdCBsZWFzdCBJ IG5ldmVyIGhhZCBwcm9ibGVtcyB3aXRoIHRvbyBtdWNoIG1vZHVsYXJpdHkuDQoNCk9LLiAgU28s IEkgdGhpbmsgdGhhdCB0aGlzIGlzc3VlIGlzIHJlYWxseSB0aGUgc2FtZSBpc3N1ZSBhcyAoNSkg YmVsb3cuICBJLmUuIHlvdSBhcmUgYXNraW5nIGZvciBhIHNlcGFyYXRlIG1vZHVsZSB0byBrZWVw IHRoZSBuYW1lIG9mIHRoZSBpZGVudGl0aWVzIHNob3J0ZXIuDQoNCg0KPiA+DQo+ID4+IDUuIExl c3MgdmVyYm9zZSBsb29wYmFjayBpZGVudGl0aWVzLiBXaXRoIGRlZGljYXRlZCBtb2R1bGUgdGhl DQo+ID4+IChsb29wYmFjay0qIGlkZW50aXRpZXMgY2FuIGJlIHNob3J0ZW5lZCBza2lwcGluZyB0 aGUgcHJlZml4KS4NCj4gPiBJIHRoaW5rIHRoYXQgaXQgaXMgbm9ybWFsIHRvIGJpbmQgdGhlIGlk ZW50aXR5IG5hbWVzIHRvIHRoZSBjb21tb24gYmFzZQ0KPiBpZGVudGl0eS4gIEkgZG9uJ3Qgc2Vl IHRoYXQgdGhlIGxlbmd0aCBvZiB0aGUgaWRlbnRpdGllcyBzaG91bGQgcmVhbGx5IGJlDQo+IGFu IGlzc3VlLg0KPiBGb3IgbWUgdGhlIGxlbmd0aCBvZiBpZGVudGl0aWVzIGRvZXMgbWF0dGVyIHNp bmNlIEkgb2Z0ZW4gdXNlIGNvbW1hbmQgbGluZQ0KPiB0b29scy4gQnV0IGl0IGlzIG1vc3RseSB0 aGUgaXJyaXRhdGlvbiBjYXVzZWQgYnkgdGhlIHRhdXRvbG9neQ0KPiBsb29wYmFjaz0nbG9vcGJh Y2staW50ZXJuYWwnIHRoYXQgZXZlcnlvbmUgd3JpdGluZyBuZXR3b3JrIGludGVyY29ubmVjdA0K PiB0ZXN0Y2FzZXMgaXMgZ29pbmcgdG8gYmUgc3R1Y2sgd2l0aCBmb3JldmVyIGlmIHdlIGxlYXZl IHRoZSBsb29wYmFjaw0KPiBjb250cm9sIG1vZGVsIGFzIHBhcnQgb2YgaWV0Zi1pbnRlcmZhY2Vz LWNvbW1vbiBhbmQgbm90IHNlcGFyYXRlIGlldGYtaWYtDQo+IGxvb3BiYWNrLiBXaGF0IGRvIG90 aGVycyB0aGluaz8NCg0KVGhlcmUgYXJlIHNvbWUgY2hvaWNlcyBoZXJlOg0KKDEpIEtlZXAgd2l0 aCBpZGVudGl0aWVzIHdpdGggYSAibG9vcGJhY2stIiBwcmVmaXguICBUaGlzIGNhdXNlcyBsb29w YmFjaz0nbG9vcGJhY2staW50ZXJuYWwnDQooMikgS2VlcCB3aXRoIGlkZW50aXRpZXMsIGJ1dCBs b29zZSB0aGUgY29tbW9uIHByZWZpeCwgaS5lLiB0aGUgaWRlbnRpdGllcyBiZWNvbWUgImludGVy bmFsIiwgImxpbmUiLCAiY29ubmVjdG9yIg0KKDMpIFVzZSBzaG9ydGVyIGlkZW50aXRpZXMsIGJ1 dCBhbHNvIHB1dCB0aGVtIGluIGEgc2VwYXJhdGUgbW9kdWxlLg0KKDQpIFVzZSBhbiBlbnVtIHJh dGhlciB0aGFuIGlkZW50aXRpZXMuICBBbHRob3VnaCB0aGlzIGhhcyB0aGUgcG90ZW50aWFsIGlz c3VlIHRoYXQgZW51bXMgY2Fubm90IGJlIGV4dGVuZGVkLg0KDQpJJ3ZlIGFsc28gYXNrZWQgdGhl IFlBTkcgZG9jdG9ycyBmb3IgdGhlaXIgaW5wdXQgb24gdGhpcyBxdWVzdGlvbiAtIGNvbnNpc3Rl bnQgbW9kZWxsaW5nIGJlaGF2aW91ciBhY3Jvc3MgbW9kdWxlcyBpcyBhbHNvIGltcG9ydGFudC4N Cg0KU28gZmFyIHRoZSBjb25zZW5zdXMgaXMgdG8ga2VlcCB0aGVtIGluIHRoZSBzYW1lIG1vZHVs ZSBidXQgZHJvcCB0aGUgImxvb3BiYWNrLSIgcHJlZml4LiAgSGVuY2UsIHRoaXMgaXMgbXkgcHJv cG9zZWQgcmVzb2x1dGlvbi4NCg0KDQo+ID4NCj4gPj4gNi4gVGhlIGRyYWZ0IGludHJvZHVjZXMg Imxvb3BiYWNrLWludGVybmFsIiwgImxvb3BiYWNrLWxpbmUiIGFuZA0KPiA+PiAibG9vcGJhY2st Y29ubmVjdG9yIiBsb29wYmFjayBpZGVudGl0aWVzLiBXaGF0IGlzIGNvbmZ1c2luZyBpcyB0aGF0 DQo+ID4+ICJpbnRlcm5hbCBsb29wYmFjayIgaXMgaGlzdG9yaWNhbGx5IHRoZSBvcHBvc2l0ZSBv ZiAiZXh0ZXJuYWwgbG9vcGJhY2siDQo+ID4+IHdoaWNoIGlzIGEgbG9vcGJhY2sgd2l0aCBhIGNv bm5lY3Rvci4gSSB0aGluayB0ZXJtaW5vbG9neSBhbHJlYWR5IGluDQo+ID4+IHVzZSBsaWtlICJu ZWFyLWVuZCIgYW5kICJmYXItZW5kIiBpcyBsZXNzIGNvbmZ1c2luZy4NCj4gPiBUaGUgaW50ZXJu YWwvbGluZSBsb29wYmFjayBjb25maWd1cmF0aW9uIGhhcyBiZWVuIHVzZWQgaW4gcGFydHMgb2Yg dGhlDQo+IGluZHVzdHJ5IGZvciBhdCBsZWFzdCAyMCB5ZWFycywgc28gdGhpcyB0ZXJtaW5vbG9n eSBpcyBhbHJlYWR5IGluIHVzZS4NCj4gPg0KPiA+IEknbSBub3Qgc3VyZSB0aGF0ICJuZWFyLWVu ZCIgYW5kICJmYXItZW5kIiB3b3VsZCBiZSBsZXNzIGNvbmZ1c2luZy4NCj4gQXNzdW1pbmcgdGhh dCAibG9vcGJhY2sgZmFyLWVuZCIgd2FzIGVxdWl2YWxlbnQgdG8gImxvb3BiYWNrLWxpbmUiIHRo ZW4gaXQNCj4gd291bGQgYmUgc29tZXdoYXQgb2YgYSBtaXNub21lciBzaW5jZSBpdCBhY3RzIG9u IHRoZSBuZWFyIGVuZCwgbm90IHRoZSBmYXINCj4gZW5kLg0KPiA+DQo+ID4gSS5lLiBib3RoIGxv b3BiYWNrIGludGVybmFsLCBhbmQgbG9vcGJhY2sgbGluZSBhY3Qgb24gdGhlIGxvY2FsDQo+IGlu dGVyZmFjZSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBpbiB3aGljaCBkaXJlY3Rpb24gdGhleSBy ZWZsZWN0IHRoZQ0KPiBzaWduYWxzLCBpLmUuIEVncmVzcyAtPiBJbmdyZXNzIChpbnRlcm5hbCks IG9yIEluZ3Jlc3MgLT4gRWdyZXNzIChsaW5lKS4NCg0KDQo+IEkgY2FuIGxpdmUgd2l0aCBsb2Nh bC9saW5lL2Nvbm5lY3RvciBidXQgSSBkbyBub3QgYWdyZWUgbmVhci1lbmQvZmFyLQ0KPiBlbmQv Y29ubmVjdG9ywqAgaXMgbW9yZSBjb25mdXNpbmcuDQoNCk9LLg0KDQoNCj4gPg0KPiA+IFBlcmhh cHMgdGhlIGRlc2NyaXB0aW9uIHRleHQgY291bGQgYmUgc2xpZ2h0bHkgY2xhcmlmaWVkIGhlcmUg dG8gaGVscA0KPiBhdm9pZCBjb25mdXNpb24/DQo+ID4NCj4gPiBPTEQ6DQo+ID4NCj4gPiAgICAg VGhlIGZvbGxvd2luZyBsb29wYmFjayBtb2RlcyBhcmUgZGVmaW5lZDoNCj4gPg0KPiA+ICAgICBv ICBJbnRlcm5hbCBsb29wYmFjayAtIEFsbCBlZ3Jlc3MgdHJhZmZpYyBvbiB0aGUgaW50ZXJmYWNl IGlzDQo+ID4gICAgICAgIGludGVybmFsbHkgbG9vcGVkIGJhY2sgd2l0aGluIHRoZSBpbnRlcmZh Y2UgdG8gYmUgcmVjZWl2ZWQgb24gdGhlDQo+ID4gICAgICAgIGluZ3Jlc3MgcGF0aC4NCj4gPg0K PiA+ICAgICBvICBMaW5lIGxvb3BiYWNrIC0gQWxsIGluZ3Jlc3MgdHJhZmZpYyByZWNlaXZlZCBv biB0aGUgaW50ZXJmYWNlIGlzDQo+ID4gICAgICAgIGludGVybmFsbHkgbG9vcGVkIGJhY2sgd2l0 aGluIHRoZSBpbnRlcmZhY2UgdG8gdGhlIGVncmVzcyBwYXRoLg0KPiA+DQo+ID4gICAgIG8gIExv b3BiYWNrIENvbm5lY3RvciAtIFRoZSBpbnRlcmZhY2UgaGFzIGEgcGh5c2ljYWwgbG9vcGJhY2sN Cj4gPiAgICAgICAgY29ubmVjdG9yIGF0dGFjaGVkIHRoYXQgbG9vcHMgYWxsIGVncmVzcyB0cmFm ZmljIGJhY2sgaW50byB0aGUNCj4gPiAgICAgICAgaW50ZXJmYWNlJ3MgaW5ncmVzcyBwYXRoLCB3 aXRoIGVxdWl2YWxlbnQgc2VtYW50aWNzIHRvIGludGVybmFsDQo+ID4gICAgICAgIGxvb3BiYWNr Lg0KPiA+DQo+ID4gTkVXOg0KPiA+DQo+ID4gICAgIFRoZSBmb2xsb3dpbmcgbG9vcGJhY2sgbW9k ZXMgYXJlIGRlZmluZWQ6DQo+ID4NCj4gPiAgICAgbyAgSW50ZXJuYWwgbG9vcGJhY2sgLSBBbGwg ZnJhbWVzIHRoYXQgZWdyZXNzIG91dCBvZiB0aGUgaW50ZXJmYWNlDQo+ID4gICAgICAgIGFyZSBs b29wZWQgYmFjayBpbnRlcm5hbGx5IHdpdGhpbiB0aGUgaW50ZXJmYWNlIGhhcmR3YXJlDQo+ID4g ICAgICAgIHRvIGJlIHJlY2VpdmVkIG9uIHRoZSBpbmdyZXNzIHBhdGguDQo+ID4NCj4gPiAgICAg byAgTGluZSBsb29wYmFjayAtIEFsbCBpbmdyZXNzIGZyYW1lcyByZWNlaXZlZCBvbiB0aGUgaW50 ZXJmYWNlIGZyb20NCj4gPiAgICAgICAgdGhlIGxpbmUgYXJlIGxvb3BlZCBiYWNrIHdpdGhpbiB0 aGUgaW50ZXJmYWNlIGhhcmR3YXJlIGFuZA0KPiA+ICAgICAgICB0cmFuc21pdHRlZCBiYWNrIG91 dCBvZiB0aGUgaW50ZXJmYWNlLg0KPiA+DQo+ID4gICAgIG8gIExvb3BiYWNrIGNvbm5lY3RvciAt IFRoZSBpbnRlcmZhY2UgaGFzIGEgcGh5c2ljYWwgbG9vcGJhY2sNCj4gPiAgICAgICAgY29ubmVj dG9yIGF0dGFjaGVkIHRoYXQgbG9vcHMgYWxsIGVncmVzcyBmcmFtZXMgYmFjayBpbnRvIHRoZQ0K PiA+ICAgICAgICBpbnRlcmZhY2UncyBpbmdyZXNzIHBhdGgsIHdpdGggZXF1aXZhbGVudCBzZW1h bnRpY3MgdG8gaW50ZXJuYWwNCj4gPiAgICAgICAgbG9vcGJhY2suDQo+IEFkZGluZyBmcmFtZXMg ZXhjbHVkZXMgY29udGludW91cyBzdHJlYW0gKG5vIGZyYW1lKSBkZXZpY2VzIGxpa2UgbGVnYWN5 DQo+IHNlcmlhbCBsaW5rcyBhbmQgaGlnaCBzcGVlZCB0cmFuc2NlaXZlcnMsIG9wdGljYWwgbGlu a3MuIExvb3BiYWNrIGlzDQo+IGFwcGxpY2FibGUgdGhlcmUgdG9vLiBJTU8gdGhlIE9MRCB0ZXh0 IHdhcyBiZXR0ZXIuDQoNCk9LLCBJIHdpbGwga2VlcCB3aXRoIHRoZSBjdXJyZW50IGRlZmluaXRp b25zLg0KDQoNCg0KDQo+ID4+IDcuIEkgYW0gbm90IHN1cmUgc3RhbmRhcmRpemluZyB0aGUgImxv b3BiYWNrLWNvbm5lY3RvciIgaWRlbnRpdHkgaXMNCj4gPj4ganVzdGlmaWVkLiBBbGwgdXNlY2Fz ZXMgb2YgY29ubmVjdGluZyBhIGxvb3BiYWNrIGNvbm5lY3RvciBJIGNhbg0KPiA+PiB0aGluayBv ZiByZXF1aXJlIHRoZSBzeXN0ZW0gdG8gbm90IGJlIGF3YXJlIHRoZXJlIGlzIHNwZWNpYWwgZXh0 ZXJuYWwNCj4gPj4gbG9vcGJhY2sgY29ubmVjdG9yIG9uIHRoZSBpbnRlcmZhY2UuDQo+ID4gSSB0 aGluayB0aGF0IGl0IHdpbGwgZGVwZW5kIG9uIGhvdyBzbWFydCBvZiBkdW1iIHRoZSBleHRlcm5h bCBsb29wYmFjaw0KPiBjb25uZWN0b3IgaXMuICBJZiBpdCBpcyBqdXN0IGEgZHVtYiBlbGVjdHJp Y2FsIG9yIG9wdGljYWwgbG9vcGJhY2sgdGhlbg0KPiB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlv biBNQUMgYWRkcmVzc2VzIG5lZWQgdG8gYmUgc3dhcHBlZCwgb3Igb3RoZXJ3aXNlDQo+IGFueSBl Z3Jlc3MgZnJhbWVzIG91dCBvZiB0aGUgaW50ZXJmYWNlIHdpbGwgZmFpbCB0aGUgZGVzdGluYXRp b24gTUFDDQo+IGFkZHJlc3MgZmlsdGVyIHdoZW4gdGhleSBhcmUgbG9vcGVkIGFyb3VuZC4NCj4g T0sNCg0KSSd2ZSBjbG9zZWQgdGhpcyBpc3N1ZS4NCg0KPiA+DQo+ID4gU29tZSBpbXBsZW1lbnRh dGlvbnMgYWxzbyB1c2UgdGhpcyBjb25maWd1cmF0aW9uIHRvIGZvcmNlIHNlbGYgcGluZw0KPiBw YWNrZXRzIG91dCB0aHJvdWdoIHRoZSBpbnRlcmZhY2UsIHNvIHRoYXQgdGhlIGZ1bGwgZGF0YXBh dGggaXMgdGVzdGVkLA0KPiByYXRoZXIgdGhhbiB0aGUgcGFja2V0cyBiZWluZyBsb29wZWQgaW50 ZXJuYWxseSB3aXRoaW4gdGhlIEwzIGZvcndhcmRpbmcNCj4gY29kZS4NCj4gPg0KPiA+DQo+ID4+ IDguIFNvbWUgaW50ZXJmYWNlcyB0aGF0IGltcGxlbWVudCAibG9vcGJhY2staW50ZXJuYWwiIGRv IG5vdA0KPiA+PiBpbXBsZW1lbnQgImxvb3BiYWNrLWxpbmUiIC0gZS5nLiBjbGFzc2ljYWwgZXRo ZXJuZXRDc21hY2QNCj4gPj4gKENhcnJpZXItc2Vuc2UgbXVsdGlwbGUgYWNjZXNzIHdpdGggY29s bGlzaW9uIGRldGVjdGlvbikgaGFzIGENCj4gPj4gcGh5c2ljYWwgbGF5ZXIgdGhhdCBieSBkZXNp Z24gY2FuIG5vdCBpbXBsZW1lbnQgc3VjaCBsb29wYmFjay4gTWF5YmUNCj4gPj4gaW50cm9kdWNp bmcgYSBkZWRpY2F0ZWQgZmVhdHVyZSB0byBlbmFibGUgdGhlICJsb29wYmFjay1saW5lIiBpcyBh IGdvb2QNCj4gaWRlYS4NCj4gPiBJJ20gbm90IHN1cmUgb24gdGhpcyBvbmUsIGkuZS4gd2hldGhl ciBpdCByZWFsbHkgaGVscHMgb3IganVzdCBhZGRzDQo+IGV4dHJhIGNsdXR0ZXIuDQo+ID4gUmVh bGlzdGljYWxseSwgSSB0aGluayB0aGF0IGV0aGVybmV0Q3NtYWNkIGlzIGRlYWQuICBEbyB5b3Ug aGF2ZSBvdGhlcg0KPiBleGFtcGxlcyBvZiBpbnRlcmZhY2UgdHlwZXMgdGhhdCBkbyBzdXBwb3J0 IGxvb3BiYWNrLCBidXQgbm90IGluIGJvdGgNCj4gZGlyZWN0aW9ucz8NCj4gQWxsIGludGVyZmFj ZXMgdGhhdCBhcmUgbm90IHBvaW50LXRvLXBvaW50IChlLmcuIGNvbW1vbiB3aWZpKS4NCg0KRXZl biB0aGVuLCBJIHN0aWxsIHRoaW5rIHRoYXQgbG9vcGJhY2sgaW50ZXJuYWwgYW5kIGxpbmUgY2Fu IGJvdGggd29yay4NCg0KTG9vcGJhY2sgaW50ZXJuYWwgLSB5b3UgbG9vcCBhbGwgZnJhbWVzIHRo YXQgd291bGQgaGF2ZSBiZWVuIHRyYW5zbWl0dGVkIG91dCBvZiB0aGUgcmFkaW8gaW50ZXJmYWNl Lg0KTG9vcGJhY2sgbGluZSAtIHlvdSBsb29wIGFuZCBmcmFtZXMgcmVjZWl2ZWQgb24gdGhlIHJh ZGlvIGludGVyZmFjZS4NCg0KSGF2aW5nIGEgY29ubmVjdG9yIG9uIGEgcmFkaW8gaW50ZXJmYWNl IHByb2JhYmx5IGRvZXNuJ3QgbWFrZSBhcyBtdWNoIHNlbnNlLg0KDQpCdXQgc3RpbGwgc3VnZ2Vz dCB0aGF0IHdlIHJlbHkgb24gZGV2aWF0aW9ucyB0byBoYW5kbGUgdGhpcyBjYXNlLCBhbmQgaGVu Y2UgY2xvc2UgdGhpcyBpc3N1ZS4NCg0KDQo+ID4gVGhpcyBtaWdodCBiZSBzb21ldGhpbmcgYmV0 dGVyIGhhbmRsZWQgdmlhIGEgZGV2aWF0aW9uLCBvciB0aGUgZGV2aWNlDQo+IGZhaWxpbmcgdGhl IGNvbmZpZ3VyYXRpb24gd2hlbiBpdCBpcyB2ZXJpZmllZC4NCj4gT0sNCj4gPiBBcyBhIHNpZGUg bm90ZSwgb25lIG9mIHRoZSBsaW1pdGF0aW9ucyBvZiBmZWF0dXJlcyBhbmQgZGV2aWF0aW9ucyBp cw0KPiB0aGF0IHRoZSBhcHBseSB0byBhbGwgaW50ZXJmYWNlcyBvbiB0aGUgZGV2aWNlLCBidXQg dGhlIGFjdHVhbCBwcm9wZXJ0aWVzDQo+IG9mIGFuIGludGVyZmFjZSBtaWdodCB2YXJ5IGRlcGVu ZGluZyBvbiB0aGUgc3BlZWQsIHR5cGUgYW5kIGhhcmR3YXJlDQo+IGFzc29jaWF0ZWQgd2l0aCB0 aGUgaW50ZXJmYWNlLg0KPiA+DQo+ID4NCj4gPj4gOS4gQXBwcm9wcmlhdGUgZW50cnkgaW4gdGhl ICIxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIG5vdGluZyB0aGUNCj4gPj4gcG9zc2liaWxp dHkgb2YgRG9TIGF0dGFja3MgYW5kIGJyb2FkY2FzdCB0cmFmZmljIHN0b3JtcyByZXN1bHRpbmcN Cj4gPj4gZnJvbQ0KPiA+PiBsb29wYmFja3M6DQo+ID4+DQo+ID4+IE9MRDoNCj4gPj4NCj4gPj4g ICDCoMKgIFRoZSBmb2xsb3dpbmcgbGVhZiBjb3VsZCBjYXVzZSB0aGUgaW50ZXJmYWNlIHRvIGdv IGRvd24sIGFuZCBzdG9wDQo+ID4+ICAgwqDCoCBwcm9jZXNzaW5nIGFueSBpbmdyZXNzIG9yIGVn cmVzcyB0cmFmZmljIG9uIHRoZSBpbnRlcmZhY2U6DQo+ID4+DQo+ID4+ICAgwqDCoCBvwqAgL2lm OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2xvb3BiYWNrDQo+ID4+DQo+ID4+IE5FVzoNCj4gPj4N Cj4gPj4gICDCoMKgIFRoZSBmb2xsb3dpbmcgbGVhZiBjb3VsZCBjYXVzZSB0aGUgaW50ZXJmYWNl IHRvIGdvIGRvd24sIGFuZCBzdG9wDQo+ID4+ICAgwqDCoCBwcm9jZXNzaW5nIGFueSBpbmdyZXNz IG9yIGVncmVzcyB0cmFmZmljIG9uIHRoZSBpbnRlcmZhY2UuIEl0DQo+IGNvdWxkDQo+ID4+ICAg wqDCoCBjYXVzZSBicm9hZGNhc3QgdHJhZmZpYyBzdG9ybXMuDQo+ID4+DQo+ID4+ICAgwqDCoCBv wqAgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2xvb3BiYWNrDQo+ID4+DQo+ID4gQWNrLg0K PiA+DQo+ID4NCj4gPg0KPiA+PiAxMC4gSW50cm9kdWNpbmcgY29uZmlnIHRydWUgImZvcndhcmRp bmctbW9kZSIgbGVhZiBicmVha3MgY2xpZW50cw0KPiA+PiB0aGF0IHN1cHBvcnQgZS5nLiByZmM4 MzQ0IGlldGYtaXAgKHdoaWNoIGhhcyBpdHMgZGVkaWNhdGVkIGZvcndhcmRpbmcNCj4gPj4gbGVh ZnMgZS5nLg0KPiA+PiAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaW50ZXJmYWNlL2lldGYt aXA6aXB2NC9mb3J3YXJkaW5nICkgYnkNCj4gPj4gaW50cm9kdWNpbmcgdGhpcyBuZXcgbW9kdWxl IHdpdGggYSBuZXcgbGVhZiB0aGV5IGtub3cgbm90aGluZyBhYm91dC4NCj4gPj4gSSBzdXBwb3J0 IHRoaXMgbGVhZiBhcyBjb25maWcgZmFsc2UuIElmIE5FVENPTkYgd2FzIG5vdCB0cmFuc2FjdGlv bmFsIGENCj4gZ2xvYmFsIGxlYWYgZW5hYmxpbmcgdGhlIGZvcndhcmRpbmcgY29uZmlndXJhdGlv biB3b3VsZCBiZSBhIGZlYXR1cmUuDQo+ID4+IEJ1dCBORVRDT05GIGlzIHRyYW5zYWN0aW9uYWwu DQo+ID4gSSBkb24ndCBnZXQgdGhlIHJlbGV2YW5jZSBvZiB0cmFuc2FjdGlvbnMsIGJ1dCBpdCBp c24ndCBpbnRlbmRlZCB0bw0KPiBicmVhayBleGlzdGluZyBjbGllbnRzL1lBTkcgbW9kdWxlcy4N Cj4gPg0KPiA+IFRoZSBpZGVhIG9mIHRoaXMgbGVhZiBpcyB0aGF0IGlmIGl0IGlzIGNvbmZpZ3Vy ZWQgdGhlbiB0aGUgc3lzdGVtIGNhbg0KPiB1c2UgaXQgdG8gY2hlY2sgb3RoZXIgY29uc3RyYWlu dHMuICBFLmcuIHRvIHZhbGlkYXRlIHRoYXQgYW4gTDIgUW9TIHBvbGljeQ0KPiBpc27igJl0IGJl aW5nIGNvbmZpZ3VyZWQgb24gYW4gTDMgaW50ZXJmYWNlLiAgSWYgdGhlIGxlYWYgaXNuJ3QgY29u ZmlndXJlZA0KPiB0aGVuIHRob3NlIGNvbnN0cmFpbnRzIGFyZSBub3QgY2hlY2tlZC4NCj4gSWYg dGhpcyBsZWFmIGlzIG9ubHkgZW5hYmxpbmcgb3B0aW9uYWwgYWRkaXRpb25hbCBjb25zdHJhaW5z IChhbmQgdGhpcyBpcw0KPiB0aGUgb25seSBiYWNrd2FyZCBjb21wYXRpYmxlIG9wdGlvbikgSXQg d29uJ3QgYmUgdGhhdCB1c2VmdWwgYXMgY29uZmlnDQo+IHRydWUuDQo+ID4NCj4gPg0KPiA+PiAx MS4gVGhlICJmb3J3YXJkaW5nLW1vZGUiIGxlYWYgaGFzIHRoZSBmb2xsb3dpbmcgc2V0IG9mIGlk ZW50aXRpZXMNCj4gPj4ge29wdGljYWwtbGF5ZXIsIGwyLWZvcndhcmRpbmcsIG5ldHdvcmstbGF5 ZXJ9LiBXZSBjb3VsZCBtYWtlIHRoZQ0KPiBpZGVudGl0eQ0KPiA+PiBuYW1lcyBzaG9ydGVyIGFu ZCBjb25zaXN0ZW50LiBsMSxsMixsMyBvciBwaHlzaWNhbCxkYXRhLWxpbmssbmV0d29yay4NCj4g PiBJJ3ZlIHRyaWVkIHRvIHVzZSBuYW1lcyBoZXJlIHRoYXQgbmV0d29yayBlbmdpbmVlcnMgYXJl IG1vc3QgbGlrZWx5IHRvDQo+IGJlIGZhbWlsaWFyIHdpdGguDQo+ID4NCj4gPiBJIHRoaW5rIHRo YXQgdXNpbmcgdGhlIE9TSSBsYXllciBuYW1lcyAoZS5nLiBsMSwgbDIsIGwzKSB3b3VsZCBiZSB0 b28NCj4gdGVyc2UuDQo+ID4NCj4gPiBXZSBjb3VsZCBjaGFuZ2UgImwyLWZvcndhcmRpbmciIHRv ICJkYXRhLWxpbmstbGF5ZXIiLCBidXQgSSB3b3VsZCB0aGluaw0KPiB0aGF0IHBlb3BsZSB3b3Vs ZCBiZSBtb3JlIGZhbWlsaWFyIHdpdGggImwyLWZvcndhcmRpbmciIGFzIGEgdGVybS4gIEUuZy4N Cj4gcmVsYXRlZCB0byBMMlZQTi4NCj4gPg0KPiA+DQo+ID4+IDEyLiBJIGRvIG5vdCBhZ3JlZSB3 ZSBuZWVkIHRoaXMgdGV4dC4gTm9ybWFsbHkgTkVUQ09ORiBkZXZpY2VzIHNob3VsZA0KPiA+PiBh Y2NlcHQgdHJhbnNhY3Rpb25zIHRvIGFueSB2YWxpZCBjb25maWd1cmF0aW9uOg0KPiA+Pg0KPiA+ PiBPTEQ6DQo+ID4+ICAgwqDCoCAuLi4NCj4gPj4gICDCoMKgIE5vcm1hbGx5IGRldmljZXMgd2ls bCBub3QgYWxsb3cgdGhlIHBhcmVudC1pbnRlcmZhY2UgbGVhZiB0byBiZQ0KPiA+PiAgIMKgwqAg Y2hhbmdlZCBhZnRlciB0aGUgaW50ZXJmY2UgaGFzIGJlZW4gY3JlYXRlZC7CoCBJZiBhbiBpbXBs ZW1lbnRhdGlvbg0KPiA+PiAgIMKgwqAgZGlkIGFsbG93IHRoZSBwYXJlbnQtaW50ZXJmYWNlIGxl YWYgdG8gYmUgY2hhbmdlZCB0aGVuIGl0IGNvdWxkDQo+IGNhdXNlDQo+ID4+ICAgwqDCoCBhbGwg dHJhZmZpYyBvbiB0aGUgYWZmZWN0ZWQgaW50ZXJmYWNlIHRvIGJlIGRyb3BwZWQuwqAgVGhlIGFm ZmVjdGVkDQo+ID4+ICAgwqDCoCBsZWFmIGlzOg0KPiA+Pg0KPiA+PiAgIMKgwqAgb8KgIC9pZjpp bnRlcmZhY2VzL2lmOmludGVyZmFjZS9wYXJlbnQtaW50ZXJmYWNlDQo+ID4+ICAgwqDCoCAuLi4N Cj4gPj4NCj4gPj4gTkVXOg0KPiA+PiAgIMKgwqAgLi4uDQo+ID4+ICAgwqDCoCBDaGFuZ2luZyB0 aGUgcGFyZW50LWludGVyZmFjZSBsZWFmIGNvdWxkIGNhdXNlDQo+ID4+ICAgwqDCoCBhbGwgdHJh ZmZpYyBvbiB0aGUgYWZmZWN0ZWQgaW50ZXJmYWNlIHRvIGJlIGRyb3BwZWQuDQo+ID4+ICAgwqDC oCBUaGUgYWZmZWN0ZWQgbGVhZiBpczoNCj4gPj4NCj4gPj4gICDCoMKgIG/CoCAvaWY6aW50ZXJm YWNlcy9pZjppbnRlcmZhY2UvcGFyZW50LWludGVyZmFjZQ0KPiA+PiAgIMKgwqAgLi4uDQo+ID4g VGhpcyBpc24ndCBhYm91dCB0cmFuc2FjdGlvbnMgc28gbXVjaCBhcyB2YWxpZCBjb25maWd1cmF0 aW9uLg0KPiA+DQo+ID4gTm9ybWFsbHksIHRoZSBuYW1lIG9mIHRoZSBzdWItaW50ZXJmYWNlIGlz IHRpZ2h0bHkgYm91bmQgdG8gdGhlIHBhcmVudA0KPiBpbnRlcmZhY2UuICBFLmcuIGlmIHRoZSBw YXJlbnQgaW4gIkV0aGVybmV0MC8xIiB0aGVuIHRoZSBzdWItaW50ZXJmYWNlDQo+IHdvdWxkIGJl ICJFdGhlcm5ldDAvMS4xIi4gIElmIHlvdSB0cmllZCB0byBjaGFuZ2UgdGhlIHBhcmVudC1pbnRl cmZhY2UNCj4gbGVhZiBvZiAiRXRoZXJuZXQwLzEuMSIgdG8gIkV0aGVybmV0Mi8yIiB0aGVuIEkg d291bGQgZXhwZWN0IHRoZSBzeXN0ZW0gdG8NCj4gcmVqZWN0IHRoYXQgY2hhbmdlIChiZWNhdXNl IHRoZSBjb25maWd1cmF0aW9uIGlzIGludmFsaWQgbm90IGJlY2F1c2Ugb2YNCj4gdHJhbnNhY3Rp b25zKS4NCj4gPg0KPiA+DQo+ID4+IDEzLiBUaGUgaW4tZHJvcC11bmtub3duLWRlc3QtbWFjLXBr dHMgY2hhbmdlcyB0aGUgYmVoYXZpb3Igb2YgdGhlIGluLQ0KPiA+PiB1bmljYXN0LXBrdHMsaW4t bXVsdGljYXN0LXBrdHMgYW5kIGluLWJyb2FkY2FzdC1wa3RzLiBJIGRvIG5vdCBhZ3JlZQ0KPiBh bnkNCj4gPj4gZGlzY2FyZGVkIHBhY2tldHMgaW4gdGhlIGZvcndhcmRpbmcgcHJvY2VzcyBzaG91 bGQgYmUgc3VidHJhY3RlZCBmcm9tDQo+IHRoZQ0KPiA+PiBpbnRlcmZhY2UgY291bnRlcnMuDQo+ ID4+DQo+ID4+IEhlcmUgaXMgdGhlIGN1cnJlbnQgZGVzY3JpcHRpb246DQo+ID4+DQo+ID4+IE9M RDoNCj4gPj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRm9yIGNvbnNpc3RlbmN5 LCBmcmFtZXMgY291bnRlZCBhZ2FpbnN0IHRoaXMgZHJvcA0KPiA+PiAgIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBjb3VudGVycyBhcmUgYWxzbyBjb3VudGVkIGFnYWluc3QgdGhlIElF VEYgaW50ZXJmYWNlcw0KPiA+PiAgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdGF0 aXN0aWNzLsKgIEluIHBhcnRpY3VsYXIsIHRoZXkgYXJlIGluY2x1ZGVkIGluDQo+ID4+ICAgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGluLW9jdGV0cyBhbmQgaW4tZGlzY2FyZHMsIGJ1 dCBhcmUgbm90IGluY2x1ZGVkIGluDQo+ID4+ICAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGluLXVuaWNhc3QtcGt0cywgaW4tbXVsdGljYXN0LXBrdHMgb3IgaW4tYnJvYWRjYXN0LQ0K PiBwa3RzLA0KPiA+PiAgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBiZWNhdXNlIHRo ZXkgYXJlIG5vdCBkZWxpdmVyZWQgdG8gYSBoaWdoZXIgbGF5ZXIuDQo+ID4+IE5FVzoNCj4gPj4g ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhlIGltcGxlbWVudGF0aW9uIG9mIHRo aXMgY291bnRlciBkb2VzIG5vdA0KPiA+PiAgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIHRoZSBjb3VudGVycyBkZWZpbmVkIGluDQo+ID4+ICAg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIElFVEYgaW50ZXJmYWNlcyBzdGF0aXN0aWNz Lg0KPiA+Pg0KPiA+IEl0IGlzIG5vdCBjaGFuZ2luZyB0aGUgZGVmaW5pdGlvbnMgb2YgdGhvc2Ug Y291bnRlcnMgYXQgYWxsLiAgSXQgaXMganVzdA0KPiBleHBsYWluaW5nIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiB0aGVtLg0KPiANCj4gVGhlIHByb2JsZW0gSSBzZWUgaXMgdGhhdCB0b2RheSB0 aGVyZSBhcmUgZXhpc3Rpbmcgc3lzdGVtcyB0aGF0DQo+IGltcGxlbWVudCBpZXRmLWludGVyZmFj ZXMgYW5kIGRpc2NhcmQgcGFja2V0cyBiZWNhdXNlIHRoZXkgaGF2ZSB1bmtub3duDQo+IE1BQyBk ZXN0aW5hdGlvbi4gQnV0IHRob3NlIHN5c3RlbXMgZG8gbm90IHN1YnRyYWN0IHRoZSBudW1iZXIg b2YNCj4gZGlzY2FyZGVkIHBhY2tldHMgZnJvbSB0aGUgImluLXVuaWNhc3QtcGt0cyIgY291bnRl ci4gVGhvc2Ugc3lzdGVtcyB3aWxsDQo+IGhhdmUgdG8gY2hhbmdlIHRoZWlyIGJlaGF2aW9yIGlu IGEgbm9uLWJhY2t3YXJkIGNvbXBhdGlibGUgd2F5IHRvIGJlDQo+IGFibGUgdG8gaW1wbGVtZW50 IHRoZSBpbi1kcm9wLXVua25vd24tZGVzdC1tYWMtcGt0cyB3aXRoIHRoaXMNCj4gZGVzY3JpcHRp b24uIEluIG15IHZpZXcgdGhpcyB0ZXh0IGNoYW5nZXMgdGhlIGRlZmluaXRpb24gb2YNCj4gaW4t dW5pY2FzdC1wa3RzIGVuZm9yY2luZyBjZXJ0YWluIGRlc2lnbiB0aGF0IHdhcyBub3QgZW5mb3Jj ZWQgYmVmb3JlLg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgdGhvc2Ugc3lzdGVtcyBhcmUgY29ycmVj dGx5IGltcGxlbWVudGluZyB0aGUgImluLXVuaWNhc3QtcGt0cyIgY291bnRlci4NCg0KSS5lLiB5 b3Ugc2hvdWxkbid0IGJlIGhhbmRpbmcgcGFja2V0cyBvZmYgdG8gdGhlIElQIGxheWVyIHRvIGZv cndhcmQsIGlmIGl0IGZhaWxzIGFuIEwyIGRlc3QgTUFDIGNoZWNrLiAgSWYgeW91IGRvbid0IGhh bmQgdGhlIHBhY2tldCB0byBJUCwgdGhlbiB5b3Ugc2hvdWxkbid0IGJlIGluY3JlbWVudGluZyAi aW4tdW5pY2FzdC1wa3RzIiBhcyBwZXIgdGhlICJkZWxpdmVyZWQgYnkgdGhpcyBzdWItbGF5ZXIg dG8gYSBoaWdoZXIgKHN1Yi1sYXllcikiIGNvbW1lbnQuDQoNCiAgICAgICAgICAgbGVhZiBpbi11 bmljYXN0LXBrdHMgew0KICAgICAgICAgICAgIHR5cGUgeWFuZzpjb3VudGVyNjQ7DQogICAgICAg ICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIHBhY2tldHMs IGRlbGl2ZXJlZCBieSB0aGlzIHN1Yi1sYXllciB0byBhDQogICAgICAgICAgICAgICAgaGlnaGVy IChzdWItKWxheWVyLCB0aGF0IHdlcmUgbm90IGFkZHJlc3NlZCB0byBhDQogICAgICAgICAgICAg ICAgbXVsdGljYXN0IG9yIGJyb2FkY2FzdCBhZGRyZXNzIGF0IHRoaXMgc3ViLWxheWVyLg0KICAg ICAgICAgICAgICAgIC4uLiINCg0KQW5kIGFsc28gdGhlICJwcmV2ZW50IHRoZWlyIGJlaW5nIGRl bGl2ZXJhYmxlIHRvIGEgaGlnaGVyLWxheWVyIHByb3RvY29sIiBjb21tZW50IGluIGluLWRpc2Nh cmRzOiANCg0KICAgICAgICAgICBsZWFmIGluLWRpc2NhcmRzIHsNCiAgICAgICAgICAgICB0eXBl IHlhbmc6Y291bnRlcjMyOw0KICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAg ICAiVGhlIG51bWJlciBvZiBpbmJvdW5kIHBhY2tldHMgdGhhdCB3ZXJlIGNob3NlbiB0byBiZQ0K ICAgICAgICAgICAgICAgIGRpc2NhcmRlZCBldmVuIHRob3VnaCBubyBlcnJvcnMgaGFkIGJlZW4g ZGV0ZWN0ZWQgdG8NCiAgICAgICAgICAgICAgICBwcmV2ZW50IHRoZWlyIGJlaW5nIGRlbGl2ZXJh YmxlIHRvIGEgaGlnaGVyLWxheWVyDQogICAgICAgICAgICAgICAgcHJvdG9jb2wuICBPbmUgcG9z c2libGUgcmVhc29uIGZvciBkaXNjYXJkaW5nIHN1Y2ggYQ0KICAgICAgICAgICAgICAgIHBhY2tl dCBjb3VsZCBiZSB0byBmcmVlIHVwIGJ1ZmZlciBzcGFjZS4NCg0KDQoNCg0KDQo+IA0KPiA+DQo+ ID4NCj4gPg0KPiA+Pg0KPiA+PiAxNC4gSSBwcm9wb3NlIHRoZSBpbi1wa3RzIGFuZCBvdXQtcGt0 cyBjb3VudGVycyBzdGFuZGFyZGl6ZWQgdG9vLg0KPiA+Pg0KPiBodHRwczovL2dpdGh1Yi5jb20v WWFuZ01vZGVscy95YW5nL2Jsb2IvbWFzdGVyL3ZlbmRvci9jaXNjby94ZS8xNjQxL2lldGYtDQo+ ID4+IGludGVyZmFjZXMtZXh0LnlhbmcuDQo+ID4+IEFuZCB5ZXMgc29tZW9uZSBmb3Jnb3QgdG8g dXBkYXRlIHRoZSBib2lsZXJwbGF0ZSB0ZXh0Lg0KPiA+IFRoaXMgb25lIEkgdGhpbmsgdGhhdCB3 ZSBuZWVkIHRvIGdldCBmdXJ0aGVyIGlucHV0IG9uLg0KPiA+DQo+ID4NCj4gaHR0cHM6Ly9naXRo dWIuY29tL1lhbmdNb2RlbHMveWFuZy9ibG9iL21hc3Rlci9zdGFuZGFyZC9pZWVlL3B1Ymxpc2hl ZC84MDINCj4gLjMvaWVlZTgwMi1ldGhlcm5ldC1pbnRlcmZhY2UueWFuZw0KPiA+DQo+ID4gZGVm aW5lcyBpbi1mcmFtZXMgYW5kIG91dC1mcmFtZXMsIGJ1dCB0aGVzZSBhcmUgb25seSBmb3IgRXRo ZXJuZXQsIGJ1dA0KPiB5b3UgYXJlIHByb2JhYmx5IGxvb2tpbmcgZm9yIGEgY291bnRlciBhY3Jv c3MgYWxsIGludGVyZmFjZSB0eXBlcy4NCj4gWWVzLiBpbi1wa3RzIGFuZCBvdXQtcGt0cyBhcmUg dXNlZCBieSBPcGVuRmxvdywgT3BlbkRheWxpZ2h0LA0KPiBPcGVuQ29uZmlnLCBDaXNjbyBldGMu IFRob3NlIGFyZSBpbnRlcmZhY2UgaW5kZXBlbmRlbnQuIEl0IGlzIGltcG9zc2libGUNCj4gdG8g aW1wbGVtZW50IGlldGYtaW50ZXJmYWNlcyBmb3IgZGV2aWNlcyB0aGF0IHByb3ZpZGUgb25seSBp bi1wa3RzIGFuZA0KPiBvdXQtcGt0cyAodGhhdCB3b3VsZCBiZSBhbGwgT3BlbkZsb3cgc3dpdGNo ZXMpIHdoaWNoIGlzIGEgZ29vZCBhcmd1bWVudA0KPiB0byBoYXZlIHRoZSBjb3VudGVycyBzdGFu ZGFyZGl6ZWQuDQo+ID4NCj4gPj4gMTUuIEkgcHJvcG9zZSB0aGF0IG5ldyAiaWV0Zi1pbnRlcmZh Y2VzLWNvbW1vbjppbi1kaXNjYXJkcy1vdmVyZmxvdyINCj4gPj4gY291bnRlciBpcyBhZGRlZC4g Q3VycmVudGx5IHRoZSAiaWV0Zi1pbnRlcmZhY2VzOmluLWRpc2NhcmRzIiBjYW4NCj4gY29udGFp bg0KPiA+PiBib3RoIGRpc2NhcmRzIGxpa2UgdGhlIG9uZXMgYWNjdW11bGF0ZWQgaW4gaW4tZHJv cC11bmtub3duLWRlc3QtbWFjLQ0KPiBwa3RzDQo+ID4+IGFuZCBkaXNjYXJkcyBjYXVzZWQgYnkg b3ZlcmZsb3dzIChwZXJmb3JtYW5jZSByZWxhdGVkIGxvc3Mgb2YgcGFja2V0cw0KPiBsaWtlDQo+ ID4+IGZyZWVpbmcgYnVmZmVyIHNwYWNlIGluIGRldmljZXMgdGhhdCBpbiBjZXJ0YWluIGNhc2Vz IGFyZSBmb3J3YXJkaW5nDQo+ID4+IHNsb3dlciB0aGVuIHRoZSBsaW5lIHNwZWVkKS4gVHVybnMg b3V0IGtub3dpbmcgaWYgZGV2aWNlIGlzIGRpc2NhcmRpbmcNCj4gPj4gKGxvb3NpbmcpIHBhY2tl dHMgZHVlIHRvIHBlcmZvcm1hbmNlIHNob3J0YWdlIGFuZCBkaXNjYXJkaW5nDQo+IChmaWx0ZXJp bmcpDQo+ID4+IHVud2FudGVkIHBhY2tldHMgYXJlIHR3byBkaWZmZXJlbnQgZXZlbnRzIHRoYXQg b25lIG5lZWRzIHRvDQo+IGRpZmZlcmVudGlhdGUNCj4gPj4gYmV0d2VlbiBhcmUgY3VycmVudGx5 IGluIHRoZSBzYW1lIGluLWRpc2NhcmRzIGNvdW50ZXIuIFdlIGNhbiBmaXggdGhhdA0KPiA+PiB3 aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgaW4tZGlzY2FyZHMtb3ZlcmZsb3cgY291bnRlci4NCj4g PiBUaGlzIG9uZSBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBnZXQgZnVydGhlciBpbnB1dCBvbi4g IEkgdGhpbmsgdGhhdA0KPiB0aGlzIG1pZ2h0IGJlIHVzZWZ1bC4gIEJ1dCB3ZSBtaWdodCBuZWVk IHNvbWUgY2FyZSB0byBlbnN1cmUgdGhhdCBpdCBmaXRzDQo+IGNsZWFubHkgd2l0aCBRb1MgZHJv cHMuDQo+ID4NCj4gPiBJZiB3ZSB3ZXJlIHRvIGFkZCB0aGlzIHRoZW4gdGhlIGRlZmluaXRpb24g b2YgImlldGYtaW50ZXJmYWNlczppbi0NCj4gZGlzY2FyZHMiIGNhbm5vdCBjaGFuZ2UuICBpLmUu IEluLWRpc2NhcmRzLW92ZXJmbG93IHdvdWxkIGJlIGEgc3Vic2V0IG9mDQo+ICJpbi1kaXNjYXJk cyIuDQo+IE9LDQo+ID4NCj4gPg0KPiA+PiAxNi4gV2UgY2FuIHJlcGxhY2UNCj4gPj4gImlldGYt aW50ZXJmYWNlcy1ldGhlcm5ldC1saWtlOmluLWRyb3AtdW5rbm93bi1kZXN0LW1hYy1wa3RzIiB3 aXRoIChpbi0NCj4gPj4gZGlzY2FyZHMgLSBpbi1kaXNjYXJkcy1vdmVyZmxvdykgZm9yIE1BQyBC cmlkZ2VzIG9yIGFueSBvdGhlciBFdGhlcm5ldA0KPiA+PiBpbnRlcmZhY2UgcGx1cyBzYXZlIHVz IHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGVjaG5vbG9neSBzcGVjaWZpYyBzaW1pbGFyDQo+ID4+IGNv dW50ZXJzIGZvciB0aGUgcmVzdCBvZiB0aGUgQnJpZGdlcyBhbmQgbm9uLUV0aGVybmV0IGludGVy ZmFjZXMuDQo+ID4gRm9yIEV0aGVybmV0LCBoYXZpbmcgYSB0ZWNobm9sb2d5IHNwZWNpZmljIGlu LWRyb3AtdW5rbm93bi1kZXN0LW1hYy1wa3RzDQo+IGlzIHVzZWZ1bC4NCj4gPg0KPiA+IEluIHRo ZSBXRyBkaXNjdXNzaW9uLCB0aGVyZSB3YXMgYWdyZWVtZW50IHRvIGFsc28gYWRkIGEgZHJvcCBj b3VudGVyIGZvcg0KPiBwYWNrZXRzIHRoYXQgYXJlIGRyb3BwZWQgYmVjYXVzZSB0aGV5IGNhbm5v dCBiZSBkZW11eGVkIHRvIGFueSBzdWItDQo+IGludGVyZmFjZS4NCj4gPg0KPiA+IFBlcnNvbmFs bHksIEkgdGhpbmsgdGhhdCBpdCBpcyB1c2VmdWwgdG8gaGF2ZSBhbiBvdmVyYWxsIGRyb3AgY291 bnRlcg0KPiB0aGF0IGNhcHR1cmVzIGV2ZXJ5dGhpbmcsIGFsb25nIHdpdGggbW9yZSBzcGVjaWZp YyBkcm9wIGNvdW50ZXJzIHRoYXQNCj4gc29tZXRpbWVzIGdpdmUgbW9yZSBpbmZvcm1hdGlvbiBh cyB0byB3aGF0IGhhcyBjYXVzZXMgc3BlY2lmaWMgZHJvcHMuDQo+IFNwZWNpZmljYWxseSwganVz dCBiZWNhdXNlIGEgbW9yZSBzcGVjaWZpYyBkcm9wIGNvdW50ZXIgaGFzIGJlZW4gZGVmaW5lZCwN Cj4gdGhhdCBkb2Vzbid0IG1lYW4gdGhhdCBpdCBzaG91bGRuJ3QgYWxzbyBiZSBpbmNsdWRlZCBp biB0aGUgZ2VuZXJhbCBkcm9wDQo+IGNvdW50ZXIuDQoNCj4gSU1PIHRoZSBpbi1kaXNjYXJkcyBj b3VudGVyIHNob3VsZCBiZSBpbmNyZW1lbnRlZCBpbiB2ZXJ5IHJhcmUNCj4gY2lyY3Vtc3RhbmNl cyAoZS5nLiBpbmdyZXNzIGNsb2NrIGZyZXF1ZW5jeSBhYm92ZSBzdXBwb3J0ZWQpIGFuZCBpZGVh bGx5DQo+IHJlc2VydmVkIGZvciByZXBvcnRpbmcgcGVyZm9ybWFuY2UgaXNzdWVzIGluIHRoZSBN QUMgdGhhdCBzaG91bGQNCj4gbm9ybWFsbHkgbm90IGV4aXN0LiBUaGUgInVua25vd24tZGVzdC1t YWMiIGFuZCAicGFja2V0cyB0aGF0IGFyZSBkcm9wcGVkDQo+IGJlY2F1c2UgdGhleSBjYW5ub3Qg YmUgZGVtdXhlZCB0byBhbnkgc3ViLWludGVyZmFjZSIgc2hvdWxkIGJlIGhhbmRsZWQNCj4gYXQg YW5vdGhlciAic3ViLWxheWVyIiBhbmQgZG8gbm90IG5lZWQgdG8gYmUgc3VidHJhY3RlZCBmcm9t IHRoZQ0KPiBpZXRmLWludGVyZmFjZXMgaW4tKi1wa3QgY291bnRlcnMgYmVjYXVzZSB0aGlzIGlz IHZlcnkgY29uZnVzaW5nLiBCdXQNCj4gcHJvYmFibHkgdGhlcmUgYXJlIHN5c3RlbXMgb3V0IHRo ZXJlIHRoYXQgYWxyZWFkeSB1c2UgImluLWRpc2NhcmRzIiBmb3INCj4gYWxsIHNvcnRzIG9mIGRp c2NhcmRzLg0KDQpNeSBpbnRlcnByZXRhdGlvbiBvZiBSRkMgODM0MyBpcyB0aGF0IGluZ3Jlc3Mg cGFja2V0cyB0byBhbiBpbnRlcmZhY2UgYXJlIGFsbCBpbmNsdWRlZCBpbiB0aGUgaW4tb2N0ZXRz IGNvdW50ZXIsIGFuZCB0aGVuIGNhdGVnb3JpemVkIGludG8gb25lIG9mIDYgcGFja2V0IGNvdW50 ZXJzOg0KIC0gZ29vZCBwYWNrZXRzIChkZWxpdmVyZWQgdG8gYSBoaWdoIGxheWVyIHByb3RvY29s KSBhcmUgY291bnRlZCBhZ2FpbnN0IG9uZSBvZiBpbi11bmljYXN0LXBrdHMsIGluLWJyb2FkY2Fz dC1wa3RzIG9yIGluLW11bHRpY2FzdC1wa3RzDQogLSB2YWxpZCBwYWNrZXRzIGRyb3BwZWQgYmVj YXVzZSB0aGUgaGlnaGVyIGxheWVyIHByb3RvY29sIGlzIHVua25vd24gKG9yIG5vdCBjb25maWd1 cmVkL2VuYWJsZWQpIGFyZSBjb3VudGVkIGFnYWluc3QgaW4tdW5rbm93bi1wcm90b3MNCiAtIGVy cm9uZW91cyBwYWNrZXRzIChlLmcuIGFsbCBmcmFtaW5nIGVycm9ycywgdG9vIGxvbmcsIHRvbyBz aG9ydCkgYXJlIGNvdW50ZWQgYWdhaW5zdCBpbi1lcnJvcnMsDQogLSBhbGwgb3RoZXIgcGFja2V0 cyBkcm9wcGVkIG9uIHRoZSBpbmdyZXNzIGludGVyZmFjZSBmb3IgYW55IG90aGVyIHJlYXNvbiBu b3QgY292ZXJlZCBhYm92ZSBhcmUgY291bnRlZCBhZ2FpbnN0IGluLWRpc2NhcmRzDQoNCmluLWRy b3AtdW5rbm93bi1kZXN0LW1hYy1wa3RzIGRvZXNuJ3QgY2hhbmdlIHRoZSBhYm92ZSBkZWZpbml0 aW9ucy4gIElzIHRoaXMgdGhlIHN1YnNldCBvZiBpbi1kaXNjYXJkcyB0aGF0IGFyZSBkcm9wcGVk IGJlY2F1c2UgdGhlIGRlc3QgTUFDIGFkZHJlc3MgaXMgaW52YWxpZC4gIElmIGZyYW1lcyBjb3Vu dGVkIGFnYWluc3QgaW4tZHJvcC11bmtub3duLWRlc3QtbWFjLXBrdHMgd2VyZW4ndCBhbHNvIGNv dW50ZWQgYWdhaW5zdCBpbi1kaXNjYXJkcyB0aGVuIHRoYXQgd291bGQgZWZmZWN0aXZlbHkgY2hh bmdlcyB0aGUgZGVmaW5pdGlvbiBpbi1kaXNjYXJkcywgYW5kIHdvdWxkIGJyZWFrIGltcGxlbWVu dGF0aW9ucyB0aGF0IGFyZSBub3QgY2hlY2tpbmcgdGhlIGluLWRyb3AtdW5rbm93bi1kZXN0LW1h Yy1wa3RzIGNvdW50ZXIuDQoNClRoYW5rcywNClJvYg0KDQoNCj4gPg0KPiA+DQo+ID4+IDE3LiBJ IGhhdmUgc2VwYXJhdGVseSBwb3N0ZWQgbXkgYXJndW1lbnRzIGFnYWluc3QgaW50cm9kdWN0aW9u IG9mIGxlYWYNCj4gPj4gbmFtZWQgbDItbXR1IGFuZCB0aGUgbmVlZCBvZiBhIGNvbmZpZyBmYWxz ZSBsZWFmIHRoYXQgaGFzIHNpbWlsYXINCj4gPj4gc2VtYW50aWNzIGFzIHRoZSBpZk10dSBvYmpl Y3QgZnJvbSBJRi1NSUIuDQo+ID4gT0ssIGxldHMga2VlcCB0aGlzIGlzc3VlIG9uIHRoYXQgb3Ro ZXIgdGhyZWFkLg0KPiBPSw0KPiA+DQo+ID4NCj4gPj4gMTguIFNvbWUgcmVmZXJlbmNlcyB0byBy ZWxldmFudCBJRUVFIHN0YW5kYXJkcyBhbmQgSUVFRSBtYWludGFpbmVkIFlBTkcNCj4gPj4gbW9k dWxlcyBzaG91bGQgYmUgYWRkZWQgKGluIHRoZSBzY29wZSBvZiBpZXRmLWludGVyZmFjZXMtZXRo ZXJuZXQtDQo+IGxpa2UpLg0KPiA+PiBBbHNvIGEgZmV3IGxpbmVzIGV4cGxhaW5pbmcgdGhlIHBv bGljeSBjaGFuZ2UgYW5kIHdoeSBub25lIG9mIHRoZQ0KPiA+PiBSRkMzNjM1IG1hbmFnZWQgb2Jq ZWN0cyBhcmUgcGFydCBvZiB0aGUgbmV3IGlldGYtaW50ZXJmYWNlcy1ldGhlcm5ldC0NCj4gbGlr ZQ0KPiA+PiBZQU5HIG1vZHVsZS4NCj4gPiBZZXMsIE9LLg0KPiA+DQo+ID4NCj4gPj4gMTkuIGll dGYtaWYtY29tbW9uLnlhbmcgYW5kIGlldGYtaWYtZXRoZXJuZXQtbGlrZS55YW5nIGluc3RlYWQg b2YgaWV0Zi0NCj4gPj4gaW50ZXJmYWNlcy1jb21tb24ueWFuZyBhbmQgaWV0Zi1pbnRlcmZhY2Vz LWV0aGVybmV0LWxpa2UueWFuZy4NCj4gPj4gU2V0dGluZyBhIHNob3J0ZXIgbmFtaW5nIHByZWNl ZGVudCBmb3IgZnV0dXJlIG1vZHVsZXMgYXVnbWVudGluZyBpZXRmLQ0KPiA+PiBpbnRlcmZhY2Vz Lg0KPiA+IEknbSBub3Qgb3Bwb3NlZCB0byBzaG9ydGVyIG5hbWVzLCBidXQgd291bGQgYmUgaW50 ZXJlc3RlZCBpbiB0aGUgdmlld3MNCj4gb2Ygb3RoZXJzIGluIHRoZSBXRy4NCj4gDQo+IE9LDQo+ IA0KPiANCj4gL1ZsYWRpbWlyDQo+IA0KPiA+DQo+ID4gVGhhbmtzIGFnYWluIGZvciB0aGUgcmV2 aWV3LiAgSXQgaXMgYXBwcmVjaWF0ZWQuDQo+ID4NCj4gPiBSb2INCj4gPg0KPiA+DQo+ID4+IC9W bGFkaW1pcg0K From nobody Thu Aug 29 09:38:35 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA31201DB for ; Thu, 29 Aug 2019 09:38:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.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 ZIwmMmby9QbS for ; Thu, 29 Aug 2019 09:38:31 -0700 (PDT) Received: from sender-of-o52.zoho.eu (sender-of-o52.zoho.eu [31.186.226.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9264C120131 for ; Thu, 29 Aug 2019 09:38:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567096693; cv=none; d=zohomail.eu; s=zohoarc; b=Q2nOsm/DR2CpumZexJXB8OgltHMV9/XXHuY5y84KydnlY5lkiGOhrLDiFV1Ar5sxeAxbKpIzY/+KmFksDsHWA3YGwjpYMzr9J/kZINbsQokrCmc3PQJaes9pANUfLxHqb8KgzGr1lAYOeW4nk1+nS4gLNECnwQWQB51hy0FAK0o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1567096693; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=oA5nd+N/6CFspPko6orpDMlkzpOg9n1+JhY89mX5dx0=; b=ikDn+VCWaCKiDVp9UT8hMr9ykPw2Tn9Ndk5PaFJ9hdhTG9Drf06dmUNdy37CuAF/JJNm9AXUN9zGIRL5Mhg4n6AnQsY8dEbLgb9z/wb+U5hiSUCm+r5wV0oeMxm/pBqh6LkxVU+SJF9RRAbjUb5R/zwYTOVhzrmOd6ZJCTlJY10= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1567096693; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=15795; bh=oA5nd+N/6CFspPko6orpDMlkzpOg9n1+JhY89mX5dx0=; b=TmGkoT7sncPXYYG3DErEga8olDV5gFWw1DmYbXOf6k++JrnFc94t3IxblcThL8h1 8hA5Zo0PPvotAltaoZkujNYuIAgHHYbeUPfBaZCT3AyCXCc5jBceeSapgvqRfrj4l7e hir4kjuZJapdMz0syselRqjca0HOORdvQmqqQ0rg= Received: from sender.zoho.eu (172.26.23.79 [172.26.23.79]) by mx.zoho.eu with SMTPS id 1567096691776875.2455484034308; Thu, 29 Aug 2019 18:38:11 +0200 (CEST) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1567096691696590.4591544327862; Thu, 29 Aug 2019 18:38:11 +0200 (CEST) Date: Thu, 29 Aug 2019 18:38:11 +0200 From: Dmytro Shytyi To: "Qin Wu" Cc: "Robert Varga" , "netmod" Message-Id: <16cde3ddbec.113caa65e53664.1973595371275750452@shytyi.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_149248_140041839.1567096691692" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:38:34 -0000 ------=_Part_149248_140041839.1567096691692 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >Dmytro: > > ># # # : Dmytro Shytyi [mailto:mailto:ietf.dmytro@shytyi.net] ># # # # : 2019# 8# 28#=C2=A0 21:46 ># # # : Robert Varga ; Qin Wu ># # : netmod ># # : Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working = Group document. > >Hello, > >Please find comments inline. >>On 27/08/2019 18:03, Dmytro Shytyi wrote: >>> Dear All, >>>=C2=A0 >>> I am one of the authors of ID VYSM and I would like to draw your >>> attention to the evolution of the >>> draft=C2=A0https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vys= m-01.txt. >>> Recently we produced (but did not submitted yet) a new version of ID >>> (02) and I beleive it fits the netmod working group. >>>=C2=A0 >>> We would be gratefull if you could suggest if the new version(02) of th= e >>> document=C2=A0 could become an official work item of the WG? >>> =C2=A0 =C2=A0 =C2=A0 If yes, could you please indicate which modificati= ons must be done >>> in the document before submition. >>=C2=A0 >>Hmm, looking over the model, it would seem there is quite a bit of >>overlap with RFC8345 -- to the point I believe the model could be >>formulated in terms of RFC8345 specialization: >First of all I would like to thank you for this comment.=C2=A0 >-Dmytro >>virtualization -> networks/network >>=C2=A0 >>device/links/interfaces/switches/vms are probably a mix of >>node/termmination-point/link extensions with conjunction with >>supporting-{topology,node,link}. >I can imagine mapping: >virtualization (ID) -> networks/network (RFC 8345) >links (ID)- >link;(RFC 8345) >ports (ID)-> termination points;(RFC 8345) >But still.. it seems here we have to create extension of the model propose= d in RFC 8345. >Precisely for node (RFC 8345) we may add types (switches, vms) and futer a= dd leafs /listsfor type if required (ex: #RAM,#vCPUs and other leafs for VM= s) >-Dmytro >>How would the draft relate to RFC8345? Should it perhaps call out it is >>a different take on the similar problem, specialized to a particular >>use-case? >One can suggest that=C2=A0 in the RFC8345 Figure 1, the block "service Top= ology model" can include the proposed in the draft network service descript= or with appropriate modification of mapping according to the RFC8345. > >Meanwhile I find that the proposed solution(ID) try to solve the problem d= escibed below: > >The uCPE management mechanism may involve not only YANG modules but=C2=A0 = also the speficif logic written in programming languages. The proposed orga= nisation of yang model is an attempt to find the best fit=C2=A0 for combina= tion (YANG modules + specific logic written in python for example )=C2=A0 t= o manage different existing NFVIs in the uCPE (by the orchestrator). > >In the case of uCPE, the mapping (w/wo additinal logic) of "variables " be= tween service yang modules (in the orchestrator) and NETCONF payload(that i= s sent to the uCPE) will be more complex (requires additional transformatio= ns in the logic) with generic approach, then the solution presented in the = ID, that is tailored to the uCPE.=C2=A0 > >Therefore I find the proposed solution as a stadalone generic approach to = manage multiple vendor uCPE that appears to be a particular case tailored f= or uCPE NFVIs that may be not nesseraly follows RFC8345. I would be pleased= if you could comment this. > >-Dmytro >>Regards, >>Robert (with RFC8345 co-author hat on) >>+1, in addition, I am wondering whether this is something related to over= lay topology model, if yes, how it is different from DC Fabric topology mod= el defined in RFC8542?=C2=A0 >>-Qin=C2=A0 >Thank you for your comment. The RFC8542 condisers PODs in the DC network. = uCPE is located on the customer site. if we consider that uCPE is A POD (wi= th links and nodes like VMs and swithces) then in the RFC8542 describes dif= ferent PODs in the network that are interconnected with links. The yang mod= el proposed in the ID ifocuses only on the uCPE interiour network service, = not the interconnection between the uCPEs. Aslo, I explained the difference= about extension neded for type of nodes,vms leafs and furter complexity in= the mapping logic in the reponce to Robert. >-Dmytro > >[Qin]:So you focus on interconnection between local vPE and remote vPE? [Dmytro]: Thank you for this question. It seems that the next version of draft should= include the explanation of the uCPE interiour network service. Example: We can have multiple VMs instantiated in the uCPE (vFW,vRouter/vCP= E,SD-WAN). With support of links and swithes=C2=A0 VMs may create a service= chains. Example of service chains: 1)WAN--vRouter(vCPE)-link-uCPEvSW -link2-vFirewall-LAN 2)WAN--SDWAN--vFirewall--LAN >It is not clear whether we should distinguish VM from switch. In my unders= tanding, Upon VNF is instantiated, there is no difference between virtual a= nd physical worlds. [Dmytro]: The VM/VNF in the uCPE could be a vROuter or Vfirewall or an SD-WAN that is= not a default part of virtual network resources of the uCPE (chapter 3 in = the ID). The switch (ex. Open vSwith) in the uCPE is a default part of uCPE network = virtual resources (chapter 3 in the ID). Thus we need to distingish swithes and VNFs to not to mix uCPE network virt= ual resources and VNFs. Another reason why the destingishing is required: because VM and SW have di= fferent device-attributes. SW does not require VNFD attributtes. If we do not distinguish nodes, and only extend the grouping "device attrib= utes" for required attributes the switch will have the properties that are= =C2=A0 unused leafs which represent the VM-device-attributes. >VNF lifecycle management is separated from topology construction, wrong? [Dmytro]: a) In case of the NFVIs uCPE the same High Level interface allows to config= ure both topology construction and VM lifecycle management in the same tran= saction. b) We can not activate Network Service Descriptor without consituent VM nod= e information. At the moment of NSD activation we already have to set the V= M node information such as VM capabilities that can be created (previosly)/= (at the moment of configuration of NSD) but have to be a part of the networ= k service descriptor at the moment of activation. [Dmytro] The Internet Draft also defines the term uCPE that is not defined at IETF y= et. ------=_Part_149248_140041839.1567096691692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
># # # : Robert V= arga <nite@hq.sk>= ; Qin Wu <bill.w= u@huawei.com>
># # : netmod <netmod@ietf.org>
>= ;# # : Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working = Group document.
>
>Hello,
&= gt;
>Please find comments inline.
>>On= 27/08/2019 18:03, Dmytro Shytyi wrote:
>>> Dear All= ,
>>> 
>>> I am one of t= he authors of ID VYSM and I would like to draw your
>>&= gt; attention to the evolution of the
>>> Recently we produced (bu= t did not submitted yet) a new version of ID
>>> (02= ) and I beleive it fits the netmod working group.
>>>= ; 
>>> We would be gratefull if you could sugge= st if the new version(02) of the
>>> document  = could become an official work item of the WG?
>>> &n= bsp;     If yes, could you please indicate which modifications mu= st be done
>>> in the document before submition.
=
>> 
>>Hmm, looking over the model= , it would seem there is quite a bit of
>>overlap with = RFC8345 -- to the point I believe the model could be
>>= formulated in terms of RFC8345 specialization:
>First of a= ll I would like to thank you for this comment. 
>-Dmy= tro
>>virtualization -> networks/network
>> 
>>device/links/interfaces/switches/vm= s are probably a mix of
>>node/termmination-point/link = extensions with conjunction with
>>supporting-{topology= ,node,link}.
>I can imagine mapping:
>vir= tualization (ID) -> networks/network (RFC 8345)
>links = (ID)- >link;(RFC 8345)
>ports (ID)-> termination poi= nts;(RFC 8345)
>But still.. it seems here we have to creat= e extension of the model proposed in RFC 8345.
>Precisely = for node (RFC 8345) we may add types (switches, vms) and futer add leafs /l= istsfor type if required (ex: #RAM,#vCPUs and other leafs for VMs)
>-Dmytro
>>How would the draft relate to RFC83= 45? Should it perhaps call out it is
>>a different take= on the similar problem, specialized to a particular
>>= use-case?
>One can suggest that  in the RFC8345 Figur= e 1, the block "service Topology model" can include the proposed in the dra= ft network service descriptor with appropriate modification of mapping acco= rding to the RFC8345.
>
>Meanwhile I find= that the proposed solution(ID) try to solve the problem descibed below:
>
>The uCPE management mechanism may involv= e not only YANG modules but  also the speficif logic written in progra= mming languages. The proposed organisation of yang model is an attempt to f= ind the best fit  for combination (YANG modules + specific logic writt= en in python for example )  to manage different existing NFVIs in the = uCPE (by the orchestrator).
>
>In the cas= e of uCPE, the mapping (w/wo additinal logic) of "variables " between servi= ce yang modules (in the orchestrator) and NETCONF payload(that is sent to t= he uCPE) will be more complex (requires additional transformations in the l= ogic) with generic approach, then the solution presented in the ID, that is= tailored to the uCPE. 
>
>Therefore= I find the proposed solution as a stadalone generic approach to manage mul= tiple vendor uCPE that appears to be a particular case tailored for uCPE NF= VIs that may be not nesseraly follows RFC8345. I would be pleased if you co= uld comment this.
>
>-Dmytro
>>Regards,
>>Robert (with RFC8345 co-author hat= on)
>>+1, in addition, I am wondering whether this is = something related to overlay topology model, if yes, how it is different fr= om DC Fabric topology model defined in RFC8542? 
>>= ;-Qin 
>Thank you for your comment. The RFC8542 condi= sers PODs in the DC network. uCPE is located on the customer site. if we co= nsider that uCPE is A POD (with links and nodes like VMs and swithces) then= in the RFC8542 describes different PODs in the network that are interconne= cted with links. The yang model proposed in the ID ifocuses only on the uCP= E interiour network service, not the interconnection between the uCPEs. Asl= o, I explained the difference about extension neded for type of nodes,vms l= eafs and furter complexity in the mapping logic in the reponce to Robert.
>-Dmytro
>
>[Qin]:So you = focus on interconnection between local vPE and remote vPE?
[D= mytro]:
Thank you for this question. It seems that the next v= ersion of draft should include the explanation of the uCPE interiour networ= k service.
Example: We can have multiple VMs instantiated in = the uCPE (vFW,vRouter/vCPE,SD-WAN). With support of links and swithes = VMs may create a service chains.
Example of service chains:<= br>
1)WAN--vRouter(vCPE)-link-uCPEvSW -link2-vFirewall-LAN
2)WAN--SDWAN--vFirewall--LAN


>It is not clear whether we should distinguish VM from switch. In = my understanding, Upon VNF is instantiated, there is no difference between = virtual and physical worlds.
[Dmytro]:
The VM/V= NF in the uCPE could be a vROuter or Vfirewall or an SD-WAN that is not a d= efault part of virtual network resources of the uCPE (chapter 3 in the ID).=
The switch (ex. Open vSwith) in the uCPE is a default part o= f uCPE network virtual resources (chapter 3 in the ID).
Thus = we need to distingish swithes and VNFs to not to mix uCPE network virtual r= esources and VNFs.
Another reason why the destingishing is re= quired: because VM and SW have different device-attributes. SW does not req= uire VNFD attributtes.
If we do not distinguish nodes, and on= ly extend the grouping "device attributes" for required attributes the swit= ch will have the properties that are  unused leafs which represent the= VM-device-attributes.



>VNF lifecycle management is separated from topology construction= , wrong?
[Dmytro]:
a) In case of the NFVIs uCPE= the same High Level interface allows to configure both topology constructi= on and VM lifecycle management in the same transaction.
b) We= can not activate Network Service Descriptor without consituent VM node inf= ormation. At the moment of NSD activation we already have to set the VM nod= e information such as VM capabilities that can be created (previosly)/(at t= he moment of configuration of NSD) but have to be a part of the network ser= vice descriptor at the moment of activation.

[= Dmytro]
The Internet Draft also defines the term uCPE that is= not defined at IETF yet.

------=_Part_149248_140041839.1567096691692-- From nobody Fri Aug 30 18:09:13 2019 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EDE12012E; Fri, 30 Aug 2019 18:09:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <156721374430.25767.14291249116802853249@ietfa.amsl.com> Date: Fri, 30 Aug 2019 18:09:04 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:09:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Handling Long Lines in Inclusions in Internet-Drafts and RFCs Authors : Kent Watsen Adrian Farrel Qin Wu Filename : draft-ietf-netmod-artwork-folding-09.txt Pages : 30 Date : 2019-08-30 Abstract: This document defines two strategies for handling long lines in width-bounded text content. One strategy is based on the historic use of a single backslash ('\') character to indicate where line- folding has occurred, with the continuation occurring with the first non-space (' ') character on the next line. The second strategy extends the first strategy by adding a second backslash character to identify where the continuation begins and thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-09 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-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 Fri Aug 30 18:15:30 2019 Return-Path: <0100016ce53d9ca4-9be14b7c-a22e-407d-bf6b-0bb7b4eacb75-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9C12004D; Fri, 30 Aug 2019 18:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 KaLUdOapfou5; Fri, 30 Aug 2019 18:15:17 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E909120077; Fri, 30 Aug 2019 18:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567214116; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bMOZsXQlGqT0v4K/97+1EZrYYO3nlQ+UNH6rW3aHXgk=; b=L7p64qT7Wu4wjGa9AngYih7BnwRRYF1UpxPKg8PV6u73ctNbADnrQVRcxi4ZKnMf ohGawN65djH8hWM9ch38d4um9wzXwXVakB99+CwXR8LNlm6Zm21NN8N/o2+KJ8MkGl9 mEG18st0vH+3ss9pKxO+wTAejQSFJ2UZeO0WnE/E= From: Kent Watsen Message-ID: <0100016ce53d9ca4-9be14b7c-a22e-407d-bf6b-0bb7b4eacb75-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7DCFB69B-34EA-4A2A-B1E4-649252ED8B83" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 31 Aug 2019 01:15:16 +0000 In-Reply-To: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> Cc: The IESG , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, "netmod@ietf.org" To: Barry Leiba References: <156644887163.25781.14997941309022671135.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.31-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:15:22 -0000 --Apple-Mail=_7DCFB69B-34EA-4A2A-B1E4-649252ED8B83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barry, I addressed all these issues in the latest update: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-09 = For the "2nd line needing to be blank" issue, I also updated the code to = test for it. Thanks, Kent > On Aug 22, 2019, at 12:41 AM, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-netmod-artwork-folding-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =E2=80=94 Section 4.1 =E2=80=94 >=20 > I find the BCP 14 =E2=80=9CSHOULD=E2=80=9D in this section to be odd, = and would lower-case > them. >=20 > When needed, this effort again > SHOULD be automated to reduce effort and errors resulting from = manual > processing. >=20 > This sentence is really awkward: =E2=80=9Cwhen needed=E2=80=9D, the = use of =E2=80=9Ceffort=E2=80=9D twice, and > the uncertainty of whether the clause =E2=80=9Cresulting from manual = processing=E2=80=9D > applies to both effort and errors, or only to the latter. I would say = it this > way: >=20 > NEW > This work should also be automated to reduce the effort and to reduce = errors > resulting from manual processing. END >=20 > =E2=80=94 Section 6 =E2=80=94 >=20 > assumes that the continuation begins at the character that is > not a space character (' ') on the following line. >=20 > Should be =E2=80=9Cat the first character=E2=80=9D. >=20 > =E2=80=94 Section 7.1.1 =E2=80=94 >=20 > The second line is a blank line. >=20 > The code in the appendix generates an *empty* line (no text). Is that = what you > mean by =E2=80=9Cblank line=E2=80=9D? Will a line that contains only = space characters (*looks* > the same) work also? The code in the appendix appears to discard the = second > line without checking its content at all. I think you should be = clearer about > what qualifies as a =E2=80=9Cblank line=E2=80=9D. (This also applies = to Section 8.1.1.) >=20 > =E2=80=94 Section 7.2.1 =E2=80=94 >=20 > If this text content needs to and can be folded, insert the header > described in Section 7.1.1, ensuring that any additional printable > characters surrounding the header does not result in a line = exceeding > the desired maximum. >=20 > Should be =E2=80=9Cdo not result=E2=80=9D (to match the plural = =E2=80=9Cprintable characters=E2=80=9D). >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_7DCFB69B-34EA-4A2A-B1E4-649252ED8B83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barry,

I addressed = all these issues in the latest update:

   https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-0= 9

For the "2nd line = needing to be blank" issue, I also updated the code to test for = it.

Thanks,
Kent


On Aug 22, 2019, at 12:41 AM, = Barry Leiba via Datatracker <noreply@ietf.org> wrote:

Barry = Leiba has entered the following ballot position for
draft-ietf-netmod-artwork-folding-08: No Objection

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


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


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/



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

=E2=80=94 Section 4.1 =E2=80=94

I find the BCP 14 =E2=80=9CSHOULD=E2=80=9D in = this section to be odd, and would lower-case
them.

  When needed, this effort again
  SHOULD be automated to reduce effort and errors = resulting from manual
  processing.

This sentence is really awkward: =E2=80=9Cwhen = needed=E2=80=9D, the use of =E2=80=9Ceffort=E2=80=9D twice, and
the uncertainty of whether the clause =E2=80=9Cresulting from = manual processing=E2=80=9D
applies to both effort and = errors, or only to the latter.  I would say it this
way:

NEW
This work = should also be automated to reduce the effort and to reduce errors
resulting from manual processing. END

=E2=80=94 Section 6 =E2=80=94

=         assumes that the = continuation begins at the character that is
=         not a space character (' = ') on the following line.

Should be =E2=80=9C= at the first character=E2=80=9D.

=E2=80=94 = Section 7.1.1 =E2=80=94

  The = second line is a blank line.

The code in = the appendix generates an *empty* line (no text).  Is that what = you
mean by =E2=80=9Cblank line=E2=80=9D?  Will a = line that contains only space characters (*looks*
the = same) work also?  The code in the appendix appears to discard the = second
line without checking its content at all.  I = think you should be clearer about
what qualifies as a = =E2=80=9Cblank line=E2=80=9D.  (This also applies to Section = 8.1.1.)

=E2=80=94 Section 7.2.1 =E2=80=94

  If this text content needs to and = can be folded, insert the header
  described in = Section 7.1.1, ensuring that any additional printable
=   characters surrounding the header does not result in a line = exceeding
  the desired maximum.

Should be =E2=80=9Cdo not result=E2=80=9D (to = match the plural =E2=80=9Cprintable characters=E2=80=9D).


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

= --Apple-Mail=_7DCFB69B-34EA-4A2A-B1E4-649252ED8B83-- From nobody Fri Aug 30 18:15:51 2019 Return-Path: <0100016ce53de468-52c4c33a-5dc2-4074-adee-bb8a0f912826-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D27120A64; Fri, 30 Aug 2019 18:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 y63Zq0WFvCXK; Fri, 30 Aug 2019 18:15:36 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00D5120B4F; Fri, 30 Aug 2019 18:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567214134; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ibVmrx3w1jTH3ATuzZhvGlFmsBD7wLlRchx6tWkIAso=; b=MuLiqO9TcvuNabQ+kG14qHAK6rKwrRuPNQdR/cw2Rp0//hGSGorx9RpooE1AiNPf Z2kRrk4thgnuUXEWgoa9t/caExk2R+wrMfbQ+t8Zogi0clLPlllbOxiMw3VOyu8HYx2 B0dEY2vweuevvdhry7VA8+h7kjBgY2QhwQIH2dwA= From: Kent Watsen Message-ID: <0100016ce53de468-52c4c33a-5dc2-4074-adee-bb8a0f912826-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2E58C11F-40C8-4BB7-B1A1-992572AC073C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 31 Aug 2019 01:15:34 +0000 In-Reply-To: <156681945152.25367.12793164355343396320.idtracker@ietfa.amsl.com> Cc: The IESG , "netmod-chairs@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, "netmod@ietf.org" To: =?utf-8?Q?=C3=89ric_Vyncke?= References: <156681945152.25367.12793164355343396320.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.31-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-netmod-artwork-folding-08=3A_=28with_COMMENT=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:15:42 -0000 --Apple-Mail=_2E58C11F-40C8-4BB7-B1A1-992572AC073C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, I added references for 'pyang' and 'yanglint' in the latest update: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-09 = Thanks, Kent > On Aug 26, 2019, at 7:37 AM, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-netmod-artwork-folding-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Sometimes a small problem (like line folding) can be annoying... so = thank you > for authoring this document. >=20 > Just a minor comment: > - should 'pyang' and 'yanglint' be added to the references ? >=20 > -=C3=A9ric >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_2E58C11F-40C8-4BB7-B1A1-992572AC073C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

I added = references for 'pyang' and 'yanglint' in the latest = update:

   https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-0= 9

Thanks,
Kent


On Aug = 26, 2019, at 7:37 AM, =C3=89ric Vyncke via Datatracker <noreply@ietf.org> = wrote:

=C3=89ric Vyncke has entered the following ballot position = for
draft-ietf-netmod-artwork-folding-08: No Objection

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


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


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/



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

Sometimes a small problem (like = line folding) can be annoying... so thank you
for = authoring this document.

Just a minor = comment:
- should 'pyang' and 'yanglint' be added to the = references ?

-=C3=A9ric


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

= --Apple-Mail=_2E58C11F-40C8-4BB7-B1A1-992572AC073C-- From nobody Fri Aug 30 18:16:09 2019 Return-Path: <0100016ce53e2b5d-fb76ed79-acf5-4932-912e-260f69c91f11-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2A12088E; Fri, 30 Aug 2019 18:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 0b0M1KW3SoUm; Fri, 30 Aug 2019 18:15:54 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12AC1209D5; Fri, 30 Aug 2019 18:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567214152; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xo+Zeec8tN/JVjBYpx8oXVVwsYR22ezMg3y1ubS/iGQ=; b=dihftiQ/J0NNV9Rhi/jgA0l3x2cZs4wfd78PfwJ+BM+sxAJUYaPCO1S88wMN7Cwy JrhjWxHgtEpXZnxKV4N649JScrjy4KJRszZkRquSMIkmXcC/Gd1JIjWD/UH/CFJfGTO WUp1dqQyxu3OyY+I9bIlXQGQ8+wkA/TL9qgVp1Bs= From: Kent Watsen Message-ID: <0100016ce53e2b5d-fb76ed79-acf5-4932-912e-260f69c91f11-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2BED9581-920E-42C6-94E8-A0BE1F7996D7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 31 Aug 2019 01:15:52 +0000 In-Reply-To: Cc: Alexey Melnikov , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, The IESG , Lou Berger To: Barry Leiba References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.31-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:16:02 -0000 --Apple-Mail=_2BED9581-920E-42C6-94E8-A0BE1F7996D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alexey (and Barry), I have clarified forced-foldings in the latest update: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-09 = Please let me know if this clears your DISCUSS. Thanks, Kent > On Aug 29, 2019, at 9:47 AM, Barry Leiba = wrote: >=20 > You're saying, then, that "This line ends with a backslash > \\[EOL][EOL]" only loses the last "\" in unfolding, because there is > no space character on the next line. Is that right? If so, Alexey is > right that the algorithm doesn't say that. >=20 > Barry >=20 > On Thu, Aug 29, 2019 at 9:44 AM Kent Watsen = wrote: >>=20 >>=20 >>=20 >> On Aug 29, 2019, at 9:36 AM, Alexey Melnikov = wrote: >>=20 >> On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote: >>=20 >> The example is set up so that the source is in 9.4, 9.4.1 is the >> result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" >> of 9.4. >>=20 >> So the original source (in 9.4) was "This line ends with a backslash = \". >> The result of "\ folding" gives "This line ends with a backslash \\", >> because the backslash had to be escaped. >>=20 >>=20 >> But the algorithm described in prose says absolutely nothing about = escaping trailing "\"! So why the example is Ok, it just doesn't match = the folding algorithm. >>=20 >>=20 >> The word "escape" is a bit misleading, even though, in a way, that is = what is happening (e.g., working around a special character), but it's = not "escaping" in the traditional sense (i.e., the first '\' is in no = way giving special significance to the second '\'). What's really going = on is better described as a forced folding on a line that contains an = invalid end-of-line sequence. Makes sense? >>=20 >> Kent // co-author >>=20 >>=20 >>=20 >> Barry >>=20 >> On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov = wrote: >>=20 >>=20 >> Hi Kent, >>=20 >> On 28 Aug 2019, at 23:03, Kent Watsen wrote: >>=20 >> Hi Alexey, >>=20 >> Response at bottom. >>=20 >> Kent >>=20 >>=20 >> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = wrote: >>=20 >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-netmod-artwork-folding-08: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thank you for your document. >>=20 >> It might be just me, but I think your examples in 9.4.1 with trailing = \ don=E2=80=99t >> seem to match the folding algorithm in section 7, as it doesn=E2=80=99t= describe >> special handling of trailing \. >>=20 >>=20 >> Can you be more specific regarding what it is you think doesn't = match? Step (2) says, at the location where the fold is to occur, = insert '\' followed by '\n'. That appears to be what is shown in 9.4.1, = yes? >>=20 >>=20 >> In the HTML version (in datatracker) I am seeing: >>=20 >> =E2=80=9CThis line ends with a backslash \\=E2=80=9D >>=20 >> followed by an empty line. So I see 2 trailing \ followed by end of = line, instead of \, end of line, and then \. >>=20 >>=20 >> FWIW, the text in Section 9.4.1 (as with all the examples in the = draft) was dynamically-generated (at draft build time) by feeding the = text in Section 9.4 into the script in the Appendix A. >>=20 >> Kent // co-author >>=20 >>=20 >>=20 >>=20 --Apple-Mail=_2BED9581-920E-42C6-94E8-A0BE1F7996D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alexey (and Barry),

I = have clarified forced-foldings in the latest update:

   https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-0= 9

Please = let me know if this clears your DISCUSS.

Thanks,
Kent


On Aug 29, 2019, at 9:47 AM, Barry Leiba <barryleiba@computer.org> wrote:

You're= saying, then, that "This line ends with a backslash
\\[EOL][EOL]" only loses the last "\" in unfolding, because = there is
no space character on the next line.  Is = that right?  If so, Alexey is
right that the = algorithm doesn't say that.

Barry

On Thu, Aug 29, 2019 at 9:44 AM Kent Watsen = <kent+ietf@watsen.net> wrote:



On = Aug 29, 2019, at 9:36 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote:

The example is set up so that the source is in = 9.4, 9.4.1 is the
result of "\ folding" of 9.4, and 9.4.2 = is the result of "\\ folding"
of 9.4.

So the original source (in 9.4) was "This line ends with a = backslash \".
The result of "\ folding" gives "This line = ends with a backslash \\",
because the backslash had to be = escaped.


But the algorithm = described in prose says absolutely nothing about escaping trailing "\"! = So why the example is Ok, it just doesn't match the folding = algorithm.


The word "escape" = is a bit misleading, even though, in a way, that is what is happening = (e.g., working around a special character), but it's not "escaping" in = the traditional sense (i.e., the first '\' is in no way giving special = significance to the second '\').  What's really going on is better = described as a forced folding on a line that contains an invalid = end-of-line sequence.  Makes sense?

Kent= // co-author



Barry

On Thu, Aug 29, 2019 at = 4:55 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:


Hi Kent,

On 28 = Aug 2019, at 23:03, Kent Watsen <kent+ietf@watsen.net> wrote:

Hi Alexey,

Response at = bottom.

Kent

On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker = <noreply@ietf.org> wrote:

Alexey Melnikov has entered the following ballot position = for
draft-ietf-netmod-artwork-folding-08: Discuss

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


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


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-fold= ing/



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

Thank you for your document.

It might be just me, but I think your examples = in 9.4.1 with trailing \ don=E2=80=99t
seem to match the = folding algorithm in section 7, as it doesn=E2=80=99t describe
special handling of trailing \.


Can you be more specific regarding what it is = you think doesn't match?   Step (2) says, at the location = where the fold is to occur, insert '\' followed by '\n'.  That = appears to be what is shown in 9.4.1, yes?


In the HTML version (in datatracker) I am = seeing:

=E2=80=9CThis line ends with a = backslash \\=E2=80=9D

followed by an empty = line. So I see 2 trailing \ followed by end of line, instead of \, end = of line, and then \.


FWIW, = the text in Section 9.4.1 (as with all the examples in the draft) was = dynamically-generated (at draft build time) by feeding the text in = Section 9.4 into the script in the Appendix A.

Kent  // co-author





= --Apple-Mail=_2BED9581-920E-42C6-94E8-A0BE1F7996D7-- From nobody Fri Aug 30 23:32:59 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0D120059; Fri, 30 Aug 2019 23:32:50 -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 header.b=nCSzZmvz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ok4jNzXF 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 HxH-J5JXSTe6; Fri, 30 Aug 2019 23:32:48 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9DB120052; Fri, 30 Aug 2019 23:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10399; q=dns/txt; s=iport; t=1567233168; x=1568442768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lYmZmamH0ussxfw9JLgNaBTBB5DIThMZkR9/f6fyIxk=; b=nCSzZmvzXYypYXDvcHGm3TZIK4o88/ZgnepMCLwSmVLt7+rQkxzGHEy/ Q/Yk0PH1dM/oXdb3FTic9vYx8KhRdMTYA/JAMY9EM/h4Vgdw+msWKjUL1 SMUrdZQafS3D86n18Ssl3sLqOcDuktz6DuDtyG6E0wn+kDSJoAeViPX5V 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AP70pYBFSEt4wUlejp2o6251GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0fioxH8lqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AACpE2pd/5BdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EWL1ADbVYgBAsqhCGDRwOKdII3JZMQhFyBQoEQA1QJAQE?= =?us-ascii?q?BDAEBGAEKCgIBAYN6RQIXgkkjOBMCAwgBAQQBAQECAQYEbYUuDIVKAQEBAQM?= =?us-ascii?q?BARARHQEBLAsBDwIBCBEDAQIoAwICAiULFAYDCAIEDgUigwABgR1NAx0BAgy?= =?us-ascii?q?iMAKBOIhhc4EygnwBAQWBNgIOQYMEGIIWAwaBNIt4GIFAP4ERJwwTgkw+gmE?= =?us-ascii?q?BAQECAYEqARIBPw0JglUygiaMT4JbhR2XUAqCH4ZwiW+DeBuCMoc2jnuDN4t?= =?us-ascii?q?xhj2QUQIEAgQFAg4BAQWBZyFnWBEIcBU7KgGCQYJCOIM6hRSFP3MBgSiLUYJ?= =?us-ascii?q?FAQE?= X-IronPort-AV: E=Sophos;i="5.64,449,1559520000"; d="scan'208,217";a="322471371" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2019 06:32:47 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7V6WlUm010748 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 31 Aug 2019 06:32:47 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 31 Aug 2019 01:32:47 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 31 Aug 2019 01:32:46 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 31 Aug 2019 01:32:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g9xM+VodfR9puUgdJLN5x0UfN5FRU31P49ZuVKjoKn7kUXy9Zn3pb9BqhpSKqDb0TxT2AfVYepNmoK3cI5lgdVd4TV+oitZm63iKZ7eXYxAOLLz/QpDmTVfC7PeNueYkSosat4Jas0nPzN6CjRairEPCkGlMdiU6wEQGFA3DlhFjgKuSqjo0bPHKWJaOie/gmHz9XJDCbnaYrZywMintMlOuWPdKtHEhP+cS6LAMVCEQB+v9pj3mkeaY0iUDCHk6E8EWQ2nvDHOyAL/iGqNxRzv1QYZGpuNs/1cIjMc0EaIxzihhR8orbbmqWe4GyBXMUx1c7lA88XclmPsv5WmLPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lYmZmamH0ussxfw9JLgNaBTBB5DIThMZkR9/f6fyIxk=; b=C7+znZCQvLGp5SU1XUSs0Ln0sNMaBzZDRWUWeT9ofzWclBk4sCS1Abkb6DnCPrTDS1pmzoiN0D88vYZShMRYQau2ayGIr1iP5XhLeYKjuyQd7WztGFhnwKEdg0C32cW3WU12Mq0H+DFCLjm4R7izjgba5yXqAv88pRtYWTSGvRJbWWt0CqafMkI8+3otGuAlNkqRPjWlF9ZTeIHe2COsB+7rrexhRuX02gjlnR1rgUZ2d+jfdXu5QsEcyWmfznIDokbodrtPg7b5ZYD0dRxJfMSCgPBt2VW+o670KGhfBZWC0mGZ3KrT9JhiZw9wHhUMaBKpq35hO+IxpE9FVrVvkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lYmZmamH0ussxfw9JLgNaBTBB5DIThMZkR9/f6fyIxk=; b=ok4jNzXFumDdQrGeM6CZyLl1e5MQdN077yo04gBVEoaAacEiMedH2vA4Zyam81VXxqXahCEAl/oFebw87qZLyD6AstFW32wmR3AKVMsZHLWSPl+PS2V0dGmTbvqQ5ifMC1O0F6+NxFBILmG/VZNorOpirVQqrRcXQMC3bFsTazA= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3904.namprd11.prod.outlook.com (10.255.180.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Sat, 31 Aug 2019 06:32:43 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b%6]) with mapi id 15.20.2199.021; Sat, 31 Aug 2019 06:32:43 +0000 From: "Eric Vyncke (evyncke)" To: Kent Watsen CC: The IESG , "netmod-chairs@ietf.org" , "draft-ietf-netmod-artwork-folding@ietf.org" , "netmod@ietf.org" Thread-Topic: =?utf-8?B?W25ldG1vZF0gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0?= =?utf-8?Q?-ietf-netmod-artwork-folding-08:_(with_COMMENT)?= Thread-Index: AQHVX5ma4eSMEyjm+UCWg10E/y6oS6cU7h2A Date: Sat, 31 Aug 2019 06:32:43 +0000 Message-ID: <212876F1-B18B-4079-AA27-9BBBFF3E876E@cisco.com> References: <156681945152.25367.12793164355343396320.idtracker@ietfa.amsl.com> <0100016ce53de468-52c4c33a-5dc2-4074-adee-bb8a0f912826-000000@email.amazonses.com> In-Reply-To: <0100016ce53de468-52c4c33a-5dc2-4074-adee-bb8a0f912826-000000@email.amazonses.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:1cc7:aa56:5f89:fdc7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9484d50-1bb9-4349-b34c-08d72ddd07e6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3904; x-ms-traffictypediagnostic: MN2PR11MB3904: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(366004)(39860400002)(199004)(189003)(53546011)(58126008)(102836004)(54906003)(6506007)(4326008)(6436002)(86362001)(486006)(236005)(54896002)(6306002)(6512007)(316002)(21615005)(446003)(224303003)(2906002)(11346002)(46003)(476003)(2616005)(36756003)(6246003)(53936002)(33656002)(6116002)(186003)(256004)(14444005)(91956017)(76116006)(66946007)(81156014)(8936002)(81166006)(66556008)(66476007)(7736002)(64756008)(66446008)(71200400001)(229853002)(71190400001)(5660300002)(6486002)(606006)(25786009)(6916009)(966005)(478600001)(76176011)(99286004)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3904; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d/YnILnED0fUDZanpXS6E9ITbLUbaL9aNVvJJ19qJL+cLrq6r5z8bmvV5I+lSP9jFSjRJGT9AxuV5ppymwesmBxch8B624OxrHeGScliLGuXx6LhCMh1gOGWr49t8W24xGvzlJffqPMkENDI9xD5rSBWAsj9tCzCYKv1x/hHWXlbZMY+Lh+bopamcRFsgV7AuyF9vf/1gzo6F9BJbolPSQayQuKu7c9wPC4xtxPVDN7OKuGVQZNLAXkeq6umkXg6fu7ufTRScHtB57wEcferhhocKXsxSlCWIUUirRD59OKdy2HB9pGiDUv3G5Dt27VnawkXi3fzwg3oIeFG7/SeDIBtlDw/SePdlDEQr4GL6o0DIFYXbBANP/f+r7a4X7+um1ql3EbgSid+I5bKR+dWQf4WYpnmVG6mr4BjlE0QIRU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_212876F1B18B4079AA279BBBFF3E876Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9484d50-1bb9-4349-b34c-08d72ddd07e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 06:32:43.8647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sAnW0ib6OLOyG4gzxHnt6m/9cllyndcOZkDn/8QvZP4pZiXpfCYUMSrxjS3Y8j5Tao8+OeoP0Az0PyTP7O1bZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3904 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netmod] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-netmod-artwork-folding-08=3A_=28with_COMMENT=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 06:32:51 -0000 --_000_212876F1B18B4079AA279BBBFF3E876Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEtlbnQNCg0KRnJvbTogS2VudCBXYXRzZW4gPGtlbnRAd2F0c2VuLm5ldD4NCkRh dGU6IFNhdHVyZGF5LCAzMSBBdWd1c3QgMjAxOSBhdCAwMzoxNQ0KVG86IEVyaWMgVnluY2tlIDxl dnluY2tlQGNpc2NvLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sICJuZXRtb2Qt Y2hhaXJzQGlldGYub3JnIiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4sICJkcmFmdC1pZXRmLW5l dG1vZC1hcnR3b3JrLWZvbGRpbmdAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3Jr LWZvbGRpbmdAaWV0Zi5vcmc+LCAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtuZXRtb2RdIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDg6ICh3aXRoIENPTU1FTlQpDQoNCkhpIEVy aWMsDQoNCkkgYWRkZWQgcmVmZXJlbmNlcyBmb3IgJ3B5YW5nJyBhbmQgJ3lhbmdsaW50JyBpbiB0 aGUgbGF0ZXN0IHVwZGF0ZToNCg0KICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbmV0bW9kLWFydHdvcmstZm9sZGluZy0wOQ0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpP biBBdWcgMjYsIDIwMTksIGF0IDc6MzcgQU0sIMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIg PG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNCg0Kw4ly aWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K ZHJhZnQtaWV0Zi1uZXRtb2QtYXJ0d29yay1mb2xkaW5nLTA4OiBObyBPYmplY3Rpb24NCg0KV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRp bmcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTb21l dGltZXMgYSBzbWFsbCBwcm9ibGVtIChsaWtlIGxpbmUgZm9sZGluZykgY2FuIGJlIGFubm95aW5n Li4uIHNvIHRoYW5rIHlvdQ0KZm9yIGF1dGhvcmluZyB0aGlzIGRvY3VtZW50Lg0KDQpKdXN0IGEg bWlub3IgY29tbWVudDoNCi0gc2hvdWxkICdweWFuZycgYW5kICd5YW5nbGludCcgYmUgYWRkZWQg dG8gdGhlIHJlZmVyZW5jZXMgPw0KDQotw6lyaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= --_000_212876F1B18B4079AA279BBBFF3E876Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgS2VudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPktlbnQgV2F0c2Vu ICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCAzMSBB dWd1c3QgMjAxOSBhdCAwMzoxNTxicj4NCjxiPlRvOiA8L2I+RXJpYyBWeW5ja2UgJmx0O2V2eW5j a2VAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+VGhlIElFU0cgJmx0O2llc2dAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtuZXRtb2QtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRtb2QtY2hh aXJzQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1uZXRtb2QtYXJ0d29yay1mb2xkaW5n QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmdAaWV0 Zi5vcmcmZ3Q7LCAmcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtuZXRtb2RdIMOJcmljIFZ5bmNrZSdzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDg6ICh3aXRo IENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkhpIEVyaWMsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ SSBhZGRlZCByZWZlcmVuY2VzIGZvciAncHlhbmcnIGFuZCAneWFuZ2xpbnQnJm5ic3A7aW4gdGhl IGxhdGVzdCB1cGRhdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDk8L2E+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5L ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk9uIEF1ZyAyNiwgMjAxOSwgYXQgNzozNyBBTSwgw4lyaWMgVnlu Y2tlIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmci Pm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLW5ldG1vZC1hcnR3b3JrLWZvbGRp bmctMDg6IE5vIE9iamVjdGlvbjxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0K PGJyPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PGJyPg0KZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQo8 YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u cywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtYXJ0d29yay1mb2xkaW5nLyI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtYXJ0d29yay1mb2xkaW5n LzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU29tZXRpbWVzIGEgc21hbGwgcHJvYmxlbSAo bGlrZSBsaW5lIGZvbGRpbmcpIGNhbiBiZSBhbm5veWluZy4uLiBzbyB0aGFuayB5b3U8YnI+DQpm b3IgYXV0aG9yaW5nIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSnVzdCBhIG1pbm9yIGNvbW1l bnQ6PGJyPg0KLSBzaG91bGQgJ3B5YW5nJyBhbmQgJ3lhbmdsaW50JyBiZSBhZGRlZCB0byB0aGUg cmVmZXJlbmNlcyA/PGJyPg0KPGJyPg0KLcOpcmljPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGlu ZyBsaXN0PGJyPg0KbmV0bW9kQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_212876F1B18B4079AA279BBBFF3E876Eciscocom_-- From nobody Sat Aug 31 03:11:56 2019 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480C312007A; Sat, 31 Aug 2019 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=fastmail.fm header.b=BNkfbicj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b9psEeA3 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 4whGPDi_2QXH; Sat, 31 Aug 2019 03:11:46 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBD5120020; Sat, 31 Aug 2019 03:11:46 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9130B21EB2; Sat, 31 Aug 2019 06:11:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 31 Aug 2019 06:11:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=+ FVWMKYUQiR0YkTscW5UisJyAM02k0MU/v0g97ErlMc=; b=BNkfbicjmCnK/OVih blwScbP/qkmlcaqgqcTwAwJWOWrwKJVCPyP/8kjEfr7BinkQPv1cwY7Cf6bFyaXS xwe/KKbypKsLyMnhVzUEnm7MRLU5THl3vLj/wE9AKymR7XSh4IiZBzzgHJjqRgZ8 UFFDC0Ed1voMODCStFdHWFynGAdHiAbaw0x/18KAISvWGAGwYx2YZJYHFoZtFarG 8s4G95eURK07/qhy3XZhmTNPpJ0xZVyos/upIRJc+3b+Yk25mFGARjHh3rlSueVg RRBGVTAtF6o/+UKAqubE0TBui0ZPllKG1hjMrsEMDD09G+Cu1VtMRiEhvs8IiTAG 6IhQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=+FVWMKYUQiR0YkTscW5UisJyAM02k0MU/v0g97Erl Mc=; b=b9psEeA3X8LH8Xk7VJ9Fr8iOa399Rea2TLiQyBEq+301m7XQEuTzWrslv grGkg605YoeFarfdEr+JG7sEG/3C1di9doNuYUkZYVj+dCROWaoeEeKACIkdV8DS aBxjzgUt3lsSlrUehdmRyae1ahRVgeU4Z79G8jg7y6VC0zMsbATGlyaG88Txjjls Z8gEFlrY0Bl5nzs8IMCkNNRj4XXDC4jxFIalmAqwuYjhQqGMRSk4fUUJn8Dxp2w2 mubiE+giWo76PUMOe9NDZkAA3U5HRX6WTYv3qTSfX0cwPr71M7o/VPKo+pP2iwrk NTrgKVRlY1BTeRycwZ0okdf07qWvA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeihedgudehiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhffojgffgffkfhfvsegrjehmrehhtdejnecuhfhrohhmpeetlhgv gigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejjedrleejrddugeehrdeh heenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrg hilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.0.12] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id AEF2CD60057; Sat, 31 Aug 2019 06:11:42 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8B9250C9-296F-4384-958D-6ACD1221BE32 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <0100016ce53e2b5d-fb76ed79-acf5-4932-912e-260f69c91f11-000000@email.amazonses.com> Date: Sat, 31 Aug 2019 11:11:41 +0100 Cc: Barry Leiba , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org, The IESG , Lou Berger Content-Transfer-Encoding: 7bit Message-Id: References: <156701823840.1110.12340821702774896307.idtracker@ietfa.amsl.com> <0100016cda414a2b-9c5e2b3c-96c0-4a7e-99d0-54f227d5155c-000000@email.amazonses.com> <3A93201E-9027-4415-80B5-4DEF49190D10@fastmail.fm> <5acf4990-5819-421c-bdbe-0245ab3f5ce2@www.fastmail.com> <0100016cdd9eeaa2-00a68cf6-d967-4a31-9598-eb896edb0b34-000000@email.amazonses.com> <0100016ce53e2b5d-fb76ed79-acf5-4932-912e-260f69c91f11-000000@email.amazonses.com> To: Kent Watsen Archived-At: Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-artwork-folding-08: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 10:11:48 -0000 --Apple-Mail-8B9250C9-296F-4384-958D-6ACD1221BE32 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kent, > On 31 Aug 2019, at 02:15, Kent Watsen wrote: >=20 > Hi Alexey (and Barry), >=20 > I have clarified forced-foldings in the latest update: >=20 > https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-09 This is helpful, thank you! >=20 > Please let me know if this clears your DISCUSS. >=20 > Thanks, > Kent >=20 >=20 >> On Aug 29, 2019, at 9:47 AM, Barry Leiba wrote:= >>=20 >> You're saying, then, that "This line ends with a backslash >> \\[EOL][EOL]" only loses the last "\" in unfolding, because there is >> no space character on the next line. Is that right? If so, Alexey is >> right that the algorithm doesn't say that. >>=20 >> Barry >>=20 >>> On Thu, Aug 29, 2019 at 9:44 AM Kent Watsen wrote= : >>>=20 >>>=20 >>>=20 >>> On Aug 29, 2019, at 9:36 AM, Alexey Melnikov wr= ote: >>>=20 >>> On Thu, Aug 29, 2019, at 2:31 PM, Barry Leiba wrote: >>>=20 >>> The example is set up so that the source is in 9.4, 9.4.1 is the >>> result of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding" >>> of 9.4. >>>=20 >>> So the original source (in 9.4) was "This line ends with a backslash \".= >>> The result of "\ folding" gives "This line ends with a backslash \\", >>> because the backslash had to be escaped. >>>=20 >>>=20 >>> But the algorithm described in prose says absolutely nothing about escap= ing trailing "\"! So why the example is Ok, it just doesn't match the foldin= g algorithm. >>>=20 >>>=20 >>> The word "escape" is a bit misleading, even though, in a way, that is wh= at is happening (e.g., working around a special character), but it's not "es= caping" in the traditional sense (i.e., the first '\' is in no way giving sp= ecial significance to the second '\'). What's really going on is better des= cribed as a forced folding on a line that contains an invalid end-of-line se= quence. Makes sense? >>>=20 >>> Kent // co-author >>>=20 >>>=20 >>>=20 >>> Barry >>>=20 >>> On Thu, Aug 29, 2019 at 4:55 AM Alexey Melnikov = wrote: >>>=20 >>>=20 >>> Hi Kent, >>>=20 >>> On 28 Aug 2019, at 23:03, Kent Watsen wrote: >>>=20 >>> Hi Alexey, >>>=20 >>> Response at bottom. >>>=20 >>> Kent >>>=20 >>>=20 >>> On Aug 28, 2019, at 2:50 PM, Alexey Melnikov via Datatracker wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-netmod-artwork-folding-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> Thank you for your document. >>>=20 >>> It might be just me, but I think your examples in 9.4.1 with trailing \ d= on=E2=80=99t >>> seem to match the folding algorithm in section 7, as it doesn=E2=80=99t d= escribe >>> special handling of trailing \. >>>=20 >>>=20 >>> Can you be more specific regarding what it is you think doesn't match? = Step (2) says, at the location where the fold is to occur, insert '\' follo= wed by '\n'. That appears to be what is shown in 9.4.1, yes? >>>=20 >>>=20 >>> In the HTML version (in datatracker) I am seeing: >>>=20 >>> =E2=80=9CThis line ends with a backslash \\=E2=80=9D >>>=20 >>> followed by an empty line. So I see 2 trailing \ followed by end of line= , instead of \, end of line, and then \. >>>=20 >>>=20 >>> FWIW, the text in Section 9.4.1 (as with all the examples in the draft) w= as dynamically-generated (at draft build time) by feeding the text in Sectio= n 9.4 into the script in the Appendix A. >>>=20 >>> Kent // co-author >>>=20 >>>=20 >>>=20 >>>=20 >=20 --Apple-Mail-8B9250C9-296F-4384-958D-6ACD1221BE32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi K= ent,

On 31 Aug 2019, at 02:15, Kent Watsen <kent+ietf@watsen.net> wrote:
<= br>
Hi Alexey (and Barry),

I have clarified forced-foldi= ngs in the latest update:


This is hel= pful, thank you!

Please let me know if this clears yo= ur DISCUSS.

Thanks= ,
Kent


On Aug 29, 2019, at 9:47 AM, Barry Leiba <barryleiba@computer.org> wrote:
You're= saying, then, that "This line ends with a backslash
\\[EOL][E= OL]" only loses the last "\" in unfolding, because there is
no= space character on the next line.  Is that right?  If so, Alexey i= s
right that the algorithm doesn't say that.
Barry

On Thu, Aug 29, 2019 at 9:44 A= M Kent Watsen <kent+ie= tf@watsen.net> wrote:



On Aug 29, 2019, at 9:36 AM,= Alexey Melnikov <aa= melnikov@fastmail.fm> wrote:

On Thu, Aug= 29, 2019, at 2:31 PM, Barry Leiba wrote:

The e= xample is set up so that the source is in 9.4, 9.4.1 is the
re= sult of "\ folding" of 9.4, and 9.4.2 is the result of "\\ folding"
of 9.4.

So the original source (in 9.4) w= as "This line ends with a backslash \".
The result of "\ foldi= ng" gives "This line ends with a backslash \\",
because the ba= ckslash had to be escaped.


But t= he algorithm described in prose says absolutely nothing about escaping trail= ing "\"! So why the example is Ok, it just doesn't match the folding algorit= hm.


The word "escape" is a bit m= isleading, even though, in a way, that is what is happening (e.g., working a= round a special character), but it's not "escaping" in the traditional sense= (i.e., the first '\' is in no way giving special significance to the second= '\').  What's really going on is better described as a forced folding o= n a line that contains an invalid end-of-line sequence.  Makes sense?
Kent // co-author

<= br class=3D"">
Barry

On Thu, Aug 2= 9, 2019 at 4:55 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:


Hi Kent,

On 28 Aug 2019, a= t 23:03, Kent Watsen <= kent+ietf@watsen.net> wrote:

Hi Alexey,<= br class=3D"">
Response at bottom.

Kent


On Aug 28, 2019, at 2:50 P= M, Alexey Melnikov via Datatracker <noreply@ietf.org> wrote:

Alexe= y Melnikov has entered the following ballot position for
draft= -ietf-netmod-artwork-folding-08: Discuss

When r= esponding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut thisintroductory paragraph, however.)

<= br class=3D"">Please refer to https://www.ietf.org/iesg/statement/discu= ss-criteria.html
for more information about IESG DISCUSS a= nd COMMENT positions.


The docume= nt, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding= /



-----------= -----------------------------------------------------------
DI= SCUSS:
-------------------------------------------------------= ---------------

Thank you for your document.
It might be just me, but I think your examples in= 9.4.1 with trailing \ don=E2=80=99t
seem to match the folding= algorithm in section 7, as it doesn=E2=80=99t describe
specia= l handling of trailing \.


Can yo= u be more specific regarding what it is you think doesn't match?   = ;Step (2) says, at the location where the fold is to occur, insert '\' follo= wed by '\n'.  That appears to be what is shown in 9.4.1, yes?


In the HTML version (in datatracker) I am s= eeing:

=E2=80=9CThis line ends with a backslash= \\=E2=80=9D

followed by an empty line. So I se= e 2 trailing \ followed by end of line, instead of \, end of line, and then \= .


FWIW, the text in Section 9.4.= 1 (as with all the examples in the draft) was dynamically-generated (at draf= t build time) by feeding the text in Section 9.4 into the script in the Appe= ndix A.

Kent  // co-author
<= br class=3D"">



= --Apple-Mail-8B9250C9-296F-4384-958D-6ACD1221BE32--