From nobody Wed Nov 1 11:53:51 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE743139612; Wed, 1 Nov 2017 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAl4xu1SgK1K; Wed, 1 Nov 2017 11:53:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7C813F87C; Wed, 1 Nov 2017 11:53:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA1IrcjI004391; Wed, 1 Nov 2017 18:53:38 GMT Received: from 950129200 (254.196.113.87.dyn.plus.net [87.113.196.254]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA1Ira6R004372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Nov 2017 18:53:37 GMT Reply-To: From: "Adrian Farrel" To: Cc: , , Date: Wed, 1 Nov 2017 18:53:35 -0000 Message-ID: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdNTQrIO97lGRZjDTByyHTzDwLaeVQ== X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23434.002 X-TM-AS-Result: No--17.531-10.0-31-10 X-imss-scan-details: No--17.531-10.0-31-10 X-TMASE-MatchedRID: mKQO0h0Bck5tcr/uuDMv3m7hbmASKcrpQPCWRE0Lo8LIvQIyugvKdVjt prj9/vncRTpdHYygurQZwn7DIQtGC+4dcT3ZaToc+L2GsArAgtofXzVgO0hVqhW4PjzZ50/jMtY +alBD5ALetqCOhM9ls/thAPwiumCncVcsgVCVf8Vdxv5RmV3KC23eqxoVjgMEHWNaMBkegSfJTt eBOzpbgvD2wbKkvoqCr7t6OWlLJrw3IAlnCz/XMYdlc1JaOB1TkUtSee+57IH2Jzqp3fkNE3ory 7LEZ/71w/o6/kyrembJp2D4aumo7Lsl8Gv1eXkKRAvohSJUpI9RwfT2oEaYdGsTVziYHlSa9dB3 QPuA1xWs5qWj5r/l1zf9o2/0YdMdBYAV6EZJorJo2fKvznNZwMd5cqtswikAqpNaTZ0S3FoezV0 lIgz9uiTACfrZ6hofAGNtSDyz8sYqACWCM+FilqOuVibdZNTvveCbyZ3xax52iqcE/RbrKLE+hk hRyJ1V4nlXq9Sz6hQ9dnB5Mf9Aa6Yy2qfD59i787gU9YZmSw/vkROLxAaM3KBp/T5dSs2Tgo4eB 1LnWgiI7qXZddSBHfhwH/7pGOPdgtJ1kfzs6mBlI0vGyCjKv1Nn42YjbyMpStZtgyGdXLP31pa3 bg57F/53mchhBKw5YpDBQqe7Xi8yCh7sleAnD+XP7JqXOmP+ftnnpG0AB3WPcd2jEAJg7URdSGQ iaJZz8azB+j7c5JQZNgTPgsbY9S2DV9S/r9yeSxG/I0MjmF5zmB71otxffKkZyr3BN6qIcKcH6d pKXP0zDwDbj/+DgoS+UIhwPrWIJa+FAG1BTBOeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: Subject: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:53:44 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsawg-mud-13.txt Reviewer: Adrian Farrel Review Date: 1 November 2017 IETF LC End Date: 7 November 2017 Intended Status: Standard Track Overview Manufacturer Usage Descriptions (MUD) provide a means for elements of an IoT network to indicate what sorts of access and network functionality they require in order to function properly. The emphasis of this document is on access control although the authors envision future extensions for "other aspects". The document is a collection of bits and pieces to enable MUD: two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension, and a means to sign and verify the descriptions. Some future work is listed, but I see no evidence that this work is actually anything more than a possibility: there are no drafts that appear to cover any additional MUD specifications. Summary: I have some minor concerns about this document that I think should be resolved before publication. I have flagged one of these as a more serious issue, although I think it may be possible to solve with some 2119 language that governs expectations on implementations. The document was easy to read although the number of minor issues and nits in the early section suggests that the late-stage reviews were more focused on the YANG than the text. Adrian === Major Issues: I know I ranted about privacy before and the authors took some text I wrote as the basis of the privacy considerations, but I'm still worried that the default will be that devices are MUD-enabled (good) and that users will not be protected. It would be sad if the user's only option is to reject MUD devices (especially as they might not even know that the devices are MUD-enabled). More burble below, but it seems to me that we should make privacy-supporting modes of operation at least the default, but possibly the only approach. Section 15 has... The release of a MUD URL by a Thing reveals what the Thing is, and provides an attacker with guidance on what vulnerabilities may be present. Pleased to see this text: it was a security concern I had. Good to have it flagged. However, the mitigation suggested 2 paragraphs later is a bit thin and sounds rather optional. I see how an implementer might take action, but what can a user do to protect their device? Similarly, While the MUD URL itself is not intended to be unique to a specific Thing, the release of the URL may aid an observer in identifying individuals when combined with other information. This is a privacy consideration. This is not the only privacy issue since once a location or individual has been identified, the release of MUD URLs announce things about the location (such as what valuable Things are present and even what security devices are in use). Furthermore, the picture of an individual built up by knowing what Things they have is a substantial concern. At least in the first case the implementer has an interest in applying the protection, but the only person who cares about my privacy is me. What options do I have to protect myself (except not purchasing MUD- enabled devices which is presumably not the objective we want to pursue)? === Minor Issues: The last call indicated a Downref to draft-ietf-netmod-acl-model. All well and good. idnits reports RFC 2818 as a Downref as well, but didn't appear in the last call. --- Abstract Referring to "Things" is cute, but actually doesn't help the reader. Could you give a clue or two? BTW, the definition in 1.6 is a little thin and circular. A Thing is something to which you apply MUD, but what is it actually? --- The Abstract says... The initial focus is on access control. But the Introduction says... Although this memo may seem to stress access requirements, usage intent also consists of quality of service needs a device may have. Please decide which you mean. --- Introduction OLD The Internet has largely been constructed on general purpose computers, those devices that may be used for a purpose that is specified by those who buy the device. NEW The Internet is largely constructed from general purpose computers. These are devices that may be used for a purpose that is specified by those who buy the device. Although this is ambiguous and probably wrong: I think routers and switches probably form a part of the Internet, and I suspect they are somewhat specific to their use. --- Introduction In the context of a smarter device that has a built in Linux stack, it might be an integrator of that device. Is there something special about Linux? --- 1.5 This section introduces the "MUD controller." It's unexplained. It could be helpful to pull section 1.6 up perhaps to 1.3. --- There seems to be some overlap of terms and definitions in 1.5 and 1.6. --- 1.7 has a nice picture, thanks. But I note that the text describes a "web site" while the picture shows a "file server". Similarly, the text has "network management system" while the picture has "MUD controller". --- 3.3 makes reference to "is supported" and 3.4 gives clarity to what that means. Shouldn't this section also describe the meaning of this object when the Thang isn't supported? --- 3.5 has me confused. Looks like a fine idea, but how does it work? A Thing reports the MUD URL, and the file that is pulled contains the systeminfo URL, and the info that is pulled contains the localised info. Have I got that right? That means that the MUD URL has to include the correct systeminfo for the locality. Presumably we're interested in the locality of the MUD controller. The MUD controller knows its locality. Is it supposed to tell the web server? How else does the right systeminfo URL get provided, or the URL get mapped to the right localised information? --- 16.2 Something messed up here. We have The IANA has allocated option 161 in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry for the MUD DHCPv4 option. IANA is requested to allocated the DHCPv4 and v6 options as specified in Section 9. But section 9 has 161 and 112 explicitly mentioned. 116 is already in the registry, but presumably you have an IANA action to update the reference to this document when it becomes an RFC. 112 is also already in the DHCPv6 options registry. So you probably want to point at that instead of the current 2nd para. ==== Nits: Introduction Please do NOT use random uppercase words in your text. There's NO need: the readers are no more stupid than the average reader of an RFC. Ditto 3.4, 3.6 --- Introduction The key points are that the device itself is expected to serve a limited purpose, I think you mean s/expected/intended/ --- Introduction The intent of MUD is to solve for the following problems: d/for/ Although the list that follows is not a list of problems. So, perhaps, The intent of MUD is to provide the following function: --- Introduction o Provide for a means to scale network policies to the ever- increasing number types of devices in the network. d/for/ s/types/of types/ --- Introduction Provide a means to address at least some vulnerabilities in a way that is faster than it might take to update systems. s/than/than the time/ --- Introduction o A classifier that a device emits that can be used to locate a description; Classifier or classification? --- OLD 1.1. What MUD doesn't do NEW 1.1. What MUD Doesn't Do --- Section 1.1 No matter how good a MUD-enabled network is, it will never replace the need for manufacturers to patch vulnerabilities. It may, however, provide network administrators with some additional protection when those vulnerabilities exist. Does this paragraph belong in this section? Seems to say what MUD does, not what MUD doesn't do. Maybe flip the order of presentation?... MUD may provide network administrators with some protection when vulnerabilities exist, however, no matter how good a MUD-enabled network is, it will never replace the need for manufacturers to patch vulnerabilities. --- 1.2 s/an app on smart phone/an application on a smart phone/ --- 1.4 para 2 Might be worth splitting this into bullets --- 1.5 s/configuration of is/configuration is/ --- 2. s/only"accept"/only "accept"/ --- I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to explain the notation used in this document. --- 3. Note that in this section, when we use the term "match" we are referring to the ACL model "matches" node, and thus returns positive such that an action should be applied. Is that English? I know what it means, but not what it says. --- 3.1 s/containers indicate/containers indicates/ --- 3.1 [I-D.ietf-netmod-acl-model] describes access-lists but does not attempt to indicate where they are applied as that is handled elsewhere in a configuration "a configuration file?" "operation"? "in configuration information"? --- 3.8 Say that this is a null-valued node --- 3.11 s/mud/MUD/ From nobody Wed Nov 1 15:39:19 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052E913F754; Wed, 1 Nov 2017 15:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy2cHpstj7zQ; Wed, 1 Nov 2017 15:39:08 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CBB13F70B; Wed, 1 Nov 2017 15:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34101; q=dns/txt; s=iport; t=1509575947; x=1510785547; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ba78W3jvLhiuEwOKsmkJAEOmxHlAXunPfB9tdbHA1AM=; b=UMilimePh3iR0G/aRl29NbxLOLY1nd7AJnB223lVTeqYeUaHXUU6JPms DYZs8FL75GVCotDN/D2nUEC9WmtqQ+lAHClc7j1ne1S80WdGJmjhajm/Q f0kM+kBHhq4dqZ9K3w79+Uwpb7a9FDOoXhaRA8f8tYJUqHBsaZyNvzB+f s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAwCYS/pZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzGBEjk1JwGDfIofdI96Jn2VR4IRBwMjhRgChT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHQEBAQECARoJUQUFCwsUBCAKAgJXBwwIAQGKFwgQqQGCJyaKbAEBAQEBB?= =?us-ascii?q?QEBAQEBAQEBARAPgy6BZRGDTSkLgkE1gyKBSAsGNoJ1gmEFijKOUokGhEKCI4E?= =?us-ascii?q?Bg2eJL4IVXoUjg2AkhxaKLII0iTOBOR84gWw0IQgdFUmCZQiCToIJQDeKMYJEA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.44,331,1505779200"; d="asc'?scan'208,217";a="656716634" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2017 22:39:01 +0000 Received: from [10.61.88.6] (ams3-vpn-dhcp6151.cisco.com [10.61.88.6]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA1Md1UR009293; Wed, 1 Nov 2017 22:39:01 GMT To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> From: Eliot Lear Message-ID: <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> Date: Wed, 1 Nov 2017 23:38:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g6mCCiTVt5WPhsPjOOLc6hgOeukasiFBk" Archived-At: Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:39:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g6mCCiTVt5WPhsPjOOLc6hgOeukasiFBk Content-Type: multipart/mixed; boundary="O1CPM3d39gi4k7gq6Jj1Q2Q6wKg51CA9I"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org Message-ID: <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> Subject: Re: RTG-DIR review of draft-ietf-opsawg-mud-13 References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> In-Reply-To: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> --O1CPM3d39gi4k7gq6Jj1Q2Q6wKg51CA9I Content-Type: multipart/alternative; boundary="------------C2FA02EB029D14B419DF936D" Content-Language: en-US This is a multi-part message in MIME format. --------------C2FA02EB029D14B419DF936D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Adrian, Thanks again for your highly detailed review.=C2=A0 Please see below: On 11/1/17 7:53 PM, Adrian Farrel wrote: > Hello,=20 > > I have been selected as the Routing Directorate reviewer for this draft= =2E The > Routing Directorate seeks to review all routing or routing-related draf= ts as > they pass through IETF last call and IESG review, and sometimes on spec= ial > request. The purpose of the review is to provide assistance to the Rout= ing ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir=20 > > Although these comments are primarily for the use of the Routing ADs, i= t would > be helpful if you could consider them along with any other IETF Last Ca= ll > comments that you receive, and strive to resolve them through discussio= n or by > updating the draft.=20 > > Document: draft-ietf-opsawg-mud-13.txt > Reviewer: Adrian Farrel=20 > Review Date: 1 November 2017 > IETF LC End Date: 7 November 2017 > Intended Status: Standard Track > > Overview > > Manufacturer Usage Descriptions (MUD) provide a means for elements o= f > an IoT network to indicate what sorts of access and network=20 > functionality they require in order to function properly. The=20 > emphasis of this document is on access control although the authors = > envision future extensions for "other aspects". > > The document is a collection of bits and pieces to enable MUD: two > YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix > specification, an X.509 certificate extension, and a means to sign a= nd > verify the descriptions. > > Some future work is listed, but I see no evidence that this work is = > actually anything more than a possibility: there are no drafts that = > appear to cover any additional MUD specifications. > =20 > Summary:=20 > > I have some minor concerns about this document that I think should be > resolved before publication. I have flagged one of these as a more > serious issue, although I think it may be possible to solve with some > 2119 language that governs expectations on implementations. > > The document was easy to read although the number of minor issues and > nits in the early section suggests that the late-stage reviews were mor= e > focused on the YANG than the text. > > Adrian > > =3D=3D=3D > > Major Issues:=20 > > I know I ranted about privacy before and the authors took some text I w= rote as > the basis of the privacy considerations, but I'm still worried that the= default > will be that devices are MUD-enabled (good) and that users will not be > protected. It would be sad if the user's only option is to reject MUD d= evices > (especially as they might not even know that the devices are MUD-enable= d). More > burble below, but it seems to me that we should make privacy-supporting= modes of > operation at least the default, but possibly the only approach. > > Section 15 has... > > The release of a MUD URL by a Thing reveals what the Thing is, and > provides an attacker with guidance on what vulnerabilities may be > present. > > Pleased to see this text: it was a security concern I had. Good to have= > it flagged. However, the mitigation suggested 2 paragraphs later is a > bit thin and sounds rather optional. I see how an implementer might > take action, but what can a user do to protect their device? [...] While this may not be a *perfect* solve for all of your concerns, I hope you will find=C2=A0 the proposal below Good Enough.=C2=A0 Keep in mind th= at we are attempting to address a very broad set of devices with a large variety of capabilities, from energy-harvesting devices that may never encrypt (think a wall switch) to devices that have heaps of power and memory (think robots).=C2=A0 Many of the devices have very limited privacy conce= rns, while others will have quite a few.=C2=A0 In addition, whatever capabilit= ies the device has must intersect the capabilities found in deployments. With all that in mind, what I propose is the following: * Add text that RECOMMENDs that devices make use of TEAP when there may be privacy concerns and when it is available; and * In other cases where privacy may be a concern, we should RECOMMEND that a configuration option be provided, particularly when devices are designed to be mobile, which is where I think most of your concerns stem from. At the moment, you should also consider that devices leak like sieves.=C2= =A0 Bad guys can do a very good job of mapping devices they are looking for, and aggregating that information.=C2=A0 So before you go reaching for tha= t button, get hold of WireShark :-( And as you consider this as an issue, also consider the threat that you face at home.=C2=A0 Every single one of those devices, if hacked, will absolutely violate your privacy, to say the least.=C2=A0 The goal here is= to stop that. > > > =3D=3D=3D > > Minor Issues:=20 > > > The last call indicated a Downref to draft-ietf-netmod-acl-model. All w= ell and > good. > > idnits reports RFC 2818 as a Downref as well, but didn't appear in the = last > call. It's on the right list. > > --- > > Abstract > Referring to "Things" is cute, but actually doesn't help the reader.= > Could you give a clue or two? > > BTW, the definition in 1.6 is a little thin and circular. A Thing is=20 > something to which you apply MUD, but what is it actually? This is addressed, I think, in response to mnot's review. > > --- > > The Abstract says... > > The initial focus is on access control. > > But the Introduction says... > > Although this memo may seem to stress > access requirements, usage intent also consists of quality of servic= e > needs a device may have. > > Please decide which you mean. Right.=C2=A0 Mark caught this as well. > --- > > Introduction > > OLD > The Internet has largely been constructed on general purpose > computers, those devices that may be used for a purpose that is > specified by those who buy the device. > NEW > The Internet is largely constructed from general purpose computers. > These are devices that may be used for a purpose that is specified b= y > those who buy the device. > > Although this is ambiguous and probably wrong: I think routers and=20 > switches probably form a part of the Internet, and I suspect they are > somewhat specific to their use. I think the participle we are looking for is "for".=C2=A0 Propose to chan= ge to that. > > --- > > Introduction > > In the context of a smarter > device that has a built in Linux stack, it might be an integrator of= > that device. > > Is there something special about Linux? That's meant as an example, nothing more.=C2=A0 To clarify, I propose to = add "For example" in the previous sentence. > > --- > > 1.5 > This section introduces the "MUD controller." It's unexplained. > It could be helpful to pull section 1.6 up perhaps to 1.3. Ok. > --- > > There seems to be some overlap of terms and definitions in 1.5 and 1.6.= Can you be more specific? > > --- > > 1.7 has a nice picture, thanks. > > But I note that the text describes a "web site" while the picture shows= > a "file server". > > Similarly, the text has "network management system" while the picture > has "MUD controller". What I propose is to make the terms consistent, but added parentheticals to remind people what those terms mean. > > --- > > 3.3 makes reference to "is supported" and 3.4 gives clarity to what=20 > that means. Shouldn't this section also describe the meaning of this > object when the Thang isn't supported? That is actually discussed in Section 3.4 (these are short sections). > > --- > > 3.5 has me confused. Looks like a fine idea, but how does it work? A > Thing reports the MUD URL, and the file that is pulled contains the > systeminfo URL, and the info that is pulled contains the localised info= =2E > Have I got that right? Yes. > > That means that the MUD URL has to include the correct systeminfo for > the locality. Presumably we're interested in the locality of the MUD > controller. The intent here is basically to allow for language tags to do their thing through one level of indirection.=C2=A0 That doesn't require any specific change to the URL itself.=C2=A0 I've included some text in respo= nse to Mark, but that text may further shift based on other suggestions Mark may have. > > --- > > 16.2 > > Something messed up here. > > We have > > The IANA has allocated option 161 in the Dynamic Host Configuration > Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry > for the MUD DHCPv4 option. > > IANA is requested to allocated the DHCPv4 and v6 options as specifie= d > in Section 9. > > But section 9 has 161 and 112 explicitly mentioned. > > 116 is already in the registry, but presumably you have an IANA action > to update the reference to this document when it becomes an RFC. > > 112 is also already in the DHCPv6 options registry. > So you probably want to point at that instead of the current 2nd para. Yes.=C2=A0 Bad edit.=C2=A0 Thanks. > > =3D=3D=3D=3D =20 > > Nits:=20 > > Introduction > > Please do NOT use random uppercase words in your text. There's NO > need: the readers are no more stupid than the average reader of an > RFC. > > Ditto 3.4, 3.6 Sorry- I didn't parse this. > > --- > > Introduction > > The key points are that the device itself is expected > to serve a limited purpose, > > I think you mean s/expected/intended/ How about "assumed"? > --- > > Introduction > > The intent of MUD is to solve for the following problems: > > d/for/ > > Although the list that follows is not a list of problems. So, perhaps, > > The intent of MUD is to provide the following function: s/following function/following/ ? > > --- > > Introduction > > o Provide for a means to scale network policies to the ever- > increasing number types of devices in the network. > > d/for/ ok > s/types/of types/ right. > > --- > > Introduction > > Provide a means to address at least some vulnerabilities in a way= > that is faster than it might take to update systems. > > s/than/than the time/ > > --- > > Introduction > > o A classifier that a device emits that can be used to locate a > description; > > Classifier or classification? Classifier. > > --- > > OLD > 1.1. What MUD doesn't do > NEW > 1.1. What MUD Doesn't Do ok > > --- > > Section 1.1 > > No matter how good a MUD-enabled network is, it will never replace > the need for manufacturers to patch vulnerabilities. It may, > however, provide network administrators with some additional > protection when those vulnerabilities exist. > > Does this paragraph belong in this section? Seems to say what MUD does,= > not what MUD doesn't do. > > Maybe flip the order of presentation?... > > MUD may provide network administrators with some protection when > vulnerabilities exist, however, no matter how good a MUD-enabled=20 > network is, it will never replace the need for manufacturers to=20 > patch vulnerabilities.=20 How about: Although MUD can provide network administrators with some additional protection when=C2=A0=C2=A0=C2=A0 device vulnerabilities exist, it will n= ever replace the need for manufacturers to patch vulnerabilities. > > --- > > 1.2 > > s/an app on smart phone/an application on a smart phone/ ok > --- > > 1.4 para 2 > Might be worth splitting this into bullets ok > > --- > > 1.5 > s/configuration of is/configuration is/ ok > > --- > > 2. > > s/only"accept"/only "accept"/ ok > > --- > > I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to > explain the notation used in this document. I think this is broken off to another draft (draft-ietf-netmod-yang-tree-diagrams). > > --- > > 3. > Note that in this section, when we use the term "match" we are > referring to the ACL model "matches" node, and thus returns positive= > such that an action should be applied. > > Is that English? I know what it means, but not what it says. New text in response to review.=C2=A0 I don't think it's English either.=C2= =A0 I think a line was clipped accidentally.=C2=A0 I propose to delete everythi= ng after the comma. > > --- > > 3.1 > > s/containers indicate/containers indicates/ Good catch. > --- > > 3.1 > > [I-D.ietf-netmod-acl-model] describes access-lists but does not > attempt to indicate where they are applied as that is handled > elsewhere in a configuration > > "a configuration file?" "operation"? "in configuration information"? This text requires a small change, anyway. > > --- > > 3.8 > > Say that this is a null-valued node ok > --- > > 3.11 > s/mud/MUD/ > > Ok. And thanks again! Eliot --------------C2FA02EB029D14B419DF936D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Adrian,

Thanks again for your highly detailed review.=C2=A0 Please see bel= ow:


On 11/1/17 7:53 PM, Adrian Farrel wrote:
Hello,=20

I have been selected as the Routing Directorate reviewer for this draft. =
The
Routing Directorate seeks to review all routing or routing-related drafts=
 as
they pass through IETF last call and IESG review, and sometimes on specia=
l
request. The purpose of the review is to provide assistance to the Routin=
g ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg=
Dir=20

Although these comments are primarily for the use of the Routing ADs, it =
would
be helpful if you could consider them along with any other IETF Last Call=

comments that you receive, and strive to resolve them through discussion =
or by
updating the draft.=20

Document: draft-ietf-opsawg-mud-13.txt
   Reviewer: Adrian Farrel=20
   Review Date: 1 November 2017
   IETF LC End Date: 7 November 2017
   Intended Status: Standard Track

Overview

   Manufacturer Usage Descriptions (MUD) provide a means for elements of
   an IoT network to indicate what sorts of access and network=20
   functionality they require in order to function properly.  The=20
   emphasis of this document is on access control although the authors=20
   envision future extensions for "other aspects".

   The document is a collection of bits and pieces to enable MUD: two
   YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
   specification, an X.509 certificate extension, and a means to sign and=

   verify the descriptions.

   Some future work is listed, but I see no evidence that this work is=20
   actually anything more than a possibility: there are no drafts that=20
   appear to cover any additional MUD specifications.
  =20
Summary:=20

I have some minor concerns about this document that I think should be
resolved before publication. I have flagged one of these as a more
serious issue, although I think it may be possible to solve with some
2119 language that governs expectations on implementations.

The document was easy to read although the number of minor issues and
nits in the early section suggests that the late-stage reviews were more
focused on the YANG than the text.

Adrian

=3D=3D=3D

Major Issues:=20

I know I ranted about privacy before and the authors took some text I wro=
te as
the basis of the privacy considerations, but I'm still worried that the d=
efault
will be that devices are MUD-enabled (good) and that users will not be
protected. It would be sad if the user's only option is to reject MUD dev=
ices
(especially as they might not even know that the devices are MUD-enabled)=
=2E More
burble below, but it seems to me that we should make privacy-supporting m=
odes of
operation at least the default, but possibly the only approach.


Section 15 has...

   The release of a MUD URL by a Thing reveals what the Thing is, and
   provides an attacker with guidance on what vulnerabilities may be
   present.

Pleased to see this text: it was a security concern I had. Good to have
it flagged. However, the mitigation suggested 2 paragraphs later is a
bit thin and sounds rather optional. I see how an implementer might
take action, but what can a user do to protect their device? [...]


While this may not be a *perfect* solve for all of your concerns, I hope you will find=C2=A0 the proposal below Good Enough.=C2=A0 Keep i= n mind that we are attempting to address a very broad set of devices with a large variety of capabilities, from energy-harvesting devices that may never encrypt (think a wall switch) to devices that have heaps of power and memory (think robots).=C2=A0 Many of the devices have ve= ry limited privacy concerns, while others will have quite a few.=C2=A0 I= n addition, whatever capabilities the device has must intersect the capabilities found in deployments.

With all that in mind, what I propose is the following:
  • Add text that RECOMMENDs that devices make use of TEAP when there may be privacy concerns and when it is available; and
  • In other cases where privacy may be a concern, we should RECOMMEND that a configuration option be provided, particularly when devices are designed to be mobile, which is where I think most of your concerns stem from.

At the moment, you should also consider that devices leak like sieves.=C2=A0 Bad guys can do a very good job of mapping devices th= ey are looking for, and aggregating that information.=C2=A0 So before = you go reaching for that button, get hold of WireShark :-(

And as you consider this as an issue, also consider the threat that you face at home.=C2=A0 Every single one of those devices, if hacked, will absolutely violate your privacy, to say the least.=C2=A0= The goal here is to stop that.




=3D=3D=3D

Minor Issues:=20


The last call indicated a Downref to draft-ietf-netmod-acl-model. All wel=
l and
good.

idnits reports RFC 2818 as a Downref as well, but didn't appear in the la=
st
call.

It's on the right list.


---

Abstract
   Referring to "Things" is cute, but actually doesn't help the reader.
   Could you give a clue or two?

BTW, the definition in 1.6 is a little thin and circular. A Thing is=20
something to which you apply MUD, but what is it actually?

This is addressed, I think, in response to mnot's review.


---

The Abstract says...

   The initial focus is on access control.

But the Introduction says...

   Although this memo may seem to stress
   access requirements, usage intent also consists of quality of service
   needs a device may have.

Please decide which you mean.

Right.=C2=A0 Mark caught this as well.
---

Introduction

OLD
   The Internet has largely been constructed on general purpose
   computers, those devices that may be used for a purpose that is
   specified by those who buy the device.
NEW
   The Internet is largely constructed from general purpose computers.
   These are devices that may be used for a purpose that is specified by
   those who buy the device.

Although this is ambiguous and probably wrong: I think routers and=20
switches probably form a part of the Internet, and I suspect they are
somewhat specific to their use.

I think the participle we are looking for is "for".=C2=A0 Propose to change to that.


---

Introduction

   In the context of a smarter
   device that has a built in Linux stack, it might be an integrator of
   that device.

Is there something special about Linux?

That's meant as an example, nothing more.=C2=A0 To clarify, I propose= to add "For example" in the previous sentence.

---

1.5
This section introduces the "MUD controller." It's unexplained.
It could be helpful to pull section 1.6 up perhaps to 1.3.

Ok. 

---

There seems to be some overlap of terms and definitions in 1.5 and 1.6.

Can you be more specific?


---

1.7 has a nice picture, thanks.

But I note that the text describes a "web site" while the picture shows
a "file server".

Similarly, the text has "network management system" while the picture
has "MUD controller".

What I propose is to make the terms consistent, but added parentheticals to remind people what those terms mean.

---

3.3 makes reference to "is supported" and 3.4 gives clarity to what=20
that means.  Shouldn't this section also describe the meaning of this
object when the Thang isn't supported?

That is actually discussed in Section 3.4 (these are short sections).


---

3.5 has me confused. Looks like a fine idea, but how does it work? A
Thing reports the MUD URL, and the file that is pulled contains the
systeminfo URL, and the info that is pulled contains the localised info.
Have I got that right?
Yes.

That means that the MUD URL has to include the correct systeminfo for
the locality.  Presumably we're interested in the locality of the MUD
controller.

The intent here is basically to allow for language tags to do their thing through one level of indirection.=C2=A0 That doesn't require an= y specific change to the URL itself.=C2=A0 I've included some text in response to Mark, but that text may further shift based on other suggestions Mark may have.



---

16.2

Something messed up here.

We have

   The IANA has allocated option 161 in the Dynamic Host Configuration
   Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry
   for the MUD DHCPv4 option.

   IANA is requested to allocated the DHCPv4 and v6 options as specified
   in Section 9.

But section 9 has 161 and 112 explicitly mentioned.

116 is already in the registry, but presumably you have an IANA action
to update the reference to this document when it becomes an RFC.

112 is also already in the DHCPv6 options registry.
So you probably want to point at that instead of the current 2nd para.

Yes.=C2=A0 Bad edit.=C2=A0 Thanks.


=3D=3D=3D=3D    =20

Nits:=20

Introduction

   Please do NOT use random uppercase words in your text.  There's NO
   need: the readers are no more stupid than the average reader of an
   RFC.

Ditto 3.4, 3.6

Sorry- I didn't parse this.

---

Introduction

   The key points are that the device itself is expected
   to serve a limited purpose,

I think you mean s/expected/intended/

How about "assumed"?

---

Introduction

   The intent of MUD is to solve for the following problems:

d/for/

Although the list that follows is not a list of problems. So, perhaps,

   The intent of MUD is to provide the following function:

s/following function/following/ ?

---

Introduction

   o  Provide for a means to scale network policies to the ever-
      increasing number types of devices in the network.

d/for/

ok

s/types/of types/

right.


---

Introduction

      Provide a means to address at least some vulnerabilities in a way
      that is faster than it might take to update systems.

s/than/than the time/

---

Introduction

   o  A classifier that a device emits that can be used to locate a
      description;

Classifier or classification?

Classifier.

---

OLD
1.1.  What MUD doesn't do
NEW
1.1.  What MUD Doesn't Do

ok

---

Section 1.1

   No matter how good a MUD-enabled network is, it will never replace
   the need for manufacturers to patch vulnerabilities.  It may,
   however, provide network administrators with some additional
   protection when those vulnerabilities exist.

Does this paragraph belong in this section? Seems to say what MUD does,
not what MUD doesn't do.

Maybe flip the order of presentation?...

   MUD may provide network administrators with some protection when
   vulnerabilities exist, however, no matter how good a MUD-enabled=20
   network is, it will never replace the need for manufacturers to=20
   patch vulnerabilities.

How about:

Although MUD can provide network administrators with some additional<= br> protection when=C2=A0=C2=A0=C2=A0 device vulnerabilities exist, it wi= ll never replace the
need for manufacturers to patch vulnerabilities.

---

1.2

s/an app on smart phone/an application on a smart phone/

ok
---

1.4 para 2
Might be worth splitting this into bullets

ok

---

1.5
s/configuration of is/configuration is/

ok

---

2.

s/only"accept"/only "accept"/

ok

---

I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to
explain the notation used in this document.

I think this is broken off to another draft (draft-ietf-netmod-yang-tree-diagrams).


---

3.
   Note that in this section, when we use the term "match" we are
   referring to the ACL model "matches" node, and thus returns positive
   such that an action should be applied.

Is that English? I know what it means, but not what it says.

New text in response to review.=C2=A0 I don't think it's English eith= er.=C2=A0 I think a line was clipped accidentally.=C2=A0 I propose to delete everything after the comma.


---

3.1

s/containers indicate/containers indicates/

Good catch.

---

3.1

   [I-D.ietf-netmod-acl-model] describes access-lists but does not
   attempt to indicate where they are applied as that is handled
   elsewhere in a configuration

"a configuration file?" "operation"? "in configuration information"?

This text requires a small change, anyway.


---

3.8

Say that this is a null-valued node
ok
---

3.11
s/mud/MUD/

Ok.


And thanks again!

Eliot
--------------C2FA02EB029D14B419DF936D-- --O1CPM3d39gi4k7gq6Jj1Q2Q6wKg51CA9I-- --g6mCCiTVt5WPhsPjOOLc6hgOeukasiFBk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZ+kz1AAoJEIe2a0bZ0nozgsIIAMGFZv6gq/PhWas3++8eNwZ6 GrujALFjPA8ZexSjL1olgGK/ewLZ9uXRV8rEyVrNTEUB1NEq1ZQq+bL+RndkzMfK VrLHZcFayFZ/YUy1Et6/8DkvbHW4CeVHdRtDEpE++hmCFRoF8WwpImtNK4r9FLJV HQxlw5SEKF+BzfL9xnpxbuoHh2z7yMMFUcv5lb6gxptQLr/e5FbKAcn2w4axpZC3 s63tiCA16Ai7dYx/7NpxDxv8orrCoKjtB/ChOWrHZzPj0q3KjPQWDPYWUGo0/9p4 AWABI4cfb5NkmtaoptugVaPKzeuqG71ikCI9ojT2y6uwozwaZ+4D6yzrIl5e+hY= =6LS+ -----END PGP SIGNATURE----- --g6mCCiTVt5WPhsPjOOLc6hgOeukasiFBk-- From nobody Wed Nov 1 17:02:19 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A077C13FB8A; Wed, 1 Nov 2017 17:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdlSc3-Me2HJ; Wed, 1 Nov 2017 17:02:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046A8138BD6; Wed, 1 Nov 2017 17:02:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA2025eS005850; Thu, 2 Nov 2017 00:02:05 GMT Received: from 950129200 (254.196.113.87.dyn.plus.net [87.113.196.254]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA201v2T005817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Nov 2017 00:02:04 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , Cc: , , References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> In-Reply-To: <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> Date: Thu, 2 Nov 2017 00:01:55 -0000 Message-ID: <022901d3536d$d01d7b10$70587130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHbXiOVWYUGr+virfAy7t490kIJlgFDRd+PouXvjKA= X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23434.003 X-TM-AS-Result: No--25.587-10.0-31-10 X-imss-scan-details: No--25.587-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wj4PYxsTKj6OPllq4+7Psp9LjXXGQy6nlCU7 43HF3fJ1O2sF32mXbnzfneWgb0wCfhvMQPGNwEh5nbUZkYTzXIZT4DtiSkMnWHe9QDr8+LTcLHN FiwmJRq9g9QVv4yJoozMqW8WukwCx6xj9tplxe1otR8fVMTBo3eBgp+G3IXxrasEfs27jsmF33U cFnsV9K2Aa4EJHd+lhy2r0pKo9mL2BmL85GH6eoJU7Bltw5qVLLi2dwKiMR9zoN8DSoota+bJVv 13dZNfHed0d4sqKDsNW6DYmWGhh3b0LBwJblWbCiFoorQjboWkt9SM1xCCZI9qqof+gfD6RXdBQ Y13RVu+fHoYNv/tRVd0iK4aOzykGr4Tjl93LJlctMfCdg6KRDdSqEluSYtV7ZD2MRV9hScnGdRf PKx6LHGd012aNXJXONuVfhyZ1UoR/mtiXLG/iqwArNgt5xpQYQPCPzycuBFNrH7R0RhorDICjHI wimOiw41ajEsPwj9r4L3Nr51seQUHQ/pYAwhs64NAJeq9IDSxBAihwNc9u51c/CedjlcvkkJfLp HarHP0ExaFjjiqBlEBd8jXb7PkJVOdT7lcCJT6VSBCoZUyqbEH7wsB5444wGNAPebYwJ/v9aPr9 xdwJWeRMOKt5mOY0mpwWqsTbqy9EbxUbCvHWy7xygpRxo469xNK79ogfIKlO2MZoFipNWxB3/5R 3B1LBPDsVTI/DsCqZ+/AHXHSuX98B+f+wv7x4et6HZsHsM79G/JUd7BvSQp3BT+pdjEe8wr3tCV Ik66rR8zboG6RI6n0EqyYQ2mty6fLaoi+ilkSeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 00:02:13 -0000 This looks really good, Eliot. Thanks for being so responsive and = positive to my peculiar brand of paranoia and pedantry. Just a few bits of discussion remain... >> I know I ranted about privacy before and the authors took some text I = wrote >> as the basis of the privacy considerations, but I'm still worried = that the default >> will be that devices are MUD-enabled (good) and that users will not = be >> protected. It would be sad if the user's only option is to reject MUD = devices >> (especially as they might not even know that the devices are = MUD-enabled). >> More burble below, but it seems to me that we should make = privacy-supporting >> modes of operation at least the default, but possibly the only = approach. >> >> Section 15 has... >> >> The release of a MUD URL by a Thing reveals what the Thing is, and >> provides an attacker with guidance on what vulnerabilities may be >> present. >> >> Pleased to see this text: it was a security concern I had. Good to = have >> it flagged. However, the mitigation suggested 2 paragraphs later is a >> bit thin and sounds rather optional. I see how an implementer might >> take action, but what can a user do to protect their device? [...] > > While this may not be a *perfect* solve for all of your concerns, I = hope > you will find the proposal below Good Enough. Keep in mind that we > are attempting to address a very broad set of devices with a large = variety > of capabilities, from energy-harvesting devices that may never encrypt > (think a wall switch) to devices that have heaps of power and memory > (think robots). Many of the devices have very limited privacy = concerns, > while others will have quite a few. In addition, whatever = capabilities the > device has must intersect the capabilities found in deployments. > > With all that in mind, what I propose is the following: > =E2=80=A2 Add text that RECOMMENDs that devices make use of TEAP when = there > may be privacy concerns and when it is available; and > =E2=80=A2 In other cases where privacy may be a concern, we should = RECOMMEND > that a configuration option be provided, particularly when devices = are > designed to be mobile, which is where I think most of your concerns > stem from. This is getting gooder. Thanks. Even when the MUD controller is on the premises (the not mobile case), = it contacts an offsite file server, and that act is visible. Suppose my Hi-Fi uses MUD - now you know that my house is worth robbing. Suppose my intruder alarm uses MUD - now you know what security system I = have. Of course, when the MUD controller is remote (the mobile case), it's all = even more worrying. I know you are trying to trade between perfect and getting something = that will be implemented and so make the world a somewhat better place. = But just recall that someone implemented those devices that "leak like = sieves" and those folk are unlikely to see a Recommendation as anything = like a strong hint. Well, I'm not in a position to block the whole effort, and I'm not = enough of an expert to suggest a solution to my concern that works for = all types of device. >> There seems to be some overlap of terms and definitions in 1.5 and = 1.6. > > Can you be more specific? 1.5 and 1.6 both have "manufacturer". 1.5 has "controller" and 1.6 has "MUD controller". The definitions don't match. >> 3.5 has me confused. Looks like a fine idea, but how does it work? A >> Thing reports the MUD URL, and the file that is pulled contains the >> systeminfo URL, and the info that is pulled contains the localised = info. >> Have I got that right? > Yes. > >> That means that the MUD URL has to include the correct systeminfo for >> the locality. Presumably we're interested in the locality of the MUD >> controller. > > The intent here is basically to allow for language tags to do their = thing > through one level of indirection. That doesn't require any specific = change > to the URL itself. I've included some text in response to Mark, but = that > text may further shift based on other suggestions Mark may have. I'm missing something, but that's OK, I don't have to understand = something for it to be right :-) So long as it is possible for the MUD Controller to be in one locale and = the MUD Server in another and all the bits to work right, I'm happy. >> Introduction >> >> Please do NOT use random uppercase words in your text. There's NO >> need: the readers are no more stupid than the average reader of an >> RFC. >> >> Ditto 3.4, 3.6 > > Sorry- I didn't parse this. Sorry I'm being sassy. I mean, please don't capitalise for emphasis. Just limit yourself to = 2119 capitalisation. >> Introduction >> >> The key points are that the device itself is expected >> to serve a limited purpose, >> >> I think you mean s/expected/intended/ > > How about "assumed"? We're both being overly passive. Who has the = expectation/intention/assumption? By "intended" I meant "intended by the manufacturer". So, actually, any one of the three words is fine, if you can attribute = the verb to someone. >> Introduction >> >> o A classifier that a device emits that can be used to locate a >> description; >> >> Classifier or classification? > > Classifier. Oh. A "classifier" is a person or thing that classifies. I don't think the device emits a thing or a person :-) I think it emits a piece of information that allows the device to be = classified.=20 Cheers, Adrian From nobody Thu Nov 2 01:46:55 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A913FA89; Thu, 2 Nov 2017 01:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb0FoDqDv2wo; Thu, 2 Nov 2017 01:46:45 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D3013FA8A; Thu, 2 Nov 2017 01:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8583; q=dns/txt; s=iport; t=1509612405; x=1510822005; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7Op2zRXxlJPtHz74lS2s7/XhudF61wwsLu8m5guZ+Wc=; b=NsH0BPYBfcAd21rvkhu4UVANPtdW3hgW///IzKIVg0HoQOZO1/1Rj89Z 6TG9iRhdLaetZzEZvYUmqX1L9RNUSv4f+IXNIqdqa1wfJu6vS9r/riZcd //TtdKcuVpSFUUCkfIWoF64FXmOYJDBQS5aglkqqnU5dZ9Hz7/aY9pyYm 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABL2vpZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdJAifZVIghEHA4U7AoVGGAEBAQEBAQEBAWsohR0BAQE?= =?us-ascii?q?BAgEjSA4FCwsYKgICVwcMCAEBF4oACKhfgieLFwEBAQEBBQEBAQEBFA+DLoFlg?= =?us-ascii?q?14pgXRYNYRqAQoGgyuCYgWKMo5UiQeEQoIjjheCFYYDg2CHOpYWgTkfOIFsNCE?= =?us-ascii?q?IHRWDLoRfQIpbASaCHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,333,1505779200"; d="asc'?scan'208";a="5942" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 08:46:42 +0000 Received: from [10.61.88.6] (ams3-vpn-dhcp6151.cisco.com [10.61.88.6]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA28kgOg027478; Thu, 2 Nov 2017 08:46:42 GMT To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> <022901d3536d$d01d7b10$70587130$@olddog.co.uk> From: Eliot Lear Message-ID: <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> Date: Thu, 2 Nov 2017 09:46:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <022901d3536d$d01d7b10$70587130$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID" Archived-At: Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 08:46:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID Content-Type: multipart/mixed; boundary="THoqLSCOu4COKf0mml9UH2EslJFO3lqsx"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org Message-ID: <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> Subject: Re: RTG-DIR review of draft-ietf-opsawg-mud-13 References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> <022901d3536d$d01d7b10$70587130$@olddog.co.uk> In-Reply-To: <022901d3536d$d01d7b10$70587130$@olddog.co.uk> --THoqLSCOu4COKf0mml9UH2EslJFO3lqsx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, On 11/2/17 1:01 AM, Adrian Farrel wrote: > This looks really good, Eliot. Thanks for being so responsive and posit= ive to my peculiar brand of paranoia and pedantry. Not at all, and thanks for improving the work. > Just a few bits of discussion remain... > >>> I know I ranted about privacy before and the authors took some text I= wrote >>> as the basis of the privacy considerations, but I'm still worried tha= t the default >>> will be that devices are MUD-enabled (good) and that users will not b= e >>> protected. It would be sad if the user's only option is to reject MUD= devices >>> (especially as they might not even know that the devices are MUD-enab= led). >>> More burble below, but it seems to me that we should make privacy-sup= porting >>> modes of operation at least the default, but possibly the only approa= ch. >>> >>> Section 15 has... >>> >>> The release of a MUD URL by a Thing reveals what the Thing is, and >>> provides an attacker with guidance on what vulnerabilities may be >>> present. >>> >>> Pleased to see this text: it was a security concern I had. Good to ha= ve >>> it flagged. However, the mitigation suggested 2 paragraphs later is a= >>> bit thin and sounds rather optional. I see how an implementer might >>> take action, but what can a user do to protect their device? [...] >> While this may not be a *perfect* solve for all of your concerns, I ho= pe >> you will find the proposal below Good Enough. Keep in mind that we >> are attempting to address a very broad set of devices with a large var= iety >> of capabilities, from energy-harvesting devices that may never encrypt= >> (think a wall switch) to devices that have heaps of power and memory >> (think robots). Many of the devices have very limited privacy concern= s, >> while others will have quite a few. In addition, whatever capabilitie= s the >> device has must intersect the capabilities found in deployments. >> >> With all that in mind, what I propose is the following: >> =E2=80=A2 Add text that RECOMMENDs that devices make use of TEAP when = there >> may be privacy concerns and when it is available; and >> =E2=80=A2 In other cases where privacy may be a concern, we should REC= OMMEND >> that a configuration option be provided, particularly when devices = are >> designed to be mobile, which is where I think most of your concerns= >> stem from. > This is getting gooder. Thanks. > Even when the MUD controller is on the premises (the not mobile case), = it contacts > an offsite file server, and that act is visible. > Suppose my Hi-Fi uses MUD - now you know that my house is worth robbing= =2E > Suppose my intruder alarm uses MUD - now you know what security system = I have. Here, I think you have some cause for hope, because on the whole, in the home, wireless encryption is generally used.=C2=A0 It's not perfect but w= ould address the point you make above. > Of course, when the MUD controller is remote (the mobile case), it's al= l even more worrying. Yes, and to that end I propose to highlight a particular warning for open networks (this would be one amongst many that developers should heed with regard to open networks). > > I know you are trying to trade between perfect and getting something th= at will be implemented and so make the world a somewhat better place. But= just recall that someone implemented those devices that "leak like sieve= s" and those folk are unlikely to see a Recommendation as anything like a= strong hint. My hope is that this problem will abate over time, but I really cannot say.=C2=A0 My guess is that the same who are unlikely to heed such a recommendation are also highly unlikely to implement MUD in the first pla= ce. > > Well, I'm not in a position to block the whole effort, and I'm not enou= gh of an expert to suggest a solution to my concern that works for all ty= pes of device. > >>> There seems to be some overlap of terms and definitions in 1.5 and 1.= 6. >> Can you be more specific? > 1.5 and 1.6 both have "manufacturer". > 1.5 has "controller" and 1.6 has "MUD controller". > The definitions don't match. Ah- that is because they are being used in different contexts.=C2=A0 One = is intended as a YANG node and the other really means those people who build the thing. > >>> 3.5 has me confused. Looks like a fine idea, but how does it work? A >>> Thing reports the MUD URL, and the file that is pulled contains the >>> systeminfo URL, and the info that is pulled contains the localised in= fo. >>> Have I got that right? >> Yes. >> >>> That means that the MUD URL has to include the correct systeminfo for= >>> the locality. Presumably we're interested in the locality of the MUD= >>> controller. >> The intent here is basically to allow for language tags to do their th= ing >> through one level of indirection. That doesn't require any specific c= hange >> to the URL itself. I've included some text in response to Mark, but t= hat >> text may further shift based on other suggestions Mark may have. > I'm missing something, but that's OK, I don't have to understand someth= ing for it to be right :-) > > So long as it is possible for the MUD Controller to be in one locale an= d the MUD Server in another and all the bits to work right, I'm happy. > >>> Introduction >>> >>> Please do NOT use random uppercase words in your text. There's NO >>> need: the readers are no more stupid than the average reader of an >>> RFC. >>> >>> Ditto 3.4, 3.6 >> Sorry- I didn't parse this. > Sorry I'm being sassy. > > I mean, please don't capitalise for emphasis. Just limit yourself to 21= 19 capitalisation. Got it. > >>> Introduction >>> >>> The key points are that the device itself is expected >>> to serve a limited purpose, >>> >>> I think you mean s/expected/intended/ >> How about "assumed"? > We're both being overly passive. Who has the expectation/intention/assu= mption. > > By "intended" I meant "intended by the manufacturer". > So, actually, any one of the three words is fine, if you can attribute = the verb to someone. Ok, I think we might have to disagree.=C2=A0 The use of passive in this c= ase is appropriate because the assumption is general and not attached to a single party.=C2=A0 Also, the following phrase =E2=80=93 and the rest of = the document =E2=80=93 make clear who is doing what. > >>> Introduction >>> >>> o A classifier that a device emits that can be used to locate a >>> description; >>> >>> Classifier or classification? >> Classifier. > Oh. > > A "classifier" is a person or thing that classifies. > I don't think the device emits a thing or a person :-) > I think it emits a piece of information that allows the device to be cl= assified. Means of classification? Eliot --THoqLSCOu4COKf0mml9UH2EslJFO3lqsx-- --HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZ+ttQAAoJEIe2a0bZ0nozDdMIAJV3mFDhMVhjRPWEroPyK9yx e0pWfTWboTow4jcOkNJrMl7wZ2avp86sbmA1qw8TAfR6dVm0TSfBvhi23c9ixc1y MQKRL4FG8I6QzvL/GG8r06hihDQmPsmi1pL4O3Z/tyAc2UlzSeFa9pWOUy7o/d0J +DixpL9Z0amg2hPXsqljrveA/9TyEQM1TaeZ1vtWL4mtlk43Fo61sQUlwhH/uFjS zWa/31hQTbtAfmN4BHGBZ3aTk8PgnoPU+ROf1RP3pWnbnmjWaf0KE+PI5V9WpixS bO2wi2f5xAeKkYo4ioJ4SMX6DMdsq6zKZMS1bMDWSqDgmwpc7MYNsgFtDVVnPkA= =Eq7T -----END PGP SIGNATURE----- --HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID-- From nobody Thu Nov 2 04:14:24 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BEA139982; Thu, 2 Nov 2017 04:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fWKHgBzrrZx; Thu, 2 Nov 2017 04:14:21 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E2713F4CB; Thu, 2 Nov 2017 04:14:19 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA2BEDR7012431; Thu, 2 Nov 2017 11:14:13 GMT Received: from 950129200 (254.196.113.87.dyn.plus.net [87.113.196.254]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id vA2BECCn012405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Nov 2017 11:14:13 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , Cc: , , References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> <022901d3536d$d01d7b10$70587130$@olddog.co.uk> <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> In-Reply-To: <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> Date: Thu, 2 Nov 2017 11:14:09 -0000 Message-ID: <02b901d353cb$b54a7aa0$1fdf6fe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHbXiOVWYUGr+virfAy7t490kIJlgFDRd+PAaRHM/gA4lCt+aLSgX2g X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23434.005 X-TM-AS-Result: No--19.810-10.0-31-10 X-imss-scan-details: No--19.810-10.0-31-10 X-TMASE-MatchedRID: Kx0w2sAofbsRqNE+xcwLcPHkpkyUphL9/NqdnmyTYHNcKZwALwMGswPa oyNK+Jv3xILoPou7rqmZ5rXmZbU9pX8RWuGQxsOi081phgl5F/lReWnUUdhI9a2PbheqHTJct/b KbgYFIpodfitjgIfGwGuQ7Ro4lHrcGBntNyPrRBurfZ+usyeESClayzmQ9QV0h868MqJkrtyTqM woXHwYFHF6xI97o6MHAhPLyEMdtHermmW6xY+ZmNh3b7/zBhN10Wobj8GkNVrKY//WmIj/ofi0j vfWRgUfPOeTGEP3OBanQTgw3dez4gjgWUfbdVp/z5rIW0RbS5h9SoM2kg9cUvYnOqnd+Q0TkGYM 14lC/DWhY1RK7RrSZ/H58jGrRTfoNA4kPXMXcBLYxkZC4pzxSEbxaqRa2zEnh8BhJvgqWBlY9QW glzfLgd9J2PHe9WriZ1cUcXza30wWFyz6902fByQIIQf/f8GJRvyVHewb0kKdwU/qXYxHvGeO90 L8tOZ6jF6wvhtRU7eILExmshQCk/l9KkqHi12rcFEiuPxHjsWLB4sTRpOnCes6rusujBXfdodzZ VKMVFxhYIpB42crUu9EJt2F5Oksv1l2Uvx6idpWdFebWIc3VsRB0bsfrpPI6T/LTDsmJmg= Archived-At: Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:14:23 -0000 Getting close. > >> With all that in mind, what I propose is the following: > >> =E2=80=A2 Add text that RECOMMENDs that devices make use of TEAP = when there > >> may be privacy concerns and when it is available; and > >> =E2=80=A2 In other cases where privacy may be a concern, we should = RECOMMEND > >> that a configuration option be provided, particularly when = devices are > >> designed to be mobile, which is where I think most of your = concerns > >> stem from. > > This is getting gooder. Thanks. > > Even when the MUD controller is on the premises (the not mobile = case), it > > contacts an offsite file server, and that act is visible. > > Suppose my Hi-Fi uses MUD - now you know that my house is worth = robbing. > > Suppose my intruder alarm uses MUD - now you know what security = system I > > have. >=20 > Here, I think you have some cause for hope, because on the whole, in = the > home, wireless encryption is generally used. It's not perfect but = would > address the point you make above. Yes. This addresses communications between device and router, and = between router and MUD controller. Of course, there are some issues with the use of wireless encryption in = the home (like security concerns) added to the fact that far fewer = people use wireless security than you might think given that you hang = out with technology-aware folk. But that's OK because (nominally) we = have a protection mechanism. But when the home-based MUD controller uses a URL to access a MUD = server, isn't that pretty visible and associated with the home (via the = IP address)? > > Of course, when the MUD controller is remote (the mobile case), it's = all even > > more worrying. >=20 > Yes, and to that end I propose to highlight a particular warning for > open networks (this would be one amongst many that developers should > heed with regard to open networks). OK. That works. > > I know you are trying to trade between perfect and getting something = that will > > be implemented and so make the world a somewhat better place. But = just recall > > that someone implemented those devices that "leak like sieves" and = those folk > > are unlikely to see a Recommendation as anything like a strong hint. >=20 > My hope is that this problem will abate over time, but I really cannot > say. My guess is that the same who are unlikely to heed such a > recommendation are also highly unlikely to implement MUD in the first = place. Yeah, you're right. I assume you have already written the paper titled "As Clear As MUD". > >>> There seems to be some overlap of terms and definitions in 1.5 and = 1.6. > >> Can you be more specific? > > 1.5 and 1.6 both have "manufacturer". > > 1.5 has "controller" and 1.6 has "MUD controller". > > The definitions don't match. >=20 > Ah- that is because they are being used in different contexts. One is > intended as a YANG node and the other really means those people who > build the thing. Yeah, got that. But isn't the YANG node supposed to encode the = information about the real things? Well, if everyone else thinks this is clear. > >>> Introduction > >>> > >>> The key points are that the device itself is expected > >>> to serve a limited purpose, > >>> > >>> I think you mean s/expected/intended/ > >> How about "assumed"? > > We're both being overly passive. Who has the > > expectation/intention/assumption. > > > > By "intended" I meant "intended by the manufacturer". > > So, actually, any one of the three words is fine, if you can = attribute the verb to > > someone. >=20 > Ok, I think we might have to disagree. The use of passive in this = case > is appropriate because the assumption is general and not attached to a > single party. Also, the following phrase =E2=80=93 and the rest of = the document > =E2=80=93 make clear who is doing what. Sigh. You'll not convince me that passive voice is ever a good thing in = a spec.=20 A general assumption is pretty risky. It's a second order assumption: = you're assuming that I assume. I'm reminded that the US has actually = written laws about "intended use" because those assumptions were not = necessarily shared. Maybe it's just writing style. Thanks, Adrian From nobody Thu Nov 2 08:01:59 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08EA13F66C; Thu, 2 Nov 2017 08:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0i3TjjMfdTk; Thu, 2 Nov 2017 08:01:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0D013FA9C; Thu, 2 Nov 2017 08:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2582; q=dns/txt; s=iport; t=1509634911; x=1510844511; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fv49HHpLt6JYCysPAP5w6KAgOv3qYU4OQfjMeUAbkII=; b=PEeC1xG2KM2td27HgzLm3XdGSnXDRXhtNPLD3wuDOVmNJNJacAiGVoNY laqeRwkhhzfV4Sh3XdGt0El9+nl2SnscVl8pN8PkOhSqQh2Rpohf4fMOE ASngvBh1t5XqnGvGGmPojAaRNUCysKdFAYndMQLXz3XlPWZtwZK5jpdFY g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADXMvtZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdJAjlkUQggEHA4U7AoUOGAEBAQEBAQEBAWsohR4BBSN?= =?us-ascii?q?WEAsYKgICVwcMCAEBih+ofYInixcBAQEBAQUBAQEBARQPgy6FbIMBhFUmgyuCY?= =?us-ascii?q?gWZBokHhEKCI44Xi3iHOpYWgTkfOIFsNCEIHRWDLoRfQI15AQEB?= X-IronPort-AV: E=Sophos;i="5.44,334,1505779200"; d="asc'?scan'208";a="15242" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 15:01:49 +0000 Received: from [10.61.88.6] (ams3-vpn-dhcp6151.cisco.com [10.61.88.6]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA2F1moe014382; Thu, 2 Nov 2017 15:01:48 GMT To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> <022901d3536d$d01d7b10$70587130$@olddog.co.uk> <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> <02b901d353cb$b54a7aa0$1fdf6fe0$@olddog.co.uk> From: Eliot Lear Message-ID: <73c3c46a-46ae-2d41-a6d0-b6c41a1365cf@cisco.com> Date: Thu, 2 Nov 2017 16:00:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <02b901d353cb$b54a7aa0$1fdf6fe0$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tcWWjFJUoFA47HjVTekARctxTi3lWogUD" Archived-At: Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:01:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tcWWjFJUoFA47HjVTekARctxTi3lWogUD Content-Type: multipart/mixed; boundary="TCuBHosPCSvTVcadH51NI9p2w4rwSEhph"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rtg-ads@ietf.org Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org Message-ID: <73c3c46a-46ae-2d41-a6d0-b6c41a1365cf@cisco.com> Subject: Re: RTG-DIR review of draft-ietf-opsawg-mud-13 References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk> <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com> <022901d3536d$d01d7b10$70587130$@olddog.co.uk> <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com> <02b901d353cb$b54a7aa0$1fdf6fe0$@olddog.co.uk> In-Reply-To: <02b901d353cb$b54a7aa0$1fdf6fe0$@olddog.co.uk> --TCuBHosPCSvTVcadH51NI9p2w4rwSEhph Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, Trimming now. On 11/2/17 12:14 PM, Adrian Farrel wrote: > But when the home-based MUD controller uses a URL to access a MUD > server, isn't that pretty visible and associated with the home (via > the IP address)? The communication occurs via TLS.=C2=A0 I just don't know how to do bette= r.=C2=A0 Also, I perceive two additional mitigations, one something of a happy accident: I expect that there will be providers that do MUD file management and so many of these URLs will all likely be served from the same places, and not necessarily give away what they are.=C2=A0 The secon= d is that much of this data will be served from commercial clouds for reliability purposes. Regarding passive tense let us take that as editorial and I will work with you to find a form that fits. AD and WG permitting of course. Eliot --TCuBHosPCSvTVcadH51NI9p2w4rwSEhph-- --tcWWjFJUoFA47HjVTekARctxTi3lWogUD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZ+zMpAAoJEIe2a0bZ0nozYa0IAK35jQM99G03HkoIY9znyVw3 8FTIZKLQYieVuHU5GbGIkWn093mJY5WzXc9GQtpIncoyHyx3vanLF+ccLo6b3rSt dUEAqYmfC1iiMHmp4gxMd/L5Zqm3+e1WbHelZ8IpoevEpyKTi2Ehae+10rYyY9Ad hNiecuVEza/dhuGfVz6hSaTJznx1V0XyszFOpXEQVtP5SfjFO3maRu1FHVgPobso Pb7yRia2AcbVvDlczck6aOrUGttSLn3t5kS5uNOZcORiM35pICw3WYbpaRckHGzl XET1C2QJ5PrTNke3L6beiuUZmJJtmmTSM/EIWX4OKOV3+tQdPFw6NGytqjxB9CQ= =utCP -----END PGP SIGNATURE----- --tcWWjFJUoFA47HjVTekARctxTi3lWogUD-- From nobody Fri Nov 3 10:31:07 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4313FF03; Fri, 3 Nov 2017 10:31:00 -0700 (PDT) X-Quarantine-ID: <9q7GYEHfeqAt> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q7GYEHfeqAt; Fri, 3 Nov 2017 10:30:56 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BBF13FF04; Fri, 3 Nov 2017 10:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37961; q=dns/txt; s=iport; t=1509730255; x=1510939855; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=ev2d13KHEjnQeempPcdOy+zzFfyYEP/6tej2PAcBFa4=; b=BI3cyRb7P5UIMtHMUz1EMbVg7BHrdhtn4AyQo+dYnxwBbuE8gHtC4B3E d66Er7HdTbn+jGpZ1DisQECm91Ci8EENUGXkuady/+GAisYIQb1PJahKr UJwmt+RJGPT8zJD41i94ELSqL+OJh9InZOL1K9zK5W06D9wkFcAT/9BHU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQC1pvxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkRCgRJuJ4N9ixOQI5ZFEIIBCiWFFgKFFxcBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQUaCU4IEAkQCiABAgcCAlcGAQwGAgEBF4oIEIkqnWeCJyaKagEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2DLoNagWkph1oFARECAYMzgmIFii6CHYUTkDCHZoMcS4k?= =?us-ascii?q?vghVfiQSHPIotgjSBSIdtgTkhATWBA2k0IQgdFUmCZAmCUxwZgU9ANgGNMQEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.44,339,1505779200"; d="scan'208,217";a="52522" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 17:30:52 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA3HUp8I020644; Fri, 3 Nov 2017 17:30:51 GMT From: Benoit Claise To: Lou Berger , NetMod WG Cc: rtg-dir@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org References: <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com> Message-ID: Date: Fri, 3 Nov 2017 18:30:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8089E1673C08B81B6A9250AA" Content-Language: en-US Archived-At: Subject: [RTG-DIR] draft-clacla-netmod-yang-model-update-00.txt : Re: handling module incompatibility => handling module transition X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:31:00 -0000 This is a multi-part message in MIME format. --------------8089E1673C08B81B6A9250AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Let me present this draft https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/ New YANG Module Update Procedure draft-clacla-netmod-yang-model-update-01 Abstract This document specifies a new YANG module update procedure in case of non backward-compatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950. Problem statement: Changing a YANG module name each time there is a non backward compatible change (as RFC7950 requires) adds a lot of complexity to automation, from an import and service composition point of view. Solution: We need a different mechanism. The solution in the draft is based on the semantic versioning YANG extension: it was proposed openconfig in the past and is currently used by the openconfig YANG modules Note: there might other solutions, such as new YANG keywords, but at this point in time, it's important to recognize that we need to change the way we produce YANG modules at the IETF. Let's discuss on the list and during the NETMOD meeting. Regards, Benoit. > On 10/12/2017 3:30 PM, Benoit Claise wrote: >> Hi Lou, >>> >>> So circling back to the original question: what do we do about the >>> non backward-compatible module being defined in rfc8049bis? >>> >>> While being sympathetic to many of the comments made below as well >>> as the "do over" concept, I find the comments about adhering to the >>> rules of 7950 compelling - which leads to renaming the module in the >>> bis to ietf-l3vpn-svc-2. >>> >>> It would be good to ensure that this is the consensus of the group >>> before asking the authors make this change. >>> >> Since this draft is AD sponsored, I'll evaluate the consensus on >> RFC8049bis. >> Moving to ietf-l3vpn-svc-2 is the easy path not to break backward >> compatibility. However, since ietf-l3vpn-svc is unimplementable (it >> has broken XPATH expressions, so a compliant implementation is >> impossible), so technically, ietf-l3vpn-svc does not even exist. > See my message on this topic, as the IETF LC follow up. > https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html > If a follow up is required, I propose that we use a single public > email thread: the ietf@ietf.org > > Regards, Benoit >> >> What NETMOD should focus on is closing on the NMDA transition: the >> ietf-routing versus ietf-routing-2 issue. >> Way bigger impact in terms of dependent YANG modules >> >> Regards, Benoit (as OPS AD) >> See below. >>> >>> This change course doesn't solve the versioning issue discussed >>> below, but this is not a new issue it's just the first time we'll >>> actually executing the steps envisioned as part of the rules laid >>> out in yang. My personal take away is that means that we should >>> immediately start work on an extension defining along the lines of  >>> ' *_obsolete|update_*' mentioned below. >>> >> I believe that option 1 is the more pragmatic and complete solution. >> option 2 is just half a step in the right direction. >> I believe we should discuss this topic in Singapore. >> >> Regards, Benoit (as individual contributor) >>> >>> Lou >>> >>> On October 8, 2017 10:59:15 AM Benoit Claise wrote: >>> >>>> Dear all, >>>> >>>> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 >>>> is broken. The small problem is: trying to maintain backward >>>> compatibility. >>>> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem. >>>> >>>> Let me extend the scope of this email thread from "handling module >>>> incompatibility" to "handling module incompatibility and NMDA >>>> transition". >>>> As I mentioned in the past (see "semver.org comparison of two YANG >>>> modules" email in NETMOD), I believe the IETF will have to change >>>> its way of working in terms of backward compatibility. See also the >>>> email "ietf-routing or ietf-routing-2? module naming convention for >>>> NMDA transition. Re: [netmod] upcoming adoptions" in NETMOD. >>>> >>>> However, we will have to tackle this discussion one day or the other: >>>> - we need _an automatic way_ to make the link between the YANG >>>> module in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, >>>> or any non backward compatible YANG modules. >>>> - we need _an automatic way_ to make the link between the YANG >>>> module in RFC8022 and the YANG module in >>>> draft-acee-netmod-rfc8022bis, or any new YANG module names used for >>>> NMDA transition. >>>> Note: actually, we face two different problems. >>>> draft-wu-l3sm-rfc8049bis might be declared backward incompatible >>>> with RFC8049, while RFC8022bis is backward compatible with RFC8022. >>>> The RFC8022bis went for a new YANG module name ietf-routing-2 to >>>> avoid to document the -state tree (as deprecated), based on the >>>> argument that ietf-routing is not yet implemented. >>>> >>>> Which solutions do we have from here? >>>> #1. We keep the same module name and express that the YANG module >>>> in draft-wu-l3sm-rfc8049bis is not backward compatible with the >>>> RFC8049 one. This is the openconfig way. See >>>> draft-clacla-netmod-model-catalog (and >>>> draft-openconfig-netmod-model-catalog before) >>>> >>>> // extension statements >>>> extension openconfig-version { >>>> argument "semver" { >>>> yin-element false; >>>> } >>>> description >>>> "The OpenConfig version number for the module. This is >>>> expressed as a semantic version number of the form: >>>> x.y.z >>>> where: >>>> * x corresponds to the major version, >>>> * y corresponds to a minor version, >>>> * z corresponds to a patch version. >>>> This version corresponds to the model file within which it is >>>> defined, and does not cover the whole set of OpenConfig models. >>>> Where several modules are used to build up a single block of >>>> functionality, the same module version is specified across each >>>> file that makes up the module. >>>> >>>> A major version number of 0 indicates that this model is still >>>> in development (whether within OpenConfig or with industry >>>> partners), and is potentially subject to change. >>>> >>>> Following a release of major version 1, all modules will >>>> increment major revision number where backwards incompatible >>>> changes to the model are made. >>>> >>>> The minor version is changed when features are added to the >>>> model that do not impact current clients use of the model. >>>> >>>> The patch-level version is incremented when non-feature changes >>>> (such as bugfixes or clarifications to human-readable >>>> descriptions that do not impact model functionality) are made >>>> that maintain backwards compatibility. >>>> >>>> The version number is stored in the module meta-data."; >>>> } >>>> >>>> Similarly, we always keep the same YANG module name in case of NMDA >>>> transition. So ietf-routing-2 should be changed back to ietf-routing. >>>> The email thread "[Rtg-dt-yang-arch] ietf-routing or >>>> ietf-routing-2? module naming convention for NMDA transition. Re: >>>> [netmod] upcoming adoptions" seems to go in that direction. >>>> >>>> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 >>>> or ietf-routing-2 but then, how do we make the link with the >>>> previous module? >>>> Then ...  What? We create extension that will link the >>>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? >>>> Same principle as #1, but just more complex. >>>> Or we have a new YANG keyword (this implies YANG 2.0) >>>> >>>> file"ietf-l3vpn-svc@2017-09-14.yang" >>>> module ietf-l3vpn-svc-2 { >>>> yang-version 1.1; >>>> namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; >>>> prefix l3vpn-svc; >>>> *_obsolete|update _*ietf-l3vpn-svc@2017-01-2 >>>> >>>> And whose responsibility is this to warn/push all authors of >>>> ietf-routing YANG modules to move to ietf-routing-2? (*) >>>> >>>> The following are non solution IMO: >>>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the >>>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" >>>> flag in order to understand that the RFC8049 YANG module is >>>> obsolete is not an automatic solution. >>>> - Using the yangcatalog.org might be a solution as we track the >>>> derived semantic, but this is just an offline trick. This is not >>>> what I call "automatic way" >>>> - Using the YANG module description field might be interesting, but >>>> again this is not an "automatic way": >>>> >>>> description >>>> "This YANG module defines a generic service configuration >>>> model for Layer 3 VPNs. This model is common across all >>>> vendor implementations. This obsoletes the RFC8049 YANG >>>> module, ietf-l3vpn-svc@2017-01-2"; >>>> revision 2017-09-14 { >>>> description >>>> >>>> "First revision ofRFC8049 ."; >>>> reference >>>> "RFC xxxx: YANG Data Model for L3VPN Service Delivery"; >>>> >>>> >>>> In conclusion, I believe openconfig got this right and that >>>> solution #1 is the solution to go ... while waiting for a new YANG >>>> keyword in YANG 2.0 >>>> >>>> (*) If you want to change the module from ietf-routing to >>>> ietf-routing-2, then you should follow with all authors of >>>> dependent modules to make sure they transition to ietf-routing-2 >>>> In the yangcatalog.org, because I needed the information as OPS AD, >>>> we created a small script to get that authors list for IETF drafts. >>>> For the ietf-routing, this produces the following >>>> { >>>>     "output": { >>>>         "author-email": [ >>>> "draft-ietf-mpls-static-yang@ietf.org", >>>> "draft-ietf-mpls-base-yang@ietf.org", >>>> "draft-ietf-ospf-sr-yang@ietf.org", >>>> "draft-ietf-pim-yang@ietf.org", >>>> "draft-ietf-bier-bier-yang@ietf.org", >>>> "draft-zhang-bier-te-yang@ietf.org", >>>> "draft-ietf-isis-yang-isis-cfg@ietf.org", >>>> "draft-ietf-teas-yang-rsvp-te@ietf.org", >>>> "draft-ietf-mpls-mldp-yang@ietf.org", >>>> "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org", >>>> "draft-ietf-isis-sr-yang@ietf.org", >>>> "draft-acee-rtgwg-yang-rib-extend@ietf.org", >>>> "draft-ietf-pim-igmp-mld-yang@ietf.org", >>>> "draft-ietf-i2rs-fb-rib-data-model@ietf.org", >>>> "draft-ietf-ospf-yang@ietf.org", >>>> "draft-ietf-rtgwg-yang-rip@ietf.org", >>>> "draft-ietf-spring-sr-yang@ietf.org", >>>> "draft-ietf-teas-yang-rsvp@ietf.org", >>>> "draft-ietf-i2rs-pkt-eca-data-model@ietf.org", >>>> "draft-ietf-mpls-ldp-yang@ietf.org", >>>> "draft-ietf-bfd-yang@ietf.org", >>>> "draft-ietf-pim-msdp-yang@ietf.org" >>>>         ] >>>>     } >>>> } >>>> >>>> Fortunately, we only deal with IETF dependent YANG modules in case >>>> of the ietf-routing. That's an easier case. >>>> If we would change ietf-interfaces to ietf-interfaces-2, we would >>>> have an cross SDO issue ... Btw, there are no automatic ways to >>>> extract the authors of YANG modules from different SDOs: it's only >>>> a metadata that that the different SDOs should insert in the >>>> yangcatalog. So we would have to rely on liaisons or direct emails, >>>> assuming we know the authors. Time consuming, believe me. >>>> >>>> Regards, Benoit >>>>> Hi, >>>>> >>>>>     As part of the my Routing Directorate review of >>>>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible >>>>> changes being made to the ietf-l3vpn-svc module without changing the >>>>> name.  I raised this with the YANG doctors and others involved with the >>>>> draft and it surfaced some topics which really should be discussed here >>>>> in NetMod. >>>>> >>>>> The background (as explained off-list by others, so I hope I have it >>>>> right)  is that one of the YANG Doctors noted that RFC8049 was broken >>>>> and could not be implemented as defined, and therefore a fix was >>>>> needed.  L3SM has concluded so the fix is in the individual draft >>>>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc >>>>> module could not be implemented, the feeling by the YANG Dr was that >>>>> even though the new module is incompatible with the original definition >>>>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of >>>>> RFC 6020) didn't have to be followed and the same name could be used. >>>>> >>>>> In the subsequent discussion with the YANG Drs., the general discussion >>>>> was heading down the path of using a new module name, and thereby not >>>>> violating YANG module update rules.  This lead us back to the a similar >>>>> discussion we've been having in the context of 8022bis: how best to >>>>> indicate that a whole module is being obsoleted.  RFCs do this by adding >>>>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't >>>>> help YANG tooling.  For 8022, we have one approach - publishing an >>>>> updated rev of the original module marking all nodes as deprecated - but >>>>> that doesn't really make sense for rfc8049bis. >>>>> >>>>> So the discussion for the WG is: >>>>> >>>>> How do we handle incompatible module changes, notably when one module >>>>> 'obsoletes' another module --  from both the process and tooling >>>>> perspectives? >>>>> >>>>> I know Benoit plans to bring in some thoughts/proposals, perhaps there >>>>> are others. >>>>> >>>>> Cheers, >>>>> >>>>> Lou >>>>> >>>>> (as contributor/reviewer) >>>>> >>>>> >>>>> >>>>> >> > --------------8089E1673C08B81B6A9250AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

Let me present this draft https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
                    New YANG Module Update Procedure
                draft-clacla-netmod-yang-model-update-01

Abstract

   This document specifies a new YANG module update procedure in case of
   non backward-compatible changes, as an alternative proposal to the
   YANG 1.1 specifications.  This document updates RFC 7950.

Problem statement:
Changing a YANG module name each time there is a non backward compatible change (as RFC7950 requires) adds a lot of complexity to automation, from an import and service composition point of view.

Solution:
We need a different mechanism. The solution in the draft is based on the semantic versioning YANG extension: it was proposed openconfig in the past and is currently used by the openconfig YANG modules

Note: there might other solutions, such as new YANG keywords, but at this point in time, it's important to recognize that we need to change the way we produce YANG modules at the IETF. Let's discuss on the list and during the NETMOD meeting.

Regards, Benoit.
On 10/12/2017 3:30 PM, Benoit Claise wrote:
Hi Lou,

So circling back to the original question: what do we do about the non backward-compatible module being defined in rfc8049bis?

While being sympathetic to many of the comments made below as well as the "do over" concept, I find the comments about adhering to the rules of 7950 compelling - which leads to renaming the module in the bis to ietf-l3vpn-svc-2.

It would be good to ensure that this is the consensus of the group before asking the authors make this change.

Since this draft is AD sponsored, I'll evaluate the consensus on RFC8049bis.
Moving to ietf-l3vpn-svc-2 is the easy path not to break backward compatibility. However, since ietf-l3vpn-svc is unimplementable (it has broken XPATH expressions, so a compliant implementation is impossible), so technically, ietf-l3vpn-svc does not even exist.
See my message on this topic, as the IETF LC follow up.
    https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
If a follow up is required, I propose that we use a single public email thread: the ietf@ietf.org

Regards, Benoit

What NETMOD should focus on is closing on the NMDA transition: the ietf-routing versus ietf-routing-2 issue.
Way bigger impact in terms of dependent YANG modules

Regards, Benoit (as OPS AD)
See below.

This change course doesn't solve the versioning issue discussed below, but this is not a new issue it's just the first time we'll actually executing the steps envisioned as part of the rules laid out in yang. My personal take away is that means that we should immediately start work on an extension defining along the lines of  ' obsolete|update' mentioned below.

I believe that option 1 is the more pragmatic and complete solution. option 2 is just half a step in the right direction.
I believe we should discuss this topic in Singapore.

Regards, Benoit (as individual contributor)

Lou

On October 8, 2017 10:59:15 AM Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is broken. The small problem is: trying to maintain backward compatibility.
draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.

Let me extend the scope of this email thread from "handling module incompatibility" to "handling module incompatibility and NMDA transition".
As I mentioned in the past (see "semver.org comparison of two YANG modules" email in NETMOD), I believe the IETF will have to change its way of working in terms of backward compatibility. See also the email "ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: [netmod] upcoming adoptions" in NETMOD.

However, we will have to tackle this discussion one day or the other:
- we need an automatic way to make the link between the YANG module in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, or any non backward compatible YANG modules.
- we need an automatic way to make the link between the YANG module in RFC8022 and the YANG module in draft-acee-netmod-rfc8022bis, or any new YANG module names used for NMDA transition.
Note: actually, we face two different problems. draft-wu-l3sm-rfc8049bis might be declared backward incompatible with RFC8049, while RFC8022bis is backward compatible with RFC8022. The RFC8022bis went for a new YANG module name ietf-routing-2 to avoid to document the -state tree (as deprecated), based on the argument that ietf-routing is not yet implemented.

Which solutions do we have from here?
#1. We keep the same module name and express that the YANG module in draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 one. This is the openconfig way. See draft-clacla-netmod-model-catalog (and draft-openconfig-netmod-model-catalog before)
 
  // extension statements
     extension openconfig-version {
       argument "semver" {
         yin-element false;
       }
       description
         "The OpenConfig version number for the module. This is
         expressed as a semantic version number of the form:
           x.y.z
          where:
           * x corresponds to the major version,
           * y corresponds to a minor version,
           * z corresponds to a patch version.
         This version corresponds to the model file within which it is
         defined, and does not cover the whole set of OpenConfig models.
         Where several modules are used to build up a single block of
         functionality, the same module version is specified across each
         file that makes up the module.

         A major version number of 0 indicates that this model is still
         in development (whether within OpenConfig or with industry
         partners), and is potentially subject to change.

         Following a release of major version 1, all modules will
         increment major revision number where backwards incompatible
         changes to the model are made.

         The minor version is changed when features are added to the
         model that do not impact current clients use of the model.

         The patch-level version is incremented when non-feature changes
         (such as bugfixes or clarifications to human-readable
         descriptions that do not impact model functionality) are made
         that maintain backwards compatibility.

         The version number is stored in the module meta-data.";
     }
Similarly, we always keep the same YANG module name in case of NMDA transition. So ietf-routing-2 should be changed back to ietf-routing.
The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: [netmod] upcoming adoptions" seems to go in that direction.

#2. Or we have a different module name, let's say ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do we make the link with the previous module?
Then ...  What? We create extension that will link the draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? Same principle as #1, but just more complex.
Or we have a new YANG keyword (this implies YANG 2.0)
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
 prefix l3vpn-svc;
 obsolete|update ietf-l3vpn-svc@2017-01-2
And whose responsibility is this to warn/push all authors of ietf-routing YANG modules to move to ietf-routing-2? (*)

The following are non solution IMO:
- Going from the draft-wu-l3sm-rfc8049bis YANG module to the draft-wu-l3sm-rfc8049bis document to lookup the IETF "obsolete" flag in order to understand that the RFC8049 YANG module is obsolete is not an automatic solution.
- Using the yangcatalog.org might be a solution as we track the derived semantic, but this is just an offline trick. This is not what I call "automatic way"
- Using the YANG module description field might be interesting, but again this is not an "automatic way":
 description
  "This YANG module defines a generic service configuration
   model for Layer 3 VPNs. This model is common across all
   vendor implementations. This obsoletes the RFC8049 YANG 
   module, ietf-l3vpn-svc@2017-01-2";
 revision 2017-09-14 {
  description
  
"First revision of RFC8049.";
  reference
   "RFC xxxx: YANG Data Model for L3VPN Service Delivery";

In conclusion, I believe openconfig got this right and that solution #1 is the solution to go ... while waiting for a new YANG keyword in YANG 2.0

(*) If you want to change the module from ietf-routing to ietf-routing-2, then you should follow with all authors of dependent modules to make sure they transition to ietf-routing-2
In the yangcatalog.org, because I needed the information as OPS AD, we created a small script to get that authors list for IETF drafts. For the ietf-routing, this produces the following
{
    "output": {
        "author-email": [
            "draft-ietf-mpls-static-yang@ietf.org",
            "draft-ietf-mpls-base-yang@ietf.org",
            "draft-ietf-ospf-sr-yang@ietf.org",
            "draft-ietf-pim-yang@ietf.org",
            "draft-ietf-bier-bier-yang@ietf.org",
            "draft-zhang-bier-te-yang@ietf.org",
            "draft-ietf-isis-yang-isis-cfg@ietf.org",
            "draft-ietf-teas-yang-rsvp-te@ietf.org",
            "draft-ietf-mpls-mldp-yang@ietf.org",
            "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
            "draft-ietf-isis-sr-yang@ietf.org",
            "draft-acee-rtgwg-yang-rib-extend@ietf.org",
            "draft-ietf-pim-igmp-mld-yang@ietf.org",
            "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
            "draft-ietf-ospf-yang@ietf.org",
            "draft-ietf-rtgwg-yang-rip@ietf.org",
            "draft-ietf-spring-sr-yang@ietf.org",
            "draft-ietf-teas-yang-rsvp@ietf.org",
            "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
            "draft-ietf-mpls-ldp-yang@ietf.org",
            "draft-ietf-bfd-yang@ietf.org",
            "draft-ietf-pim-msdp-yang@ietf.org"
        ]
    }
}

Fortunately, we only deal with IETF dependent YANG modules in case of the ietf-routing. That's an easier case.
If we would change ietf-interfaces to ietf-interfaces-2, we would have an cross SDO issue ... Btw, there are no automatic ways to extract the authors of YANG modules from different SDOs: it's only a metadata that that the different SDOs should insert in the yangcatalog. So we would have to rely on liaisons or direct emails, assuming we know the authors. Time consuming, believe me.

Regards, Benoit
Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)



--------------8089E1673C08B81B6A9250AA-- From nobody Sat Nov 4 14:20:05 2017 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395913FB6C; Sat, 4 Nov 2017 14:19:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.64.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150983039829.26601.3109842491855567125@ietfa.amsl.com> Date: Sat, 04 Nov 2017 14:19:58 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 21:19:58 -0000 Reviewer: Joel Halpern Review result: Not Ready This is a routing directorate early review. It is intended to assist the working group and the routing ADs in processing the advancing document. This document is nearly ready for publication as a Proposed Standard RFC. Isses: Major: N/A Moderate: Please address the issues reported by id-nits. Specifically, repair the abstract and add an explicit reference to RFC 2119 Please add an informative reference to draft-ietf-rtgwg-dst-src-routing indicating the the routing policy described here aligns with the ongoing work in the routing area for how to handle source specific routes. This could be added in section 4. The base Babel (bis) specification does not talk about the handling of duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given destination prefix advertisement? Please indicate what the intended / permitted handling is in the text. Minor: As far as I can tell, the behavior described in section 3.1 for 0/0 source addresses and their relationship to routes without source addresses is correct and matches draft-ietf-rtgwg-dst-src-routing. However, the wording is sufficiently different as to cause this reader to wonder about it. If practical consider additional wording to make the alignment clear. This would seem to apply to 3.2 as well. The most obvious fix is to say that a Babel node supporting this extensions treats all advertisements received without a source specific prefix as if they had the 0/0 source prefix? (The text in section 5.2 says this. I would like to see it in section 3.1) From nobody Wed Nov 8 07:04:55 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058D41275C5; Wed, 8 Nov 2017 07:04:48 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 x8AldrNx0MXt; Wed, 8 Nov 2017 07:04:46 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B3AAC126557; Wed, 8 Nov 2017 07:04:45 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA8F4hbG006905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Nov 2017 16:04:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA8F4hPD022175; Wed, 8 Nov 2017 16:04:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 49FCEEB259; Wed, 8 Nov 2017 16:04:43 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id w5A8geeJmKDr; Wed, 8 Nov 2017 16:04:37 +0100 (CET) Received: from mac-matthieu.lan (AAubervilliers-652-1-188-235.w86-218.abo.wanadoo.fr [86.218.75.235]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EDAD0EB216; Wed, 8 Nov 2017 16:04:36 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthieu Boutier In-Reply-To: <150983039829.26601.3109842491855567125@ietfa.amsl.com> Date: Wed, 8 Nov 2017 16:04:35 +0100 Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.4.7) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 08 Nov 2017 16:04:43 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Nov 2017 16:04:43 +0100 (CET) X-Miltered: at korolev with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A031D0B.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5A031D0B.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5A031D0B.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5A031D0B.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 15:04:48 -0000 Hi, Thank's a lot for this early review. > Please address the issues reported by id-nits. Please accept my apologizes about these nits. > The base Babel (bis) specification does not talk about the handling of > duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on = a given > destination prefix advertisement? I believe it is clear that a Babel node MUST NOT send two Source Prefix = sub-TLVs in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I = hesitate: does a node SHOULD or MUST ignore the whole TLV? Does the list have an opinion? Matthieu From nobody Wed Nov 8 16:19:28 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956B129421; Wed, 8 Nov 2017 16:19:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 1eNTIK_UvKjz; Wed, 8 Nov 2017 16:19:21 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 5686012778E; Wed, 8 Nov 2017 16:19:21 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1510186752; bh=y0xkGrNDrHtWAGuQnmpUWCWdoRm+uU24ZTLx12Gy1oI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MPAcVpVw45qf2BYcXx6LyBLQvbM7YguXAeZf9dYoxgL7ejk2Qiu5pii8fD0ahefZo Syzw4HcFZGmOVbLVIRTdaWoClnBvF07PHkhTOna9045yGOAKxXeDM+syKOeJA519ww wMYwpjMBYJSM+YCV4xb6GwegVPjlwnqOQwZWfZCcGrUwO7WVhmESeyPXYliA8DUYnH gAtwOShJiRxVE7fuJv88KNL4nHJmvO611AgDFfGY+7SojPU2UctG8eCNE3Kdc5ZDCB 5aLOO//5Ld+4+FRlgK3ceh1tpyDXVQNfdeFympgRZ3NIfy6IdeNkiwyT+wNN7buv7x b0myW+xkRekww== To: Matthieu Boutier , Joel Halpern Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org In-Reply-To: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> Date: Thu, 09 Nov 2017 09:18:55 +0900 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87po8sqp74.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 00:19:22 -0000 Matthieu Boutier writes: > Hi, > > Thank's a lot for this early review. > >> Please address the issues reported by id-nits. > > Please accept my apologizes about these nits. > >> The base Babel (bis) specification does not talk about the handling of >> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given >> destination prefix advertisement? > > I believe it is clear that a Babel node MUST NOT send two Source Prefix sub-TLVs > in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I hesitate: > does a node SHOULD or MUST ignore the whole TLV? > > Does the list have an opinion? Off the top of my head: Ignore the whole thing; better to fail (preferably loudly) than carry on with ambiguous semantics. -Toke From nobody Wed Nov 8 16:44:53 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67C129478 for ; Wed, 8 Nov 2017 16:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 F3IkVAHNvA9U for ; Wed, 8 Nov 2017 16:44:49 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 9B59912941D for ; Wed, 8 Nov 2017 16:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510188289; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding: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=uoHAtRgbWJpUOlYhbuEM5j8vmvFFzCvqYFzjmPssmwI=; b=KwHvz1KScC31EpXBs4qsXPNTpJd2vRSVuYICQ1I0SkW1MMugXviq4ZODPzAXG2WH yY4MO5gMjbKV77CwwDgh9V/ST56wc3GPoGMGMbkJwEWhr5Ntfz737eIiZ9r11APL cD2vLjR6XoGwIUVwbti269esjlVeTrt0qpB7w0mdZuuvHBPYTi7WKSEKv1Sue8Dl Fe5U9ftWBh3lopkKAlahHtoM5MACPIyPDapdRs3JE2w0UMGSpeO7CANW9GsUuwXP 7We+9ve4eWJ5iM43uv4ZFgpVMVXBDWsamFVtbZdY2FjsaHRshMxt2zruu0lsofyJ v6Ymrnyr2SAcuZ9AbUi4ig==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id CC.80.16042.105A30A5; Wed, 8 Nov 2017 16:44:49 -0800 (PST) X-AuditID: 11973e12-355ff70000003eaa-85-5a03a501192d Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id C5.FC.23978.105A30A5; Wed, 8 Nov 2017 16:44:49 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)" Received: from [17.226.23.83] (unknown [17.226.23.83]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ4004A9KQONI30@jimbu.apple.com>; Wed, 08 Nov 2017 16:44:48 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> Date: Wed, 08 Nov 2017 16:44:48 -0800 In-reply-to: <87po8sqp74.fsf@toke.dk> Cc: Matthieu Boutier , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUi2FAYrMu4lDnK4PMKUYsti7pZLA5/aWSx eLbzJavFx1NvmCwWrHnKbrH1/Qp2BzaPJUt+Mnks3vKW0ePclO+MHlsOXWQLYInisklJzcks Sy3St0vgytj1ZQp7wYHYikvf5jE1MD4M7GLk5JAQMJE4t/I8WxcjF4eQwGomiUt/pjLBJBp6 DzBBJDYwSkx4vY4dJMErICjxY/I9FhCbWSBM4sfVq2C2kMBfRokZjeUgtrCAtETXhbusXYwc HGwCWhIH1hhBtNpIzD36kh2ixF/iwcupYK0sAqoS616eYwOxOYHsxVumMILsZRaYyyhxc/5q sAYRAXuJxq8XWCAO6mWUaPu9lQXiUkWJIzPnMIMkJAROsEm0HZzAPIFRaBaSY2chOXYW0FHM AuoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwTvcSCgpxUveT83E2MoEia bie0g/HUKqtDjAIcjEo8vBqKTFFCrIllxZW5hxilOViUxHlTXzFECQmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamD0DnZIWh4l+2zOJr3Pr3xu6Phbuc283D3Fduujx0f+/gx9pfou18ghWbir wX3CjCwV5XfJe6Mcn2t0hE7k6pz/yNuqM//ScTflliCx1spZFU9D/+TXNaVpH3lj9jRUtXDn 17f2lecLp7+ukP35RTr6Bdsr1akRhxjSlJ7v4p+VWPS4KIGJf64SS3FGoqEWc1FxIgBZXjj6 hQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUiON1OVZdxKXOUwY5lghZbFnWzWBz+0shi 8WznS1aLj6feMFksWPOU3WLr+xXsDmweS5b8ZPJYvOUto8e5Kd8ZPbYcusgWwBLFZZOSmpNZ llqkb5fAlbHryxT2ggOxFZe+zWNqYHwY2MXIySEhYCLR0HuAqYuRi0NIYAOjxITX69hBErwC ghI/Jt9jAbGZBcIkfly9CmYLCfxllJjRWA5iCwtIS3RduMvaxcjBwSagJXFgjRFEq43E3KMv 2SFK/CUevJwK1soioCqx7uU5NhCbE8hevGUKI8heZoG5jBI3568GaxARsJdo/HqBBeKgXkaJ tt9bWSAuVZQ4MnMO8wRG/llI7puF5L5ZQHcwC6hLTJmSCxHWlnjy7gIrhK0msfD3IiZk8QWM bKsYBYpScxIrjfUSCwpyUvWS83M3MYICv6EweAfjn2VWhxgFOBiVeHgvyDFFCbEmlhVX5h5i lOBgVhLhtc5kjhLiTUmsrEotyo8vKs1JLT7EKM3BoiTO25HBECUkkJ5YkpqdmlqQWgSTZeLg lGpg3BbLtqu28qty6YQche5I4/Pbp+ydPe9Kx/O6+SdOTNq1PWpynpBK8oE1Oa0ueY/D4+cZ nzh1dwkvw+YZnNIiCxiMVdsqG3+eXXffW3xJ8UK116dmmG+dVJ3CXSv4UGiWwe8Ll/9NbjbP 1BfK1zaY8i57X0G2u+hqrbIoxh8XZSZ+LD275rXlNiWW4oxEQy3mouJEAOE6OYh4AgAA Archived-At: Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 00:44:51 -0000 --Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable $.02 Personally, if I receive something that the spec says you MUST NOT do I = get upset at the packet. Maybe I ignore the whole TLV, maybe the whole packet, maybe I summon the = wrath of the Gods of the Internet. If you expect that someone someday could find a use case for sending two = sub-TLVs, then I'd recommend explicitly saying MUST NOT send and on receive MUST = drop TLV but not packet. If you don't expect this to ever be useful, no need to specify it. David > On Nov 8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Matthieu Boutier > writes: >=20 >> Hi, >>=20 >> Thank's a lot for this early review. >>=20 >>> Please address the issues reported by id-nits. >>=20 >> Please accept my apologizes about these nits. >>=20 >>> The base Babel (bis) specification does not talk about the handling = of >>> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed = on a given >>> destination prefix advertisement? >>=20 >> I believe it is clear that a Babel node MUST NOT send two Source = Prefix sub-TLVs >> in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I = hesitate: >> does a node SHOULD or MUST ignore the whole TLV? >>=20 >> Does the list have an opinion? >=20 > Off the top of my head: Ignore the whole thing; better to fail > (preferably loudly) than carry on with ambiguous semantics. >=20 > -Toke >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel = --Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable $.02

Personally, if I receive something that the spec says you = MUST NOT do I get upset at the packet.
Maybe I ignore the = whole TLV, maybe the whole packet, maybe I summon the wrath of the Gods = of the Internet.
If you expect that = someone someday could find a use case for sending two = sub-TLVs,
then I'd recommend explicitly saying MUST = NOT send and on receive MUST drop TLV but not packet.
If you don't expect this to ever be useful, no need to = specify it.

David


On Nov = 8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> = wrote:

Matthieu Boutier <boutier@irif.fr> writes:
Hi,

Thank's a lot for this early review.

Please address the = issues reported by id-nits.

Please accept my apologizes about these nits.
The base Babel (bis) = specification does not talk about the handling of
duplicate = sub-TLVs.  Are multiple source-specific sub-TLVs allowed on a = given
destination prefix advertisement?

I believe it is clear that a = Babel node MUST NOT send two Source Prefix sub-TLVs
in one = TLV.  But If a received TLV has two Source Prefix sub-TLVs, I = hesitate:
does a node SHOULD or MUST ignore the whole = TLV?

Does the list have an opinion?

Off the top of my head: Ignore the whole = thing; better to fail
(preferably loudly) than carry = on with ambiguous semantics.

-Toke

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

= --Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)-- From nobody Thu Nov 9 05:48:37 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC51200F1; Thu, 9 Nov 2017 05:48:30 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YwyRYDTaArvB; Thu, 9 Nov 2017 05:48:29 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 CF963120046; Thu, 9 Nov 2017 05:48:28 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA9DmLvU020057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Nov 2017 14:48:23 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA9DmKiF008352; Thu, 9 Nov 2017 14:48:20 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A56C3EB21F; Thu, 9 Nov 2017 14:48:20 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9EcWhBS8LX1H; Thu, 9 Nov 2017 14:48:19 +0100 (CET) Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7DDA6EB364; Thu, 9 Nov 2017 14:48:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthieu Boutier In-Reply-To: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> Date: Thu, 9 Nov 2017 14:48:18 +0100 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr> References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.4.7) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 09 Nov 2017 14:48:23 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 09 Nov 2017 14:48:21 +0100 (CET) X-Miltered: at korolev with ID 5A045CA5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5A045CA4.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A045CA5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5A045CA4.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5A045CA5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5A045CA4.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 13:48:31 -0000 > maybe I summon the wrath of the Gods of the Internet. Hey! What's the protocol for that? :p > If you don't expect this to ever be useful, no need to specify it. Looks good for me, does something like the following make sense? Should = we recommend something? A node does not expect to receive any TLV with two Source Prefix = sub-TLVs or more. Whenever that occurs, the behaviour is undefined: an = implementation may drop the whole packet, the whole TLV or consider only just one = of the sub-TLVs (this can be the case if the implementation does not check = if multiple sub-TLVs are sent). Toke, would you like to see: "It is recommended to ignore the whole = packet". (lower case "recommended") Matthieu From nobody Thu Nov 9 05:54:18 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7F120046; Thu, 9 Nov 2017 05:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv-lpA_KlNcu; Thu, 9 Nov 2017 05:54:14 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A489126BFD; Thu, 9 Nov 2017 05:54:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7CA74245B71; Thu, 9 Nov 2017 05:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510235654; bh=vbukJqV+FOdoPoMCeqXBzhvbwi8aQNWnJWNRJTLAd6g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TCwlAO4sFHGRP2F/wocXyPZF4gf7dr7Cn93UV1fSfgK7xzvdMi6mnoqxPfCrnUJog Ke4LH9ZnSQ6KDobYJU6UlFNUO0YnKNJmQKIMNhZbWFf4sTtgSWzC3NJWzkkeS/Zu2O R59yULyXqm9qiX+RJQmgva6hsjB56ETRhCmW/b2w= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E0C56240E4E; Thu, 9 Nov 2017 05:54:12 -0800 (PST) To: Matthieu Boutier , David Schinazi Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , babel@ietf.org, Joel Halpern References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr> From: "Joel M. Halpern" Message-ID: Date: Thu, 9 Nov 2017 08:54:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 13:54:16 -0000 Being a little bit picky here: Could you also add a sentence in section 7.1 stating explicitly that only one source specific prefix is permitted in a TLV? I realize this is implied by the use of "a source prefix" in section 5.1. I think it would help to be explicit. If the sending side restriction is made explicit, then the text you propose for the receiving side is acceptable, although I would personally prefer that it used an upper case SHOULD for ignoring the whole TLV. This preference is driven by a desire for robustness and predictability in interoperation. Yours, Joel On 11/9/17 8:48 AM, Matthieu Boutier wrote: >> maybe I summon the wrath of the Gods of the Internet. > > Hey! What's the protocol for that? :p > >> If you don't expect this to ever be useful, no need to specify it. > > Looks good for me, does something like the following make sense? Should we > recommend something? > > A node does not expect to receive any TLV with two Source Prefix sub-TLVs or > more. Whenever that occurs, the behaviour is undefined: an implementation > may drop the whole packet, the whole TLV or consider only just one of the > sub-TLVs (this can be the case if the implementation does not check if > multiple sub-TLVs are sent). > > Toke, would you like to see: "It is recommended to ignore the whole packet". > (lower case "recommended") > > Matthieu > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Sun Nov 12 08:50:09 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3A312945D; Sun, 12 Nov 2017 08:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 OQneIxGAnSrj; Sun, 12 Nov 2017 08:50:06 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.113]) (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 465501200F3; Sun, 12 Nov 2017 08:50:06 -0800 (PST) Received: from [193.109.255.99] by server-9.bemta-6.messagelabs.com id BE/82-30115-CBB780A5; Sun, 12 Nov 2017 16:50:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUgTYRzHe+5u2xW7uGbLn0v/cBaR6TASUch ahSBY9PKHlZR2q2tbbaftZlhBLchaamX2ujKcaMNqf6QZRa2IUSPFMswkxaXhC6VI9l5mL3e7 WXZ/HJ/n9/19v8/veXhIXNUq15BskZ21cYxFK59GJMfqNyf69pE5SU5/VGrZsQWpTZXf8FS3d 0ChxzNra79jmY86L+FrsByZmTPkF22Rma69/CkvuDG7qPVSO3KgPihB00iCPoxDWSBIiAsVXY FBzWh7eNGLoG2kGitBU0k5nQ4N14JykWfSuTDW+FomMk6vhdKGywqRI2g1FA+2CEwKPRq4d3W W1K4D71gfLjJBz4WLrV9DTNGbYMhzKhSD6FnwtdmLSZGR0NVfFWKgaaj1teISq+Ft369wvwF6 BqqRVI+F868qFRLHQFtVKRLnB9qvgLqGgXCQDm6eHAkbVoG3pEsuzgl0HDS+2Sz1exB0PHTIp Z54aBnvD3t3QofzftibBW7PmEIyBGUw/vuFTBKi4en7HkISnsng81lXyK2it8Ljyo+EdEMaCL YfRRJHw5vue7JyNP/CpFNLzMGDugBxIXRLM6DJ1U9I9QRw3/0gl3gBeKqH8QluedCHTa67keI qmseztt2sLXGRzmAzG012K2O2JC5MStFZWZ5njKyFMfC6rfnWBiQ8qCnCdxs5fy33oygS06qp OR8VOarphvxte0wMb8qzFVpY3o+iSVILFLeXzFHNsLFGtmi72SK8ygkZSKV2JqXeI8gUX8BYe bNRkppRGnm9MziOkfdD/0HXsANXEVw+x2oiqXQxjxYNpkLub9zEO29DMZoICgkDqpQFrM1qtv +vD6FIEmkjqICYojRz9r+7DgkDYcJAGvEsFG9n/kkaB6pKOJG9utG1osvtSqgbKV18PvnMgXX OJ1kVK9cXLI0IeEY/LRqsziiueD6acdBV4QvuvzN4a1vSklv1afquEn/k8TW7jM5ngaUbj5zJ UPb4NsRdeZeXcpHz7lsVm5ex0lA+nK3vrXnvz526P/f0i2U7zOqRL+WHzn3wKX/ExQTqu3eWa QnexCyMx2088wcUKe+I4gMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-48.messagelabs.com!1510505401!80864235!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 19688 invoked from network); 12 Nov 2017 16:50:03 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-12.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Nov 2017 16:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hxdEb7l2iTtjnkukrR/+KrW2gOjTPF91Skd5U/E7J5U=; b=XX9pW3EyWsHz/+o2eDm8e3PRpdBJQJuRL0obmVl1cjarjriGPhHDlnwLfjOHap/SGxRpR89/dQy/XSXNtooAEQ1uhNzOrBrE1nz7kc3bKx1lruAF1t8jj/QdTVo8BruU0Zb1m13y5NvFwJWz1P3k2f+2QGuX8UvA+xQAJpcSRrk= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1714.eurprd03.prod.outlook.com (10.167.88.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sun, 12 Nov 2017 16:49:59 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216%13]) with mapi id 15.20.0197.017; Sun, 12 Nov 2017 16:49:59 +0000 From: Alexander Vainshtein To: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" CC: "rtg-dir@ietf.org" , "rtg-ads@ietf.org" Thread-Topic: My vacation Thread-Index: AdNb1eSA1mnpI1H0SDm9ty2JKsn0IQ== Date: Sun, 12 Nov 2017 16:49:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1714; 6:o31eBVmhj4K6wpS/I/mRrZXeb17eQZjeK/4g4EJnyexoyab5ftjX0zhreEDnn4hBwqmQrz0zD8TYCZC15u04t3YMfVFYSZ0XcM2h4LRwvcZCi8+wfBxQjic4sQ6tfZEOtrK4XT3Sgp1xuBB520G9DBSHIOaKFZRoG2pr1GX+6YpZDwXctyugcPlG38QrL5sQKglFQtXykHVeBILYIY0lJqSoFBkCoQb88cTMPHAz+hhx1XAygIrN2kcHRADOVDpdB1hpzAvUoEdpx/r2/wKQMlDZrEsdth4x92/3+Q/cHhG6KVeeEJ94F+NoSbj946ve9NuhPgqHEnb6C3KU1mYNwM3fFUd47GSkUligDLZ+bMY=; 5:I+cbyedyy1vvFlDVWhOaHmE3ImoG6bY0RZwa10PVdCkcNCYejEDuBFtHjkw6mdXgtIM9n+jpvB54Hl0KTZcnRNpvLeaWpTIey+6ox0qNL3my6Iee5JSwXq9G1tH7ViXChKnBPQP00EHH88zYRfgDtsCnvx7iSZBb6T6yUHYAnl0=; 24:PUn60VESoo8P/aX/obUXjre4ng4csSH2jo/rZHTSrGdQXuhjOzZ4Xu5+c8k8udqjlxtBqNqwPID0bhh0m3dIJf7u4bxAJ4r94qLkZAViBo4=; 7:IAg09E2k/ZWIcDr53KdL0qOdlTsxj6cO+l8CFofWuizoDgstN0BFMb2sUxl8tea8ILaXauE154Zil9vemo/0Fxtx1JDRAgumrWrsn8ldUf/zi29Z7h3snPR2srCqR8O0lY22xV72+bWnHr2tWNr58koFl7CJNmEzv4ctrY71YSYsTWd56gylCVW7dyB29IGdlLMHjcbOqhDaKh8f2z2ZOf8XxJdYVIJes1glcHYIpufYr2p7y9UtMzC3cK0Wc7Kh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: efa1f9f8-eea9-40c8-de3a-08d529ed699f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR03MB1714; x-ms-traffictypediagnostic: AM4PR03MB1714: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1714; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(189002)(37984002)(199003)(252514010)(81166006)(55016002)(54906003)(81156014)(189998001)(105586002)(5250100002)(50986999)(4743002)(8676002)(33656002)(316002)(54896002)(6306002)(74316002)(4326008)(7736002)(68736007)(9686003)(106356001)(54356999)(25786009)(8936002)(53936002)(66066001)(72206003)(5660300001)(97736004)(2906002)(6436002)(3480700004)(6116002)(6506006)(790700001)(3846002)(102836003)(3280700002)(101416001)(3660700001)(86362001)(7116003)(7696004)(2900100001)(6916009)(99286004)(14454004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1714; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: efa1f9f8-eea9-40c8-de3a-08d529ed699f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 16:49:59.8240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1714 X-CFilter-Loop: Reflected Archived-At: Subject: [RTG-DIR] My vacation X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 16:50:08 -0000 --_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan, and all, I will be on vacation in the US from 17-Nov-17 and until 10.12.17 (both da= tes inclusive). I will have only limited access to my email during this period and will no= t be able to do any reviews for the RTG-DIR if the deadline is within or v= ery close to this interval. I apologize in advance for possible inconvenience. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jonathan, and all,

