Re: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt

[<[e-mail]>]

Hi Brian, 

Thank you for the follow-up. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Anima [mailto:[e-mail]] 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, [e-mail] 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:[e-mail]] 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
> >> [e-mail]
> >>
> >> 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: [e-mail]
> >> Reply-To: [e-mail]
> >> To: [e-mail]
> >>
> >>
> >> 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
> >> [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima