Hi Brian, Thanks for the draft!
I am still concerned about the implications and perceptions this draft might entail. Particularly, I wonder whether this will fracture the Internet (even more) and encourage (even more) protocol ossification by allowing developers and protocol designers to take short cuts that skimp on interoperability and use proprietary solutions instead of investing in open ones (with the vendor lock-in that goes with that). Consider this from the draft: "This section suggests that protocols or protocol extensions should, when appropriate, be standardised to interoperate only within a Limited Domain Boundary. Such protocols are not required to operate across the Internet as a whole." I'm not sure what "not required to operate across the Internet as a whole" means. Specifically, what does it mean for a protocol to not have to "operate" on the whole Internet. I think there are three possible meanings here: 1) using the protocol across the whole Internet isn't useful because it depends on localized information 2) using the protocol on the Internet isn't feasible because there is a lack of global support for it in the Internet 3) using the protocol on the whole Internet isn't correct and leads to bad behaviors. Example of #1 is segment routing, example of #2 is IPv6 extension headers, and example of #3 is extension header insertion. Of the three possibilities, an incorrect protocol is the most problematic. As a litmus test, consider that a Limited Domain implies a security perimeter exists around the domain that would contain the Limited Domain protocol. We know that such perimeters can and will break down at some point so that some day a limited domain protocol will leak into the Internet. That cannot lead to incorrect behavior, this cannot break the Internet! I submit that if a protocol cannot operate *correctly* in the Internet, or would break correct operation of other protocols on the Internet, then it is _not_ an Internet protocol. The part about "interoperate only within a Limited Domain Boundary" is also interesting. I worry vendors make take a lot of license with this. For instance, I have heard one suggestion that mobile operators might "give" each hardware vendor there own slice. So a Limited Domain is defined to contain only one vendor's equipment. Interoperability within a single implementation is rarely an issue! While I don't think it's our business to prevent things like this (network operators can do what they want within their domain), neither do I think we should be encouraging or facilitating it. IETF is fundamentally about standardizing open, interoperable Internet protocols. I guess the consequences of this is that if someone defines a protocol that only operates in a limited domain, then the limited domain itself needs to be clearly defined in normative language. Tom On Tue, Sep 11, 2018 at 8:30 PM, Brian E Carpenter <[email protected]> wrote: > New version, with a first draft of a taxonomy added. > > Discussion welcome. > > Brian + Bing > > -------- Forwarded Message -------- > Subject: I-D Action: draft-carpenter-limited-domains-03.txt > Date: Tue, 11 Sep 2018 20:18:56 -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-03.txt > Pages : 19 > Date : 2018-09-11 > > 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 and emerging solutions, and develops a related > taxonomy. It shows the needs for a precise definition of a limited > domain boundary and for a corresponding protocol to allow nodes to > discover where such a boundary exists. > > > 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-03 > https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-03 > > > 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 > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