I will be on vacation in the US from 17-Nov-17 and = until 10.12.17 (both dates inclusive).

 

I will have only limited access to my email during = this period and will not be able to do any reviews for the RTG-DIR if the = deadline is within or very close to this interval.

 

I apologize in advance for possible inconvenience.<= o:p>

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com=

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_-- From nobody Tue Nov 14 21:55:26 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5041294F0 for ; Tue, 14 Nov 2017 21:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.846 X-Spam-Level: ** X-Spam-Status: No, score=2.846 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGUAtVVwlV0w for ; Tue, 14 Nov 2017 21:55:24 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A7F361243F6 for ; Tue, 14 Nov 2017 21:55:24 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.139.117; From: "Susan Hares" To: Cc: "'Alexander Clemm'" Date: Wed, 15 Nov 2017 00:55:19 -0500 Message-ID: <003c01d35dd6$53041f80$f90c5e80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D35DAC.6A2F9E20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNd1fkVz82/QxsEQjq8nIetK5Gbwg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [RTG-DIR] [RTG-DIR} Rtgdir early revie wof draft-ietf-i2rs-yang-l3-topology-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:55:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01D35DAC.6A2F9E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Chris: Thank you for your review of: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ found at: https://mailarchive.ietf.org/arch/msg/rtg-dir/2ELh2F2UObsCRaCiCSKSPj-xevU On your comments: #1) The draft has an normative reference to the NMDA documents. #2) The ISIS example has been removed . Thank you for your comments. Sue Hares Draft shepherd ------=_NextPart_000_003D_01D35DAC.6A2F9E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris: =

 

Thank you for your review of:

  https://datatracker.ietf.org/doc/draft-ietf-i2rs-=
yang-l3-topology/

 

found at: =

 

https://mailarchive.ietf.org/arch/msg/rtg-dir/2ELh2F2UObsCRaCiCSKSP= j-xevU

 

On your = comments:

#1) The draft has an = normative reference to the NMDA documents. 

#2) The ISIS example has been removed . =

 

Thank you for your comments.

 

Sue Hares =

Draft = shepherd

------=_NextPart_000_003D_01D35DAC.6A2F9E20-- From nobody Tue Nov 14 22:05:55 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25FE1294FF; Tue, 14 Nov 2017 22:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 v6BBRBcl8xR1; Tue, 14 Nov 2017 22:05:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B6B7B1294F8; Tue, 14 Nov 2017 22:05:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.139.117; From: "Susan Hares" To: Cc: , "'Alexander Clemm'" Date: Wed, 15 Nov 2017 01:05:48 -0500 Message-ID: <004c01d35dd7$ca7603c0$5f620b40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01D35DAD.E1A1F790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNd1t3SuGoaFkPpRn60MdtlcaynJg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-i2rs-yang-l3-topology X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:05:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01D35DAD.E1A1F790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Matt: Your delightful review in July 19th, 2017 went unanswered. As the shepherd, I apologize for the delay in responding to you. Thank you for the complements for your draft. Great minds think alike. Originally, this draft had ISIS, OSPF, and none of your "useless" descriptions. It is satisfying that great-minds in the RTG-DIR Think alike. I helps me know I'm not crazy. Great minds think alike in the OPS area, but they do not think like RTG-DIR people. The changes in this document are due to the recommendations by Yang Doctors and NETMOD to add things that are expected by OPS-DIR. So. in the interest of inter-Area harmony, I2RS compromised and added the information. Sue Hares ------=_NextPart_000_004D_01D35DAD.E1A1F790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matt:

 

