Hi Brian, Thank you for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Anima [mailto:[email protected]] De la part de Brian E Carpenter > Envoyé : vendredi 7 juin 2019 07:04 > À : BOUCADAIR Mohamed TGI/OLN > Cc : Anima WG; Liubing (Leo) > Objet : Re: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains- > 07.txt > > Hi Med, > > Finally some feedback on your excellent comments. I only mention points > where I have not accepted your point for the next version. > > > Controlled networks may not even be connected to the Internet. > > I suggest to delete “of the Internet”. > > That's true, but in a sense it's true of every IETF standard. If > people want to use private protocols on a disconnected network, > they are of course free to do so. [Med] My hidden comment was that ** interoperability ** is needed even for closed networks. We cannot imply that such networks should use private protocols because they are not connected to the Internet. However, I prefer to mention this > aspect in the main Introduction, not in the Abstract. [Med] OK, thanks. Hope you will reflect the above comment about interoperability. > > > Intent Based Networking... Commentaire [Med6]: Not sure why this > > is mentioned. IBN is not specific to a service, and hence cannot be > > limited to a single domain. > > I don't agree, not as I understand the discussion so far on intent. > It isn't specific to a service, but it is specific to a human point > of control such as a NOC. (Of course, intent could be nested inside > a higher level intent, i.e. nested scopes.) [Med] The issue I had with that text is it assumes that intent are necessarily for services with limited scopes, while it is completely fine to use it for services with ** global ** reachability. IMHO, IBN is a dimension which is not tied to closed networks. > > > specific tunneling and encapsulation techniques may only be > > usable within a given domain... Commentaire [Med7]: inter-AS VPNs > > are also widely used. > > Sure, that's why it's "may". [Med] Yes, but there is that "only" in your text :-) > > > a limited use requirement potentially adds complexity... > > Commentaire [Med9]: This depends on the design of the protocol > > targeting a managed network. See for example, > > https://tools.ietf.org/html/rfc6947#section-4.2.3 > > Agreed, that's why it's "potentially". > > > 6. Functional Requirements of Limited Domains... > > Commentaire [Med12]: I would remove this part from the draft. > > The authors don't agree. This is not a specification, of course, > but it's intended as a pointer to possible future work. [Med] The concern I had with that text it is drawn from a perspective which may not apply to every controlled/limited domain. I'm working on use cases for which your list is great, e.g., BGP automation within massively scale data centers, but if I would like to run a fleet of drones for some usage, I don't necessarily need a "domain identity" or "role verification" as it the bootstrapping of the drones will be with an external control. > > > A basic assumption is that domains should be created and managed as > > automatically as possible, with minimal human configuration required. > > We therefore discuss requirements for automating domain creation and > > management... > > Commentaire [Med13]: This is depoyment-specific. > > Will reword slightly, but do we really want *new* manual management jobs? [Med] It depends on the "limited domain" scope and purpose. Manual operations can be perfectly fine vs. the heaviness of setting and configuring complex schemes. > > > Clearly, the boundary of a limited domain will almost always also act > > as a security boundary... > > Commentaire [Med15]: If such nodes is allowed by the structure of the > limited domain. > > Some closed networks may not hosts such nodes. > > Yes, this is the argument I've had with the BRSKI people about running > BRSKI with no access to the Internet. But that's why we say "almost > always". > [Med] Yeah, but the text assumes that such "role" is always present in a limited domain. Please consider tweaking the text. Thanks. > Thanks and regards. There will be a new version. > > Brian Carpenter > > On 25-Apr-19 21:31, [email protected] wrote: > > Hi Brian, > > > > FWIW, you may find some comments to this I-D at: > > > > * pdf: https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/draft-carpenter-limited-domains-07-rev%20Med.pdf > > * doc: https://github.com/boucadair/IETF-Drafts- > Reviews/raw/master/draft-carpenter-limited-domains-07-rev%20Med.doc > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Anima [mailto:[email protected]] De la part de Brian E > Carpenter > >> Envoyé : mardi 16 avril 2019 04:43 > >> À : Anima WG > >> Cc : Liubing (Leo) > >> Objet : [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt > >> > >> Hi, > >> > >> Another update following recent comments. The main changes were > >> moving the taxonomy to an appendix, some new examples, and editorial > >> improvements. Please send any new comments that you may have to > >> [email protected] > >> > >> At the moment the authors plan to submit this draft soon to the > >> Independent Submissions stream, but we'd be glad to hear any > >> alternative suggestions. > >> > >> Regards > >> Brian + Bing > >> > >> -------- Forwarded Message -------- > >> Subject: I-D Action: draft-carpenter-limited-domains-07.txt > >> Date: Mon, 15 Apr 2019 19:22:48 -0700 > >> From: [email protected] > >> Reply-To: [email protected] > >> To: [email protected] > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Limited Domains and Internet Protocols > >> Authors : Brian Carpenter > >> Bing Liu > >> Filename : draft-carpenter-limited-domains-07.txt > >> Pages : 25 > >> Date : 2019-04-15 > >> > >> Abstract: > >> There is a noticeable trend towards network requirements, behaviours > >> and semantics that are specific to a limited region of the Internet > >> and a particular set of requirements. Policies, default parameters, > >> the options supported, the style of network management and security > >> requirements may vary. This document reviews examples of such > >> limited domains, also known as controlled environments, and emerging > >> solutions, and includes a related taxonomy. It then briefly > >> discusses the standardization of protocols for limited domains. > >> Finally, it shows the needs for a precise definition of limited > >> domain membership and for mechanisms to allow nodes to join a domain > >> securely and to find other members, including boundary nodes. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-carpenter-limited-domains-07 > >> https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains- > 07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-07 > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> _______________________________________________ > >> Anima mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
