From nobody Wed May 9 23:06:52 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94A126CE8; Wed, 9 May 2018 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, 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 lNt98Nij4SDs; Wed, 9 May 2018 23:06:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773DC127078; Wed, 9 May 2018 23:06:42 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EF53058C4E5; Thu, 10 May 2018 08:06:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DF1BE440218; Thu, 10 May 2018 08:06:36 +0200 (CEST) Date: Thu, 10 May 2018 08:06:36 +0200 From: Toerless Eckert To: "Pascal Thubert (pthubert)" Cc: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Message-ID: <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Int-dir] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 06:06:50 -0000 Thanks, Pascal, sorry for the delay, Comments inline. Version: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Diff to prior version (-14 for Joel Halpern) http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Will commit as -14 when i am through with the other -13 feedback. Cheers Toerless On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) wrote: > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomic-control-plane-13. > > These comments were written primarily for the benefit of the INT and OPS Areas Directors from the IoT perspective. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the IoT Directorate, please see https://datatracker.ietf.org/group/iotdir/about/ and for Directorates in general please see https://www.ietf.org/about/groups/directorates/. > > > I'll be away for the next 2 weeks and could not finish the review in time for this heavy document, but at least I made it through till the RPL section. In the interest of time, let me share what I already have. > > > > Summary > > ------------- > > The summary of the review is that the document is Ready for Publication, with comments. > > > > > > Major comments > > ------------------------ > > > > - " in-band" and "out of band network " > > should be defined since it is fundamental to understand that the ACP takes place in the same physical links as the data plane, as opposed to dedicated management ports (correct?); Good point, done. (got a bit too long to paste here, so pls. check diff). > > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; Not sure i understand the "point on Michaels enrollment draft". I am happy to add pointers to variations of ACP design aspects for informational purposes to show that/how it can be modified, but Michaels drafts i think are all variation of the BRSKI design, so the ACP would be completly unaffected by them, right ? Wrt. constrained devices and L2. I didn't want to touch section 3 for what you suggested because that really a very formulistic section going back to the charter 1 justifications of ANIMA and matched with the three numbered use case explanations in the introduction. Instead i wrote text at the end of the introduction, now section 1.1, This got longer than i hoped, but it was really a big missing piece to pitch the ACP and give early on context for implementers and reminding of the charter goal of reusing the best available existing protocols/function. The text got longer specifically also because i did not want to fall into the trap of making claims whether or not ACP is applicable to specific IOT networks or (even worse) assuming IOT is always constrained. Therefore mentioning of OT networks (IMHO big part of IOT, and often totally non-constrained), explanation of why RPL, and at the end a statement about constrained environments. There is also a new paragraph in 10.8 about TCP/TLS vs. CoAP/DTLS as a possible constained environment variant in the future. > - " Inside the ACP VRF, each node sets up a loopback interface with its ULA IPv6 address" > This is the first time, IPv6 is discussed; would have been nice to introduce that the Node has IPv6, that it needs a ULA and that ACP assigns it. This discussion could be done in conjunction with the comment above; Actually, section 1. introduction already mentions that the ACP provides IPv6 and that the stable-connectivity document describes how to interoperate with IPv4 only OAM. I added to the new 1.1 section (see above) the following paragraph, which i hope is a useful context setting and pitch: The ACP uses only IPv6 to avoid complexity of dual-stack ACP operations (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even otherwise IPv4-only network devices. The data-plane itself would not need to change, it could continue to be IPv4 only. For such IPv4 only devices, the IPv6 protocol itself would be additional implementation footprint only used for the ACP. > - About "The ttl > parameter SHOULD be 3.5 times the period so that up to three > consecutive messages can be dropped before considering an > - announcement expired. " > > This is the only discussion on the ttl field of the M_FLOOD. Though its meaning is quite obvious, the behavior associated to it should be defined. Added: When a service announcer using these parameters unexpectely dies immediately after sending the M_FLOOD, receivers would consider it expired 210 seconds later. When a receiver tries to connect this dead service earlier, it will experience a failing connection and use that as an indication the service is dead and select another instance of the same service instead. > - "In the above (recommended) example the period of sending of the" > Is this RECOMMENDED IOW normative?? Hmmm... Sure, why not. Less guessing/experiementation for this. Modified to RECOMMENDED. > - Text P 25 says "At this time in the lifecycle of ACP nodes, it is unclear whether it > is feasible to even decide on a single MTI (mandatory to implement) > security association protocol across all ACP nodes" > but then P27 "It MUST support ESP > with AES256 for encryption and SHA256 hash and MUST NOT permit weaker > crypto options." > > and then " A baseline ACP node MUST support IPsec natively and MAY support IPsec > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > connecting constrained areas with baseline areas MUST therefore > > support IPsec and dTLS." > > Seems that text P25 should go? P27: An ACP node supporting native IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for encapsulation. It MUST support ESP... (parameters). clarified to: P27: An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for encapsulation. It MUST then support ESP... (parameters). Also: ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security setup.. clarified to: An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec security setup.. Aka: P25 is correct, there is no single MTI. 6.7.3 defines the actual requirement for two different profiles: "baseline ACP node" and "constrainted ACP node". The two requirements in P27 are only conditional MUSTs defining the details of the IPsec profiles assuming a node does support IPsec or IPsec/GRE. Let me know if this is still unclear, and if so, how you would suggest to make it better readable. > - "Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > with L=1]." > > This needs to be more crisp. ULA is defined in RFC 4193 but the term ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 is the way addresses are formed, if so please say so. The best practice RFC 8064 recommends use of RFC 7217. I understand that privacy is not a concern but does it hurt? Anyway please point at section 6.10 and 6.11.1.11 The term "ULA-Random" was used in the discussions on ANIMA mailing list re. ULA, so admittedly i didn't check that the term as it stands is actually not defined/used in rfc4193 - but its just meant to imply ULA with L=1, nothing more. I've removed the use of ULA-Random from the text and just refer now to 4193 with L=1 (also pointing to 3.1. of rfc4193 defining L). I have also added a note that the hash uses our own ACP definition instead of rfc4193 3.2.2. Paragraph is now: Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local Addresses (ULA), as defined in with L=1 (as defined in section 3.1 of ). Note that the random hash for ACP loopback addresses uses the definition in and not the one of section 3.2.2. 8064/7217 are irrelevant here if i understand it correctly because we define the addressing scheme for anything following the ULA prefix ourselves for ACP addresses. Let me know if i do misunderstad what you where trying to suggest re. 8064/7217. > - " > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with multicast support". Implementations should support also other modes. > > Note: Root indicates mode in DIO flow" > > Why "should" ? there is no much point supporting the other modes is there? Section 6.11.1.13 says that SRH is not used so this is inconsistent. You only need MOP 2 or 3, 3 is you do multicast which at the moment does not appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). Probably a transcription error on my side when i took your RPL summary and wrote it down. Fixed according to above. > - "The lack of a RPI (the header defined by [RFC6553]), means that the > data-plane will have no rank value that can be used to detect loops. > As a result, traffic may loop until the TTL of the packet reaches > zero. " > > Since we have reliable links and no stretch (section 6.11.1.7), loops should be exceedingly rare. It could be recommended to send the DIOs 2-3 times to inform children when losing the last parent. Note that the technique in section "8.2.2.6. Detaching" of RFC 6550 should be favored over that in section "8.2.2.5. Poisoning" because it allows local connectivity. Also, It should be said that a node should select more than one parent, at least 3 if possible, and send DAOs to all of then in parallel. This provides multi Not sure why your paragraph ends apruptly, buts its also in the archive, so its not a mistake on my email end. Hopefully nothing significant missing. I have replaced the suggestive text that followed your above quoted text in the draft: There are a variety of heuristics that can be used to signal from the data-plane to the RPL control plane that a new route is needed. With a hopefuly correct transcription of your suggestion: Since links in the ACP are assumed to be mostly reliable (or have link layer protection against loss) and because there is no stretch according to , loops should be exceedingly rare though. There are a variety of mechanisms possible in RPL to further avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform children when losing the last parent. The technique in section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2.2.5. (Poisoning) because it allows local connectivity. Also, nodes SHOULD select more than one parent, at least 3 if possible, and send DAOs to all of then in parallel. > - "ACP nodes MUST perform standard IPv6 operations across ACP virtual > interfaces including SLAAC (Stateless Address Auto-Configuration - > RFC4862])" > > They may actually prefer Optimistic DAD RFC 4429 since address duplication is highly improbable as long as you . Added: "Optimistic Duplicate Address Detection (DAD)" according to is RECOMMENDED because the likelyhood for duplicates between ACP nodes is highly improbable as long as the address can be formed from a globally unique local assigned identifier (e.g.: EUI-48/EUI-64, see below). > Minor comments > > ------------------------ > > > > > > - About "[RFC7575] defines the fundamental ... " > > for readability, it may be nicer to indicate the title of an RFC when it is referenced first; e.g. the text above would become > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines the fundamental ... Ok, i am punting this one for now to RFC editor after playing around a bit with the XML options - and not being satisfied... and having references for 50 RFCs in the doc: [RFC Editor: Question: Is it possible to change the first occurrances of [RFCxxxx] references to "" [RFCxxxx] ? the XML2RFC format does not seem to offer such a format, but i did not want to duplicate 50 first references to be duplicate - one reference for title mentioning and one for RFC number.] If RFC editor comes back and can't do this easier than i can in XML, i'll try to go through the chores when doc is in RFC editor queue. > - about "or network plane (there is no well-established name for this)" > > The term network plane is not used again in the document. This text may go away. Done. > You may consider using "security and transport substrate" instead, since it is used elsewhere in the document. "autonomic communications fabric" = ACP including ACP GRASP (ACP GRASP provides discovery etc..). "security and transport substrate" == the parts of ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding of ACP). Subtle difference. > Also, please be consistent on whether you use hyphen or not and use that globally, e.g. for the above, and pane like in "forwarding plane" or "out of band network "; Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). Not sure why but this is what MS word spelling checker suggested to me. RFC editor will override if these are not the best choices. > - "data-plen" > Typo? Done > - "OAM applications ("Operations Administration and Management)" > > Consider using "Operations Administration and Management (OAM) applications " instead; same goes for SDN, ASA, VRF, etc... Ok. Tried to fix up all the instances i could find. > - " MIC: "Manufacturer Installed Certificate". Another word not used in this document to describe an IDevID." > > MIC is not used in the document, maybe inform of this equivalence in the IDevID definition instead; same goes for SUDI. Note that UDI is use just once and may not need an entry here. The definitions of those non-necessary terms are there to help others who like me start out not being security experts and are confused about those equivalent or related terms. I specifically didn't want to include discussions about these terms in the definitions that are relevant (eg: IDevID) so as not to clobber up that text. Instead, readers would just look up those redundant terms when they are like me initially confused about them. > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy Networks\". The routing protocol used in the ACP." > > Maybe point on [RFC6550]? Done > - "Connecting over non-ACP Layer-3 clouds initially requires a tunnel between ACP nodes." > > I understands that it is one tunnel between each pair of adjacent ACP nodes, correct? I read "a tunnel" as an end-to-end tunnel, which sounds different Changed to: Connecting over non-ACP Layer-3 clouds requires explicit configuration. See . This may be automated in in the future through autodiscovery mechanisms across L3. > - "ACP relies on group security" > > Add "The" Done > - "An ACP node MUST have keying > material consisting of a certificate (LDevID), with which it can > cryptographically assert its membership in the ACP domain and trust > anchor(s) associated with that certificate with which it can verify > the membership of other nodes (see Section 6.1.2)." > > This is convoluted. Could you make it 2 sentences? Fixed to: The ACP relies on group security. An ACP domain is a group of nodes that trust each other to participate in ACP operations. To establish trust, each ACP member requires keying material: An ACP node MUST have a certificate (LDevID) and a trust anchor (TA) consisting of a certificate (chain) used to sign the LDevID of all domain members. The LDevID is used to cryptographically assert membership in the ACP domain, the TA to verify the membership of other nodes in the ACP domain (see ). > - " Note: LDevID ("Local Device IDentification") is the term used to > indicate a certificate that was provisioned by the owner of a node as > opposed to IDevID ("Initial Device IDentifier") that may has been > loaded on the node during manufacturing time. Those IDevID do not > include owner and deployment specific information to allows autonomic > establishment of trust for the operations of an ACP domain (e.g.: > between two ACP nodes without relying on any third party)." > LDevID was already defined in the terminology. This text may move there or go away. Gone. I added the note that LDevID can not be used directly for ACP to the terminology definition of IDevID. > - " This document uses the term ACP in many places where its reference > document use the word autonomic." > > Add [RFC7575] after "reference document" Done. > - " "routing-subdomain" is the autonomic subdomain that is used to > calculate the hash for the ULA prefix of the ACP address of the node." > > Do you mean ULA suffix? No, the Global ID. Fixed. Actually, i also sumbled across this: RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we have used use the term ULA prefix to refer to the first 48 bits of a ULA address, so i've clarified this more in the terminology. > - " o If the node certificates indicate a CDP (or OCSP) then the peer's > certificate must be valid according to those criteria. e.g.: OCSP > check across the ACP or not listed in the CRL retrieved from the > CDP." > > Please define CDP and OSCP, and/or reference a RFC is possible. Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review should help. > - "enrolment" > Typo Fixed. > - "This can > use a single GRASP M_FLOOD message as shown in above example." > Actually the example is now below. Please reference the figure. Done. Actually its still "above", or i am heavily confused. > > - "The protocol could for example could have been" > > Typo Fixed. > - "if the IPsec connecting" > > Typo? More like sentence structure was strange. Fixed to: "Even if the IPsec connection from Bob succeeded, Alice might prefer another secure protocol over IPsec" > - "ACP wide service discovery" > ACP-wide Fixed. > - "if the IPsec connecting In most other solution > designs such distributed discovery does not exist at all or was added > as an afterthought and relied upon inconsistently" > > Consider removing or rephrasing : ) Removed: Sentence wasn't that bad, but easier removed instead of trying to justify negative observations about reality without being called out to provide even more proof. > > - Maybe consider moving the discussion on multicast P29 -30 to annex? Why Multicast is not used is an interesting discussion but not critical for the protocol operation. Done. > - "it is not quite clear yet what exactly the implications are > to make GRASP flooding depend on RPL DODAG convergence and how > difficult it would be to let GRASP flooding access the DODAG > information" > > Let's chat then. There's work on reliable multicast for RPL using BIER. Yeah if i would just get around to that ;-) For now moved together into informative section together with te multicast discus. > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the > security and transport substrate for the GRASP instance run inside > the ACP ("ACP GRASP"). " > > "running" inside the ACP? Maybe rephrase more globally? > This instance of GRASP runs across the ACP secure channels.. > - "OAM protocols no not require IPv4: The ACP may carry OAM " > Typo no->do Fixed. > - "Consider a network that has multiple NOCs in different locations. > Only one NOC will become the DODAG root. Other NOCs will have to > send traffic through the DODAG (tree) rooted in the primary NOC." > A figure would help. I remember all the discussions we had about setting the prf bits in remote NOCs Sorry. A bit low on cycles right now. Hopefully i'll get around to it later. Created a wish list entry in changelog. > - "RPPL." > Typo Fixed. > - "Administrative Preference ([RFC6552], 3.2.6 " > > The section is correct but that is RFC 6550. Done > > - "This is a standard issue > with tunneling, not specific to running the ACP across it." > Do you really mean Standard or would Classical work better? This is an issue of tunnels, not an issue of running the ACP across a tunnel. > - "Even though loopback interfaces where originally d" > Typo Where -> were Done. > - Section 3, 4, 9 and 10 may move to Annex (by moving the section after the tag) since they are not normative and do not contribute to the understanding of the protocol. This way there should not be a need to indicate normative in other sections. Sections 3, 4 and 9 are fairly short and the flow of the document depends on them being in their particular location. Section 10 could go into an appendix, but it makes not a lot of difference, but past experience has shown that Annex text is a lot less likely to be read given how the RFCs are structured. We had 10 in Annex and moved it up for exactly that reason. > - Well Noted that Section 14 Will be removed/. > Sorry for being interrupted here, Thanks you so much! Toerless From nobody Wed May 9 23:14:28 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E9126DC2; Wed, 9 May 2018 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, 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 YJ5j95A76ZVb; Wed, 9 May 2018 23:14:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99A0126CE8; Wed, 9 May 2018 23:14:21 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DF69F58C4D8; Thu, 10 May 2018 08:14:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C8C36440218; Thu, 10 May 2018 08:14:17 +0200 (CEST) Date: Thu, 10 May 2018 08:14:17 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" Message-ID: <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Int-dir] [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 06:14:23 -0000 Brian: as part of the fixes for Pascals review, i added a section 1.1, applicability & scope that mentions the "professionally managed" and also has one small paragraph at the end re. constrained devices/ networks. I hope this provides qukc/useful scoping of what the ACP does. Cheers Toerless On Tue, Feb 27, 2018 at 10:17:01AM +1300, Brian E Carpenter wrote: > Pascal, > > Great review! > > > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; > > Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. > > I'll leave the rest of your excellent comments to the ACP authors. > > Thanks > Brian -- --- tte@cs.fau.de From nobody Fri May 11 19:21:21 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8840012DA22; Fri, 11 May 2018 19:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG2N7AeHsB6d; Fri, 11 May 2018 19:21:13 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 07E1212DA19; Fri, 11 May 2018 19:21:13 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id w3-v6so3140215pgv.12; Fri, 11 May 2018 19:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4/cmppu1HKN3hEv8Agxjmzz4jGI4RvFffKosg/WSYZc=; b=Y6hT8twFRNwXOZDtrEaYayx/aZg0R2cv6+ygUdXEmra/34cQiFnjnT30DBOKDcBdrV /syLKD9CmttKvfs1ROstLhzIVlet3bR7k1v6hoAzWLiFXTWZ11bA/jUQdjFNMr1aaP9d YV9e2/rsrDBSxe9em1t5Oev/vbdxYC3+OdYbJ96sys98LTUEyoaF56cVx5V+3cCVzJOs KkZgcxQGVkRacENYTX+ajjiv1bxZxUVyQOdaarTSUV+9OEMWPCgUk0CscOQYLZlyJeZv YZD0Cxmri0lxae/AdK27oPww4pw5e85rzgiMTiT9i0NEgN9vlcHGs6n29+YqSWPTBlIK p2Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4/cmppu1HKN3hEv8Agxjmzz4jGI4RvFffKosg/WSYZc=; b=kj12ZuRMb0iRO/5AkVyc1Z9/fhDI4hOUmk07wBRZZxSskUg0PHkFZCWe46CrPktUjr 1exKbh3Dp98aIkelAcQYcRV8NWxkhHjc1sBXl5tMiQs9oDpN0e4tXTkfoXHFhKLZiuca EFfxIgHlYvVrPhCc+Rd3I2HBn4eKNLXUGfNv+pY0Ds+W8afAHYI9f/w/hjUJ0Px0lU4j GTgctBl1s0OAUocxEYyKWapwqd0CG6s2ZWeNdjdAeCf81DWu0LodHNFjfcQowqpz/aSg 5HNqPe/RsXxVNTxjgXlvISLi4wIIla7iNJXjkNR8J8GTynC1gpZmndA29QG3oak5oXzB oIGQ== X-Gm-Message-State: ALKqPwfRWtwdLrGDLOPgi9hgP9CzN/XuQWGd7lG6EiBNO3k/oIN8Ddig ezDFwfV4lm/MWHwnpSUER440eQ== X-Google-Smtp-Source: AB8JxZoQaSsjMub5jwsgkbB0gBKzfyHpA8TSmt0p/7SzG7fXVUU3nu3sSpNfeGBGCV7HBMqZtGz+kg== X-Received: by 2002:a62:469b:: with SMTP id o27-v6mr1263962pfi.124.1526091672243; Fri, 11 May 2018 19:21:12 -0700 (PDT) Received: from [192.168.178.26] (211.245.69.111.dynamic.snap.net.nz. [111.69.245.211]) by smtp.gmail.com with ESMTPSA id b28-v6sm5609388pfl.168.2018.05.11.19.21.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 19:21:11 -0700 (PDT) Sender: Brian Carpenter To: Toerless Eckert Cc: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <6730013f-49e4-97c5-4872-a75c8ca5ab41@gmail.com> Date: Sat, 12 May 2018 14:21:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180510061417.qptyeweyhr3x7it5@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-dir] [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 02:21:15 -0000 Hi Toerless, Yes, section 1.1 works for me. Personally I hope that some of what we do here can later become self-deploying in unmanaged networks, but that is out of WG charter at the moment and purely a dream. Regards Brian On 10/05/2018 18:14, Toerless Eckert wrote: > > Brian: as part of the fixes for Pascals review, i added a section 1.1, > applicability & scope that mentions the "professionally managed" > and also has one small paragraph at the end re. constrained devices/ > networks. I hope this provides qukc/useful scoping of what the ACP > does. > > Cheers > Toerless > > On Tue, Feb 27, 2018 at 10:17:01AM +1300, Brian E Carpenter wrote: >> Pascal, >> >> Great review! >> >>> - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; >> >> Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. >> >> I'll leave the rest of your excellent comments to the ACP authors. >> >> Thanks >> Brian > From nobody Mon May 21 07:24:57 2018 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6013127137; Mon, 21 May 2018 07:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Haberman To: Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152691268188.22908.6810216714051964245@ietfa.amsl.com> Date: Mon, 21 May 2018 07:24:41 -0700 Archived-At: Subject: [Int-dir] Intdir early review of draft-ietf-dmm-ondemand-mobility-14 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 14:24:42 -0000 Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following issues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connectionless, this term is really about IP address stability and its lifetime. A new term could/should be coined to reflect what is really needed. 2. The needs described in this document have a mix of the ID/Location split issues raised in a variety of other specifications. It would be good to clarify what is different here. 3. The draft only references host-based Mobile IP specifications. What are the implications when other solutions (e.g., PMIP) are employed? 4. It is problematic that this document explicitly rules out of scope any discussion of how this API interacts with address assignment methods (e.g., DHCP). Clearly, there will need to be a way for this API to influence each of the address assignment methods available. Some of the classes of IP addresses described in this document require certain lifetime guarantees from the address assignment method. That needs to addressed since it will require changes to every assignment method. 5. The IETF has a very checkered history of success in getting APIs standardized within the appropriate group (POSIX/Austin/Open). Has this proposed API been discussed within that community? From nobody Tue May 22 07:07:01 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EF1270A7; Tue, 22 May 2018 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNTd0FrF3iN; Tue, 22 May 2018 07:06:49 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF9512EB46; Tue, 22 May 2018 07:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25843; q=dns/txt; s=iport; t=1526998008; x=1528207608; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wCmjHlFr1AmP1O6FCdQ8WWC6BoihPpNLTo03APTNfYc=; b=mapjxUykSeW/tY5N8Jn0bzOFIS3itumi3BTpBJUkUZtpHXsqGskAxI4u vE2YgfyC5XfxNQtQPJb1JAdO5hrntWJgYzQsNYzrY4yIE8o2g/MPu2ZAv z2yyR2T0P09QGUlEzXc2bvke/FXfDgCfWebYuH+U4/MTGpFtUVEZygvse I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AABjIwRb/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMYK2J9KAqLb4x3gXl1GpM2FIFkCyWERwKCISE0GAECAQE?= =?us-ascii?q?BAQEBAmwcDIUoAQEBAQIBGg0TMQMLBQsCAQgOCh4QMiUBAQQODRODCYF3CA+?= =?us-ascii?q?qOjOIRYIPhxKBI4FUP4EPgRF9SjWDEQEBAgEXgRMXBIVsAoccFwoRhFOBIos?= =?us-ascii?q?MCQKFaG+HdoE/PoMwgl+EeolghnMCERMBgSQBHDhhcXAVGiGCMwEPCYIWARd?= =?us-ascii?q?6AQKCSIUUhT5vAQGMFiqBBIEYAQE?= X-IronPort-AV: E=Sophos;i="5.49,430,1520899200"; d="scan'208";a="118217003" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2018 14:06:47 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4ME6k5l001878 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2018 14:06:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 22 May 2018 09:06:46 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 22 May 2018 09:06:45 -0500 From: "Pascal Thubert (pthubert)" To: Toerless Eckert CC: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Thread-Topic: An IOT DIR review of draft-ietf-anima-autonomic-control-plane Thread-Index: AdOnCBzSJMKw+zXyQYGzXbZB1JtadhBRtloAAmD3rMA= Date: Tue, 22 May 2018 14:06:17 +0000 Deferred-Delivery: Tue, 22 May 2018 14:06:12 +0000 Message-ID: References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:06:54 -0000 Hello Toerless: >=20 > Thanks, Pascal, sorry for the delay, >=20 > Comments inline. >=20 > Version: >=20 > https://raw.githubusercontent.com/anima-wg/autonomic-control- > plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf-anima- > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt >=20 >=20 > Diff to prior version (-14 for Joel Halpern) >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githu= busercon > tent.com/anima-wg/autonomic-control- > plane/8b4436edaa720eadb5839120400fd1e89d3289b0/draft-ietf-anima- > autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > 14.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic- > control-plane/2ae8f47399ae0d0811cb45209186d01f9e0d3077/draft-ietf- > anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > 14.txt >=20 > Will commit as -14 when i am through with the other -13 feedback. >=20 > Cheers > Toerless >=20 >=20 > On Mon, Feb 26, 2018 at 05:25:58PM +0000, Pascal Thubert (pthubert) > wrote: > > Reviewer: Pascal Thubert on behalf of IOT-DIR; > > > > I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomi= c- > control-plane-13. > > > > These comments were written primarily for the benefit of the INT and OP= S > Areas Directors from the IoT perspective. Document editors and shepherd(s= ) > should treat these comments just like they would treat comments from any > other IETF contributors and resolve them along with any other Last Call > comments that have been received. For more details on the IoT Directorate= , > please see https://datatracker.ietf.org/group/iotdir/about/ and for > Directorates in general please see > https://www.ietf.org/about/groups/directorates/. > > > > > > I'll be away for the next 2 weeks and could not finish the review in t= ime for > this heavy document, but at least I made it through till the RPL section.= In the > interest of time, let me share what I already have. > > > > > > > > Summary > > > > ------------- > > > > The summary of the review is that the document is Ready for Publication= , > with comments. > > > > > > > > > > > > Major comments > > > > ------------------------ > > > > > > > > - " in-band" and "out of band network " > > > > should be defined since it is fundamental to understand that the ACP > > takes place in the same physical links as the data plane, as opposed > > to dedicated management ports (correct?); >=20 > Good point, done. (got a bit too long to paste here, so pls. check diff). >=20 > > > > - Section 3; the IOT certainly could use an ACP. It would be u= seful to > scope the feature that is proposed in this document, whether it is compat= ible > of not with constrained environments, whether it needs adaptations, point= on > Michael's enrollment draft. It would also be useful to indicate whether t= he > ACP works between L3 bridges, IOW whether ACP operates the same (over IP) > regardless of the packet forwarding layer in the data plane; >=20 > Not sure i understand the "point on Michaels enrollment draft". >=20 > I am happy to add pointers to variations of ACP design aspects for > informational purposes to show that/how it can be modified, but Michaels > drafts i think are all variation of the BRSKI design, so the ACP would be > completly unaffected by them, right ? >=20 [PT>] I guess you're right there > Wrt. constrained devices and L2. I didn't want to touch section 3 for wha= t you > suggested because that really a very formulistic section going back to th= e > charter 1 justifications of ANIMA and matched with the three numbered us= e > case explanations in the introduction. >=20 [PT>] OK > Instead i wrote text at the end of the introduction, now section 1.1, Thi= s got > longer than i hoped, but it was really a big missing piece to pitch the A= CP and > give early on context for implementers and reminding of the charter goal = of > reusing the best available existing protocols/function. [PT>]=20 [PT>] I read it, very cool. >=20 > The text got longer specifically also because i did not want to fall into= the trap > of making claims whether or not ACP is applicable to specific IOT network= s or > (even worse) assuming IOT is always constrained. Therefore mentioning of = OT > networks (IMHO big part of IOT, and often totally non-constrained), > explanation of why RPL, and at the end a statement about constrained > environments. There is also a new paragraph in 10.8 about TCP/TLS vs. > CoAP/DTLS as a possible constained environment variant in the future. >=20 > > - " Inside the ACP VRF, each node sets up a loopback interface = with its > ULA IPv6 address" > > This is the first time, IPv6 is discussed; would have been nice to > > introduce that the Node has IPv6, that it needs a ULA and that ACP > > assigns it. This discussion could be done in conjunction with the > > comment above; >=20 > Actually, section 1. introduction already mentions that the ACP provides > IPv6 and that the stable-connectivity document describes how to interoper= ate > with IPv4 only OAM. >=20 > I added to the new 1.1 section (see above) the following paragraph, which= i > hope is a useful context setting and pitch: >=20 > The ACP uses only IPv6 to avoid complexity of dual-stack ACP operation= s > (IPv6/IPv4). Nevertheless, it can without any changes be integrated into = even > otherwise IPv4-only network devices. The data-plane itself would not need= to > change, it could continue to be IPv4 only. For such IPv4 only devices, th= e IPv6 > protocol itself would be additional implementation footprint only used fo= r the > ACP. [PT>] OK >=20 > > - About "The ttl > > parameter SHOULD be 3.5 times the period so that up to three > > consecutive messages can be dropped before considering an > > - announcement expired. " > > > > This is the only discussion on the ttl field of the M_FLOOD. Though its > meaning is quite obvious, the behavior associated to it should be defined= . >=20 > Added: >=20 > When a service announcer > using these parameters unexpectely dies immediately after sending the > M_FLOOD, receivers would consider it expired 210 seconds later. When a > receiver tries to connect this dead service earlier, it will experience a= failing > connection and use that as an indication the service is dead and select > another instance of the same service instead. >=20 [PT>] OK > > - "In the above (recommended) example the period of sending of = the" > > Is this RECOMMENDED IOW normative?? >=20 > Hmmm... Sure, why not. Less guessing/experiementation for this. > Modified to RECOMMENDED. [PT>] OK >=20 > > - Text P 25 says "At this time in the lifecycle of ACP nodes, i= t is unclear > whether it > > is feasible to even decide on a single MTI (mandatory to implement) > > security association protocol across all ACP nodes" > > but then P27 "It MUST support ESP > > with AES256 for encryption and SHA256 hash and MUST NOT permit > weaker > > crypto options." > > > > and then " A baseline ACP node MUST support IPsec natively and MAY > support IPsec > > via GRE. A constrained ACP node MUST support dTLS. ACP nodes > > connecting constrained areas with baseline areas MUST therefore > > > > support IPsec and dTLS." > > > > Seems that text P25 should go? >=20 > P27: An ACP node supporting native IPsec MUST use IPsec security setup vi= a > IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for > encapsulation. It MUST support ESP... (parameters). >=20 > clarified to: >=20 > P27: An ACP node that is supporting native IPsec MUST use IPsec security > setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses us= ed for > encapsulation. It MUST then support ESP... (parameters). >=20 > Also: >=20 > ACP nodes supporting ACP via GRE/IPsec MUST support IPsec security setup.= . >=20 > clarified to: >=20 > An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec > security setup.. >=20 [PT>] OK > Aka: P25 is correct, there is no single MTI. 6.7.3 defines the actual > requirement for two different profiles: "baseline ACP node" and "constrai= nted > ACP node". > The two requirements in P27 are only conditional MUSTs defining the detai= ls > of the IPsec profiles assuming a node does support IPsec or IPsec/GRE. >=20 > Let me know if this is still unclear, and if so, how you would suggest to= make it > better readable. [PT>] Someone else need to do it now I'm biased >=20 > > - "Use-ULA: For loopback interfaces of ACP nodes, we use Uniq= ue > Local > > > > Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] > > > > with L=3D1]." > > > > This needs to be more crisp. ULA is defined in RFC 4193 but the term > > ULA-Random is not. I think you mean that 3.2.2. of RFC 4193 is the > > way addresses are formed, if so please say so. The best practice RFC > > 8064 recommends use of RFC 7217. I understand that privacy is not a > > concern but does it hurt? Anyway please point at section 6.10 and > > 6.11.1.11 >=20 > The term "ULA-Random" was used in the discussions on ANIMA mailing list r= e. > ULA, so admittedly i didn't check that the term as it stands is actually = not > defined/used in rfc4193 - but its just meant to imply ULA with L=3D1, not= hing > more. I've removed the use of ULA-Random from the text and just refer now > to 4193 with L=3D1 (also pointing to 3.1. of rfc4193 defining L). >=20 [PT>] cool; > I have also added a note that the hash uses our own ACP definition instea= d of > rfc4193 3.2.2. >=20 > Paragraph is now: >=20 > Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local > Addresses (ULA), as defined in with L=3D1 (as = defined > in section 3.1 of ). Note that the random hash = for > ACP loopback addresses uses the definition in a= nd > not the one of section 3.2.2. >=20 > 8064/7217 are irrelevant here if i understand it correctly because we def= ine > the addressing scheme for anything following the ULA prefix ourselves for > ACP addresses. Let me know if i do misunderstad what you where trying to > suggest re. 8064/7217. [PT>]=20 [PT>] I guess I missed that you defined the IID. >=20 > > - " > > RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with > multicast support". Implementations should support also other modes. > > > > Note: Root indicates mode in DIO flow" > > > > Why "should" ? there is no much point supporting the other modes is > there? Section 6.11.1.13 says that SRH is not used so this is inconsisten= t. You > only need MOP 2 or 3, 3 is you do multicast which at the moment does not > appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 > which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). >=20 > Probably a transcription error on my side when i took your RPL summary an= d > wrote it down. Fixed according to above. >=20 [PT>] cool >=20 > > - "The lack of a RPI (the header defined by [RFC6553]), means= that the > > data-plane will have no rank value that can be used to detect loops. > > As a result, traffic may loop until the TTL of the packet reaches > > zero. " > > > > Since we have reliable links and no stretch (section 6.11.1.7), loops > > should be exceedingly rare. It could be recommended to send the DIOs > > 2-3 times to inform children when losing the last parent. Note that > > the technique in section "8.2.2.6. Detaching" of RFC 6550 should be > > favored over that in section "8.2.2.5. Poisoning" because it allows > > local connectivity. Also, It should be said that a node should select > > more than one parent, at least 3 if possible, and send DAOs to all of > > then in parallel. This provides multi >=20 > Not sure why your paragraph ends apruptly, buts its also in the archive, = so its > not a mistake on my email end. Hopefully nothing significant missing. [PT>]=20 [PT>] Dunno what happened. Selecting multiple parents enables NECM back. Co= uld be useful. >=20 > I have replaced the suggestive text that followed your above quoted text = in > the draft: >=20 > There are a variety of heuristics that can be used to signal from the > data-plane to the RPL control plane that a new route is needed. >=20 > With a hopefuly correct transcription of your suggestion: >=20 > > Since links in the ACP are assumed to be mostly reliable (or have link > layer protection against loss) and because there is no stretch > according to , loops should be > exceedingly rare though. > > There are a variety of mechanisms possible in RPL to further > avoid temporary loops: DIOs SHOULD be sent 2...3 times to inform childr= en > when losing the last parent. The technique in > section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2= .2.5. > (Poisoning) because it allows local connectivity. Also, nodes SHOULD se= lect > more than one parent, at least 3 if possible, and send DAOs to all > of then in parallel. >=20 [PT>] Yes, I'm good with all this. > > - "ACP nodes MUST perform standard IPv6 operations across ACP > virtual > > interfaces including SLAAC (Stateless Address Auto-Configuration - > > RFC4862])" > > > > They may actually prefer Optimistic DAD RFC 4429 since address duplicat= ion > is highly improbable as long as you . >=20 > Added: >=20 > "Optimistic Duplicate Address Detection (DAD)" according to > is RECOMMENDED because the likelyhood = for > duplicates between ACP nodes is highly improbable as long as > the address can be formed from a globally unique local assigned > identifier > (e.g.: EUI-48/EUI-64, see below). >=20 [PT>]=20 [PT>] I'm unsure what your recommendation for the interface ID is thus the = discussion on RFC 7217. Note: I have only one slight comment left below: > > Minor comments > > > > ------------------------ > > > > > > > > > > > > - About "[RFC7575] defines the fundamental ... " > > > > for readability, it may be nicer to indicate the title of an RFC when > > it is referenced first; e.g. the text above would become > > > > " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines > the fundamental ... >=20 > Ok, i am punting this one for now to RFC editor after playing around a bi= t with > the XML options - and not being satisfied... and having references for 50= RFCs > in the doc: >=20 > [RFC Editor: Question: Is it possible to change the first occurrances = of > [RFCxxxx] references to "" [RFCxxxx] ? the XML2RFC format d= oes > not seem to offer such a format, but i did not want to duplicate 50 first > references to be duplicate - one reference for title mentioning and one f= or > RFC number.] >=20 > If RFC editor comes back and can't do this easier than i can in XML, i'll= try to > go through the chores when doc is in RFC editor queue. >=20 > > - about "or network plane (there is no well-established name f= or this)" > > > > The term network plane is not used again in the document. This text may= go > away. >=20 > Done. >=20 > > You may consider using "security and transport substrate" instead, sinc= e it is > used elsewhere in the document. >=20 > "autonomic communications fabric" =3D ACP including ACP GRASP (ACP GRASP > provides discovery etc..). "security and transport substrate" =3D=3D the = parts of > ACP used by "ACP GRASP" (aka: The secure IPv6 forwarding of ACP). >=20 > Subtle difference. >=20 > > Also, please be consistent on whether you use hyphen or not and use > > that globally, e.g. for the above, and pane like in "forwarding plane" > > or "out of band network "; >=20 > Fixed up "out of band" (no hyphens) and "in-band" (with hyphen). > Not sure why but this is what MS word spelling checker suggested to me. R= FC > editor will override if these are not the best choices. >=20 >=20 >=20 > > - "data-plen" > > Typo? >=20 > Done >=20 >=20 > > - "OAM applications ("Operations Administration and Management)= " > > > > Consider using "Operations Administration and Management (OAM) > applications " instead; same goes for SDN, ASA, VRF, etc... >=20 > Ok. Tried to fix up all the instances i could find. >=20 > > - " MIC: "Manufacturer Installed Certificate". Another wor= d not used > in this document to describe an IDevID." > > > > MIC is not used in the document, maybe inform of this equivalence in th= e > IDevID definition instead; same goes for SUDI. Note that UDI is use just = once > and may not need an entry here. >=20 > The definitions of those non-necessary terms are there to help others who > like me start out not being security experts and are confused about those > equivalent or related terms. >=20 > I specifically didn't want to include discussions about these terms in th= e > definitions that are relevant (eg: IDevID) so as not to clobber up that t= ext. > Instead, readers would just look up those redundant terms when they are l= ike > me initially confused about them. >=20 > > - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy > Networks\". The routing protocol used in the ACP." > > > > Maybe point on [RFC6550]? >=20 > Done >=20 > > - "Connecting over non-ACP Layer-3 clouds initially requires a = tunnel > between ACP nodes." > > > > I understands that it is one tunnel between each pair of adjacent ACP > > nodes, correct? I read "a tunnel" as an end-to-end tunnel, which > > sounds different >=20 > Changed to: >=20 > Connecting over non-ACP Layer-3 clouds requires explicit configuration= . > See . This may be automated in in = the > future through autodiscovery mechanisms across L3. >=20 >=20 > > - "ACP relies on group security" > > > > Add "The" >=20 >=20 > Done >=20 > > - "An ACP node MUST have keying > > material consisting of a certificate (LDevID), with which it can > > cryptographically assert its membership in the ACP domain and trus= t > > anchor(s) associated with that certificate with which it can verif= y > > the membership of other nodes (see Section 6.1.2)." > > > > This is convoluted. Could you make it 2 sentences? >=20 > Fixed to: >=20 > The ACP relies on group security. An ACP domain is a group of nodes t= hat > trust each other to participate in ACP operations. To establish trust, e= ach ACP > member requires keying material: An ACP node MUST have a certificate > (LDevID) and a trust anchor (TA) consisting of a certificate (chain) used= to sign > the LDevID of all domain members. The LDevID is used to cryptographically > assert membership in the ACP domain, the TA to verify the membership of > other nodes in the ACP domain (see ). >=20 > > - " Note: LDevID ("Local Device IDentification") is the term u= sed to > > indicate a certificate that was provisioned by the owner of a > > node as opposed to IDevID ("Initial Device IDentifier") that may has > > been loaded on the node during manufacturing time. Those IDevID do > > not include owner and deployment specific information to allows > > autonomic establishment of trust for the operations of an ACP domain (e= .g.: > > between two ACP nodes without relying on any third party)." >=20 > > LDevID was already defined in the terminology. This text may move there= or > go away. >=20 > Gone. I added the note that LDevID can not be used directly for ACP to th= e > terminology definition of IDevID. >=20 > > - " This document uses the term ACP in many places where its > reference > > document use the word autonomic." > > > > Add [RFC7575] after "reference document" >=20 > Done. >=20 > > - " "routing-subdomain" is the autonomic subdomain that is u= sed to > > calculate the hash for the ULA prefix of the ACP address of the node." > > > > Do you mean ULA suffix? >=20 > No, the Global ID. Fixed. >=20 > Actually, i also sumbled across this: >=20 > RFC4193 uses "Prefix" for the first 7 bits of a ULA address, but we have= used > use the term ULA prefix to refer to the first 48 bits of a ULA address, s= o i've > clarified this more in the terminology. >=20 > > - " o If the node certificates indicate a CDP (or OCSP) the= n the peer's > > certificate must be valid according to those criteria. e.g.: OCSP > > check across the ACP or not listed in the CRL retrieved from the CDP." > > > > Please define CDP and OSCP, and/or reference a RFC is possible. >=20 > Done. Using RFC5280. Hope thats correct, otherwise IESG SEC review should > help. >=20 > > - "enrolment" > > Typo >=20 > Fixed. >=20 > > - "This can > > use a single GRASP M_FLOOD message as shown in above example." > > Actually the example is now below. Please reference the figure. >=20 > Done. Actually its still "above", or i am heavily confused. >=20 > > > > - "The protocol could for example could have been" > > > > Typo >=20 > Fixed. >=20 > > - "if the IPsec connecting" > > > > Typo? >=20 > More like sentence structure was strange. >=20 > Fixed to: >=20 > "Even if the IPsec connection from Bob succeeded, Alice might prefer ano= ther > secure protocol over IPsec" >=20 > > - "ACP wide service discovery" > > ACP-wide >=20 > Fixed. >=20 > > - "if the IPsec connecting In most other solution > > designs such distributed discovery does not exist at all or was added > > as an afterthought and relied upon inconsistently" > > > > Consider removing or rephrasing : ) >=20 > Removed: >=20 > Sentence wasn't that bad, but easier removed instead of trying to justify > negative observations about reality without being called out to provide e= ven > more proof. >=20 > > > > - Maybe consider moving the discussion on multicast P29 -30 to = annex? > Why Multicast is not used is an interesting discussion but not critical f= or the > protocol operation. >=20 > Done. >=20 > > - "it is not quite clear yet what exactly the implications ar= e > > to make GRASP flooding depend on RPL DODAG convergence and how > > difficult it would be to let GRASP flooding access the DODAG > > information" > > > > Let's chat then. There's work on reliable multicast for RPL using BIER. >=20 > Yeah if i would just get around to that ;-) >=20 > For now moved together into informative section together with te multicas= t > discus. >=20 > > - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the AC= P is the > > security and transport substrate for the GRASP instance run inside the > > ACP ("ACP GRASP"). " > > > > "running" inside the ACP? Maybe rephrase more globally? > > >=20 > This instance of GRASP runs across the ACP secure channels.. >=20 > > - "OAM protocols no not require IPv4: The ACP may carry OAM " > > Typo no->do >=20 > Fixed. >=20 > > - "Consider a network that has multiple NOCs in different loc= ations. > > Only one NOC will become the DODAG root. Other NOCs will have to send > > traffic through the DODAG (tree) rooted in the primary NOC." >=20 > > A figure would help. I remember all the discussions we had about > > setting the prf bits in remote NOCs >=20 > Sorry. A bit low on cycles right now. Hopefully i'll get around to it lat= er. > Created a wish list entry in changelog. >=20 > > - "RPPL." > > Typo >=20 > Fixed. >=20 > > - "Administrative Preference ([RFC6552], 3.2.6 " > > > > The section is correct but that is RFC 6550. >=20 > Done >=20 > > > > - "This is a standard issue > > with tunneling, not specific to running the ACP across it." > > Do you really mean Standard or would Classical work better? >=20 > This is an issue of tunnels, not an issue of running the ACP across a tun= nel. [PT>]=20 [PT>] Sure but I was pointing at the word "standard", probably ill-chosen i= n a standard doc... >=20 > > - "Even though loopback interfaces where originally d" > > Typo Where -> were >=20 > Done. >=20 > > - Section 3, 4, 9 and 10 may move to Annex (by moving the secti= on after > the tag) since they are not normative and do not contribute= to > the understanding of the protocol. This way there should not be a need to > indicate normative in other sections. >=20 > Sections 3, 4 and 9 are fairly short and the flow of the document depends= on > them being in their particular location. >=20 > Section 10 could go into an appendix, but it makes not a lot of differenc= e, but > past experience has shown that Annex text is a lot less likely to be read= given > how the RFCs are structured. > We had 10 in Annex and moved it up for exactly that reason. >=20 > > - Well Noted that Section 14 Will be removed/. >=20 > > Sorry for being interrupted here, >=20 >=20 > Thanks you so much! >=20 [PT>] My pleasure, Take care; Pascal From nobody Tue May 22 13:55:59 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756C12D886; Tue, 22 May 2018 13:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksFhaGrQFFQL; Tue, 22 May 2018 13:55:49 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 48D80124D37; Tue, 22 May 2018 13:55:49 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id f189-v6so9359217pfa.7; Tue, 22 May 2018 13:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YlS7QW+n6C5qCDKyh7VWOujrZ9Js1Ysx3XsdyJWvmo8=; b=Qc8eEzxL/SJ/ReBHGGFm9/J4vOySEhox4uYYUQU0696YLFjWmzpJtnOh3htSVj+62a gpKDAmpORD9ROQdS6EnRMip6LKgtG4vhDNmuXvfvq+cV3fwLStu3llTsiYkE/ysGJeh0 uNQidPHQkWJv6yMyC9glIbrT/Q8XY2+EJ+m4wR/7nWCbZauW8pnbYyh5dF7CGPwo+4RC Pj6B6EeKVz0uqF/urD6mo6GdUm51uIlhlJVYsZMt6GZ6cJtUnGw/N+D0DXqFdleUkQOC BBU59i5FzSve/8PhOcqfGo6IEE+OgvjKS44nEnuVgNkT+k2ljICej1ogXZoi9WyD9A3l S0/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YlS7QW+n6C5qCDKyh7VWOujrZ9Js1Ysx3XsdyJWvmo8=; b=jLOJoTfOLPBd1JRbtcbUYSnnkRAYf6ZjdvYR+wIN7qeDCn3LH8ChBDK7zrBBlVmp+F 8vmilUsWAWcwK4hUl14BnXjUAtDJTYCwXhVHZ326lCe3XUapGCNkIzqVhcI/CJUIe9yL gTp+NNGolel18K67CO0BbPTMZvuhkEMgxiqbtOC32DiVhyIC7e0VE8HQEsVyKHhm9j85 5iNriZqoPJIwiFNLr5C0JAfzA9azctCdtppvM5mh9XRucnfgiwkaR/o/zTg0QtM+PZYH fIZR32oGYkZ1wXxeuI4Xe7vL4PVb62+ZLTArG4YNxoA4kU+JGKUzqN6E/KySf5pMClNt ba0Q== X-Gm-Message-State: ALKqPwfNQXUKls7KDeCqFI0km1n7/oRFvqDrfMZ5Uw/+HWBo9ExW5Pc3 nPgoYrpmz5AC8pt5ht3dfQ19Bw== X-Google-Smtp-Source: AB8JxZrv14ZI3C/oh+zA4w6c0VZ0TzOvCm243FK5lkoWOjPBt7LJmU1bwFUHsR+0c9Ma9aIyEsXixw== X-Received: by 2002:a62:b509:: with SMTP id y9-v6mr34367pfe.121.1527022548495; Tue, 22 May 2018 13:55:48 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 131-v6sm28768795pfa.128.2018.05.22.13.55.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 13:55:47 -0700 (PDT) To: "Pascal Thubert (pthubert)" , Toerless Eckert Cc: "ops-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" , iot-dir , "int-dir@ietf.org" References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> <20180510060636.gspxrd4d7duaksc7@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <4823a9d3-9ea9-4403-3db8-8e34bb159fd6@gmail.com> Date: Wed, 23 May 2018 08:55:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Int-dir] RFC7217 [was An IOT DIR review of draft-ietf-anima-autonomic-control-plane] X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 20:55:51 -0000 On 23/05/2018 02:06, Pascal Thubert (pthubert) wrote: > Hello Toerless: ... > >>> - "ACP nodes MUST perform standard IPv6 operations across ACP >> virtual >>> interfaces including SLAAC (Stateless Address Auto-Configuration - >>> RFC4862])" >>> >>> They may actually prefer Optimistic DAD RFC 4429 since address duplication >> is highly improbable as long as you . >> > >> Added: >> >> "Optimistic Duplicate Address Detection (DAD)" according to >> is RECOMMENDED because the likelyhood for >> duplicates between ACP nodes is highly improbable as long as >> the address can be formed from a globally unique local assigned >> identifier >> (e.g.: EUI-48/EUI-64, see below). >> > [PT>] > [PT>] I'm unsure what your recommendation for the interface ID is thus the discussion on RFC 7217. Privacy is not really an issue here. Firstly we're talking about devices, not people. More important, we're talking about ULA addresses that will not be visible outside the domain covered by the ACP. So the old-fashioned technique of using modified EUI-64 would be safe, and there is no real need to use RFC7217. However, since RFC8064 recommends RFC7217 for all SLAAC nodes, and the ACP uses SLAAC, RFC7217 is automatically recommended by the existing standards. I don't think we should mention EUI-64. Brian From nobody Thu May 24 00:15:49 2018 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047EB1242F7; Thu, 24 May 2018 00:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djLbGvvjrXiC; Thu, 24 May 2018 00:15:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE771242EA; Thu, 24 May 2018 00:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4496; q=dns/txt; s=iport; t=1527146144; x=1528355744; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K7rLzzKsD9XDP2hTzXLEr0SRKAxH5/3UD68PoRKbRWY=; b=XV3mHbf21GcXWz3oXdUEq+Fr6O4vhy+OUAHOhb2x2MA67WI1yZB4bunv DFxoGvrbSG2vFtmbxUQ2Nvo3C6a7HuxdqCz5eZc1U8zhgEsYRIckVTWkQ IRfTK7zZWw8uiW5rbL7idWDJ6wn8k2ITXXiV9GyTDa35B8GhjDlNydAkD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAQBNZgZb/4gNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMVL2J9KAqDbYgEjGSBWIEwhwWMNIF4CyOESQIXgXMhNBg?= =?us-ascii?q?BAgEBAQEBAQJsHAyFKQYjEUUQAgEIGgImAgICHxEVEAIEAQ0FCYMZAoFnAxU?= =?us-ascii?q?PqxiCHIcQDYErgXyBCYctgVQ/gTMMgig1gk83CwIBgUkWF4JpMIIkAoc7hg+?= =?us-ascii?q?KZSwJAotYgn+NA4owhioCERMBgSQBHDiBUnAVZQGCGAmLB4U+bwGMcIEYAQE?= X-IronPort-AV: E=Sophos;i="5.49,436,1520899200"; d="scan'208";a="389683540" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2018 07:15:43 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4O7Fh2m028866 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 May 2018 07:15:43 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 May 2018 03:15:42 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 24 May 2018 03:15:42 -0400 From: "Eric Vyncke (evyncke)" To: Zhen Cao , "int-dir@ietf.org" CC: "draft-ietf-intarea-provisioning-domains.all@ietf.org" , "int-area@ietf.org" Thread-Topic: Intdir early review of draft-ietf-intarea-provisioning-domains-01 Thread-Index: AQHT0GLAHdb9eKfkfEeE5UjHZA703aQ/IdoA Date: Thu, 24 May 2018 07:15:42 +0000 Message-ID: References: <152332006565.13513.6925533541817459571@ietfa.amsl.com> In-Reply-To: <152332006565.13513.6925533541817459571@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.161.47] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Intdir early review of draft-ietf-intarea-provisioning-domains-01 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 07:15:47 -0000 Wmhlbg0KDQpUaGFuayB5b3UgYWdhaW4gZm9yIHRoZSByZXZpZXcsIHRoZSBhdXRob3JzIGFyZSBm aW5hbGl6aW5nIHRoZSByZXYtMDIgd2hpY2ggaW5jbHVkZXMgY2hhbmdlcyBiYXNlZCBvbiBhbGwg eW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNCk9u IDEwLzA0LzE4IDAyOjI3LCAiWmhlbiBDYW8iIDx6aGVuY2FvLmlldGZAZ21haWwuY29tPiB3cm90 ZToNCg0KICAgIFJldmlld2VyOiBaaGVuIENhbw0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5IHdp dGggSXNzdWVzDQogICAgDQogICAgSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2 aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZXNlDQogICAgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWENCiAgICBEaXJlY3Rv cnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkcyBzaG91bGQgdHJlYXQgdGhlc2UgY29t bWVudHMNCiAgICBqdXN0IGxpa2UgdGhleSB3b3VsZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBv dGhlciBJRVRGIGNvbnRyaWJ1dG9ycw0KICAgIGFuZCByZXNvbHZlIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgaGF2ZQ0KICAgIGJlZW4gcmVjZWl2ZWQu IEZvciBtb3JlIGRldGFpbHMgb2YgdGhlIElOVCBkaXJlY3RvcmF0ZSwgc2VlDQogICAgPGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS5odG1sPi4NCiAgICANCiAgICBUaGFuayB0 aGUgYXV0aG9ycyBmb3IgdGhlIHdvcmsuICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgd2F5IGZv ciBhIGhvc3QgdG8NCiAgICBwZXJmb3JtIGluZm9ybWVkIHNlbGVjdGlvbiBhYm91dCB0aGUgUHJv dmlzaW9uaW5nIERvbWFpbnMgKFB2RHMpIG9mIGl0cyBhY2Nlc3MNCiAgICBuZXR3b3JrcywgYnkg ZXh0ZW5kaW5nIHRoZSBSQSB3aXRoIHRoZSBkZWZpbmVkIFB2RCBJRCBvcHRpb24uDQogICAgDQog ICAgVGhlIGRvY3VtZW50IGlzIHF1aXRlIHJlYWR5IGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIG9w dGlvbiBhbmQgYXNzb2NpYXRlZA0KICAgIGFjdGlvbnMgcmVxdWlyZWQgYnkgdGhlIHJvdXRlciBh bmQgaG9zdC4gICBIb3dldmVyLCBzb21lIGNsYXJpZmljYXRpb24gd2lsbCBiZQ0KICAgIGhlbHBm dWwgYW5kIG5lY2Vzc2FyeSwgc2VlIGJlbG93Lg0KICAgIA0KICAgIDEuICBBYm91dCB0aGUgJ2lu Zm9ybWVkIHRyYW5zcG9ydCBzZWxlY3Rpb24nLiAgVGhlIGFic3RyYWN0IG1lbnRpb25zIHRoYXQg Ig0KICAgIFRoaXMgYWxsb3dzIGFwcGxpY2F0aW9ucyB0byBzZWxlY3Qgd2hpY2ggUHJvdmlzaW9u aW5nIERvbWFpbnMgdG8gdXNlIGFzIHdlbGwgYXMNCiAgICB0byBwcm92aWRlIGNvbmZpZ3VyYXRp b24gcGFyYW1ldGVycyB0byB0aGUgdHJhbnNwb3J0IGxheWVyIGFuZCBhYm92ZS4iICwgYnV0DQog ICAgSW50cm9kdWN0aW9uIHNheXMgdGhhdCAiLi53aGVuIGNob29zaW5nIHdoaWNoIFB2RCBhbmQg dHJhbnNwb3J0IHNob3VsZCBiZQ0KICAgIHVzZWQuIiAgICBGaXJzdCBvZiBhbGwsIHRoaXMgaXMg c29tZWhvdyBub3QgYWxpZ25lZCwgYXJlIHlvdSBnb2luZyB0byBwcm92aWRlDQogICAgaW5mb3Jt ZWQgc2VsZWN0aW9uIG9mIHRoZSB0cmFuc3BvcnQgY29uZmlndXJhdGlvbiBvciB0aGUgdHJhbnNw b3J0IHByb3RvY29scw0KICAgIChtcHRjcC90Y3AvcXVpYykgdGhlbXNlbHZlcz8gIEJ1dCBJIHRo aW5rIGluZm9ybWVkIHRyYW5zcG9ydCBwcm90b2NvbCBzZWxlY3Rpb24NCiAgICBieSB0aGUgUkEg b3B0aW9uIGlzIG5vdCBhIHJlY29tbWVuZGVkIGFwcHJvYWNoLiAgIFNlY29uZCwgSSBzZWFyY2gg dGhlIGRvY3VtZW50DQogICAgYW5kIHRyeSB0byBmaW5kIGFuIGV4YW1wbGUgb2YgdGhlIGluZm9y bWVkIHRyYW5zcG9ydCBjb25maWd1cmF0aW9uIHNlbGVjdGlvbg0KICAgIGJ1dCBmYWlsZWQuICAg SSB0aGluayBpdCB3aWxsIGJlIHF1aXRlIHVzZWZ1bCB0byBpbmNsdWRlIG9uZSBhdCBsZWFzdC4g IEkgdGhpbmsNCiAgICBvbmUgY2FzZSBtYXkgYmUgcmVsZXZhbnQgZm9yIHlvdSB0byBjb25zaWRl ciwgaS5lLiwgb25lIHByb3Zpc2lvbmluZyBkb21haW4gaXMNCiAgICBjb25uZWN0ZWQgd2l0aCBj b25zdHJhaW5lZCBhbmQgbG9zc3kgbGlua3MsIHdpdGggbWluaW1hbCBhdmFpbGFibGUgTVRVLCBz byB0aGF0DQogICAgYSBzbWFsbCBNU1Mgd2lsbCBiZSBpbmNsdWRlZCB3aGVuIHJlc3BvbmRpbmcg VENQIGNvbm5lY3RpbmcgcmVxdWVzdC4gICBPciBtYXliZQ0KICAgIHRoaXMgaGFzIGZ1cnRoZXIg Y29ubmVjdGlvbiB3aXRoIHRoZSB0YXBzIHdnPyAgSSBob3BlIEkgYW0gdGhlIG9ubHkgb25lIHRo YXQNCiAgICBmZWVscyBjb25mdXNlZC4NCiAgICANCiAgICAyLiAgaW4gU2VjdGlvbiAzLjMuMywg cXVvdGVkICJUaGUgZXhhY3QgYmVoYXZpb3IgaXMgVEJEICBidXQgaXQgaXMgZXhwZWN0ZWQNCiAg ICB0aGF0IHRoZSBvbmUgb3Igc2V2ZXJhbCBQdkQgYXNzb2NpYXRlZCB0byB0aGUgc2hhcmVkIGlu dGVyZmFjZSAoZS5nLiBjZWxsdWxhcikNCiAgICB3aWxsIGFsc28gYmUgYWR2ZXJ0aXNlZCB0byB0 aGUgY2xpZW50cyBvbiB0aGUgb3RoZXIgaW50ZXJmYWNlIChlLmcuICBXaUZpKSIsICBJDQogICAg YW0gc3VnZ2VzdGluZyByZXBsYWNlIFRCRCB3aXRoIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50Lg0KICAgIA0KICAgIDMuICBBdXRob3JzIG1heSBjb25zaWRlciB0byBpbmNsdWRlIFJGQzY3 MzEgKG9uZSBmcnVpdCBvZiB0aGUgY29uY2x1ZGVkIG1pZiB3ZykNCiAgICBhcyBhbiBpbmZvcm1h dGl2ZSByZWZlcmVuY2UsIHRoZXJlLCAgaW5mb3JtZWQgRE5TIHJlY3Vyc2l2ZSBzZXJ2ZXIgc2Vs ZWN0aW9uIGlzDQogICAgbWFkZSBwb3NzaWJsZSBieSBleHBsaWNpdCBESENQIGV4dGVuc2lvbiwg d2hpY2ggaXMgcXVpdGUgcmVsZXZhbnQgYW5kIHRoZQ0KICAgIGV4YW1wbGUgY2FzZSBpbiBSRkM2 NzMxIHN0cmVuZ3RoZW5zIHRoZSBjYXNlIGFuZCBwcm9ibGVtIHRoaXMgZG9jdW1lbnQgd2FudHMg dG8NCiAgICBhZGRyZXNzLg0KICAgIA0KICAgIDQuIHNvbWUgbml0cywgb24gUGFnZSA1Og0KICAg ICAgICAgICBBLWZsYWcgICAgICA6ICAgKDEgYml0KSAnLi4uLiAoU2VlIHNlY3Rpb24NCiAgICAg ICAgICA0LjIgb2YgdGFyZ2V0PSJSRkM0ODYxIi8+KS4NCiAgICAobWF5IGF0dHJpYnV0ZSB0byB5 b3VyIHhtbCBmaWxlKQ0KICAgIA0KICAgIA0KICAgIA0KDQo=