Your = delightful review in July 19th, 2017 went unanswered.  = As the shepherd, I apologize for the delay in responding to you. =  Thank you for the complements for your draft.  =

 

Great minds think alike.   Originally, this = draft had ISIS, OSPF, and none of your “useless” = descriptions.   It is satisfying that great-minds in the = RTG-DIR Think alike.   I helps me know I’m not crazy. =

 

Great minds think alike in the OPS area, but they do = not think like RTG-DIR people.   The changes in this document = are due to the recommendations by Yang Doctors and NETMOD to add things = that are expected by OPS-DIR.   So… in the interest of = inter-Area harmony, I2RS compromised and added the information. =   

 

Sue Hares

------=_NextPart_000_004D_01D35DAD.E1A1F790-- From nobody Tue Nov 21 00:16:56 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66E212773A; Tue, 21 Nov 2017 00:16:49 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fxqxkaGYcexk; Tue, 21 Nov 2017 00:16:47 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 7D1961293E0; Tue, 21 Nov 2017 00:16:47 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAL8GfDd011541; Tue, 21 Nov 2017 09:16:41 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3C547EB217; Tue, 21 Nov 2017 09:16:41 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6dVSJjskP84K; Tue, 21 Nov 2017 09:16:39 +0100 (CET) Received: from mac-matthieu.lan (AAubervilliers-652-1-169-162.w86-218.abo.wanadoo.fr [86.218.8.162]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A87FAEB216; Tue, 21 Nov 2017 09:16:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthieu Boutier In-Reply-To: Date: Tue, 21 Nov 2017 09:16:36 +0100 Cc: David Schinazi , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.4.7) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 21 Nov 2017 09:16:42 +0100 (CET) X-Miltered: at korolev with ID 5A13E0E9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A13E0E9.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5A13E0E9.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 08:16:50 -0000 > Being a little bit picky here: All improvements are welcome! Thanks for the advices and explanations. > Could you also add a sentence in section 7.1 stating explicitly that = only one source specific prefix is permitted in a TLV? I also rewrite the introduction of 7 to precise the behaviour when = multiple or malformed sub-TLV are received. Thanks for the feedback. This is pushed on the git = (https://github.com/jech/babel-drafts). Matthieu= From nobody Wed Nov 22 01:12:44 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAE120726; Wed, 22 Nov 2017 01:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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, RCVD_IN_MSPIKE_H2=-2.8, 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=metaswitch.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 KYxAN1fzkEeu; Wed, 22 Nov 2017 01:12:35 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0097.outbound.protection.outlook.com [104.47.38.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9315D124B09; Wed, 22 Nov 2017 01:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OpDO22C6nAa6f0dIrxTQ6hx8SXuXyc2qfNlPgXCdDb4=; b=ZViEnYfXqShKm66QYGk779+edLZHFjdel82qJsq4qWa3t5bhb6A2Zw/OhTsnE5A5CxcieAgHmcgHAq8hfCqoqGkxyCkaP+3WhJO4uS/4W23s72LtfgVssRhU2u316D0WRXxQ05YYFLby6PQFyBnDuNMDZr4aP0Ej72XThI94FW8= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3604.namprd02.prod.outlook.com (52.132.99.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 09:12:32 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 09:12:32 +0000 From: Jonathan Hardwick To: "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@ietf.org" Thread-Topic: Routing area draft minutes available Thread-Index: AdNjce2Dujszsli0T6WRrXLK1zsDGA== Date: Wed, 22 Nov 2017 09:12:31 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3604; 6:CQpYr8YL/OL4ZZ1E0kTPwDob0YAzUsKoUU93b/+SIL0W+8gHLhw/65Jk28iKfhv9gd3AxsnZwvYAIU04nt2c6yy2IG0N+zD/s7k/o3GkMYG18OQT0sCOiKZP2T5+kVpTz53RdyC1Uq1LSOVef1udVQ737yjWROI984pCqrC6KPhO8pS7UqgwKYUYbn3XUMaMeKp4W7XCSY3UjMwoIqzuYk3VzX/Vi80OHeQFzxTTKtpBvFNk0eKIaAwXRIyEvNTkXZF9O7pUCY8Sz9gDNy7ga20apeJEVCTT69siDp4n14UvrNyUKneQtLPfbmAekDjhl6KkCqXdaefbRzK07m6k9hOYAdQylmAleFr45gRQs3Q=; 5:WTDBMcXG1MKJd1DlWlL1vKcf4VlDRXCGHkcBS843JgqMkdZMEaHrKnGsUB8Y0/o4wTgf0riH8lxlWMH1F35Xn62yYCkeoXmof5bNMiEZUBY6MPyX3Z66JQj19yswuslvVcfr1xphSlbOEsKJXTpP6G5MeaeNVBLg76gBHr/AN2w=; 24:Xy4+iXEphq8AwWZxduKAc1t1kC+OS7ICwEHV5tetd59lGGafxcMiol0BIq3KcMqzair91vNYCNWJ/9dsP3B52i/RJ47GatLEIacXc3rDW7I=; 7:2klxoGjlziJ6bFi4hEFKpxwHs3Mey/O3/Pk2VFHeZ4zUIa9noT1BO5mEG1IRImDkanEzYqyd03dtlD71pHzMzhgCVKHS1WHYfIj/hLmQEG/F/DbvLdjRoiJrD8i43xX6LEwQirrw/ta69vgq7x3XbZhgTUWQYw0vnVNtCiuJKncUUbCGdlUeE7dbmtHdxl22zQbfznhNu1LHQqhYjJooPjYBM4vyiEcifYDXdvj66tFnx95uEY/o6XMi5KtFjWlY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 86dad48d-6594-4f66-4836-08d531892998 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3604; x-ms-traffictypediagnostic: CY4PR0201MB3604: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3604; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(199003)(189002)(316002)(33656002)(110136005)(14454004)(86362001)(8936002)(97736004)(25786009)(6506006)(5660300001)(189998001)(106356001)(105586002)(966005)(7696004)(54896002)(53936002)(236005)(55016002)(68736007)(6306002)(6436002)(2900100001)(450100002)(72206003)(5250100002)(9686003)(478600001)(74316002)(3280700002)(99286004)(7736002)(790700001)(3846002)(6116002)(2201001)(102836003)(54356999)(50986999)(606006)(2906002)(101416001)(66066001)(81166006)(558084003)(81156014)(2501003)(8676002)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3604; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86dad48d-6594-4f66-4836-08d531892998 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 09:12:31.9982 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3604 Archived-At: Subject: [RTG-DIR] Routing area draft minutes available X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 09:12:37 -0000 --_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the RTGAREA meeting at IETF 100 are now available. P= lease let me know if you have any comments. https://datatracker.ietf.org/doc/minutes-100-rtgarea/ Best regards Jon --_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the RTGAREA meeting at IETF= 100 are now available.  Please let me know if you have any comments.<= o:p>

https://datatracker.ietf.org/doc/minutes-100-rtgarea/

 

Best regards

Jon

 

--_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_-- From nobody Tue Nov 28 03:10:33 2017 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9BE127369; Tue, 28 Nov 2017 03:10:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Niven-Jenkins To: Cc: pce@ietf.org, draft-ietf-pce-pcep-exp-codepoints.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151186742816.13409.4274999012117883106@ietfa.amsl.com> Date: Tue, 28 Nov 2017 03:10:28 -0800 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:10:28 -0000 Reviewer: Ben Niven-Jenkins Review result: Ready RtgDir review: draft-ietf-pce-pcep-exp-codepoints-04 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-pcep-exp-codepoints-04 Reviewer: Ben Niven-Jenkins Review Date: 28th November 2017 IETF LC End Date: Not known Intended Status: Proposed Standard Summary: No issues found. This document is ready for publication. Comments: The document is well written and readable with clear guidance to IANA. Major Issues: No major issues found. Minor Issues: No minor issues found. Regards Ben From nobody Tue Nov 28 03:12:15 2017 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5466D126BF0; Tue, 28 Nov 2017 03:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 88WJhJZ5OgZs; Tue, 28 Nov 2017 03:12:11 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BE81200F3; Tue, 28 Nov 2017 03:12:11 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 17CA8EDB53E4E; Tue, 28 Nov 2017 11:12:08 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 11:12:09 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 16:41:56 +0530 From: Dhruv Dhody To: Ben Niven-Jenkins , "rtg-dir@ietf.org" CC: "pce@ietf.org" , "draft-ietf-pce-pcep-exp-codepoints.all@ietf.org" Thread-Topic: [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04 Thread-Index: AQHTaDmPNCdRCbcL3EqacLHp06r5saMpoi1A Date: Tue, 28 Nov 2017 11:11:55 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8D5E5874@BLREML503-MBX.china.huawei.com> References: <151186742816.13409.4274999012117883106@ietfa.amsl.com> In-Reply-To: <151186742816.13409.4274999012117883106@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [RTG-DIR] [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:12:13 -0000 VGhhbmtzIEJlbiBmb3IgeW91ciByZXZpZXchIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQmVuIE5pdmVuLUplbmtpbnMNCj4gU2VudDogMjggTm92ZW1iZXIgMjAxNyAxNjo0MA0KPiBU bzogcnRnLWRpckBpZXRmLm9yZw0KPiBDYzogcGNlQGlldGYub3JnOyBkcmFmdC1pZXRmLXBjZS1w Y2VwLWV4cC1jb2RlcG9pbnRzLmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbUGNlXSBSdGdkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXBjZS1wY2VwLWV4cC0NCj4gY29kZXBvaW50 cy0wNA0KPiANCj4gUmV2aWV3ZXI6IEJlbiBOaXZlbi1KZW5raW5zDQo+IFJldmlldyByZXN1bHQ6 IFJlYWR5DQo+IA0KPiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXBjZS1wY2VwLWV4cC1jb2Rl cG9pbnRzLTA0DQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KPiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkDQo+IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQg SUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMNCj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0bw0KPiB0aGUgUm91 dGluZyBBRHMuDQo+IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlIA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyDQo+IA0KPiBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJp bWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQNCj4gd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRG IExhc3QNCj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoDQo+IGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 Lg0KPiANCj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGNlLXBjZXAtZXhwLWNvZGVwb2ludHMtMDQN Cj4gUmV2aWV3ZXI6IEJlbiBOaXZlbi1KZW5raW5zDQo+IFJldmlldyBEYXRlOiAyOHRoIE5vdmVt YmVyIDIwMTcNCj4gSUVURiBMQyBFbmQgRGF0ZTogTm90IGtub3duDQo+IEludGVuZGVkIFN0YXR1 czogUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IFN1bW1hcnk6IE5vIGlzc3VlcyBmb3VuZC4gVGhp cyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQo+IA0KPiBDb21tZW50czogVGhl IGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQgcmVhZGFibGUgd2l0aCBjbGVhciBndWlkYW5j ZSB0bw0KPiBJQU5BLg0KPiANCj4gTWFqb3IgSXNzdWVzOiBObyBtYWpvciBpc3N1ZXMgZm91bmQu DQo+IA0KPiBNaW5vciBJc3N1ZXM6IE5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCj4gDQo+IFJlZ2Fy ZHMNCj4gQmVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBQY2UgbWFpbGluZyBsaXN0DQo+IFBjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K