IETF conflict review for draft-carpenter-limited-domains
conflict-review-carpenter-limited-domains-01

Concur with Martin Vigoureux's summary.  The key issue is whether there is a conflict (which there is not).

I fundamentally do not believe that limited *IP* domains exist -- they always sound like a fine idea ("Meh, use RFC1918, it won't leak!", or "We can just insert and remove this additional header at the border - we've got automation to define the border, so it's all safe!"), but in practice Murphy always wins.

I *do* think that limited domains for non-IP protocols can be made to work with some jiggling, and that domain boundaries that require explicit configuration are more dangerous than ones that don't -- but, I've already had this conversation with Brian, and:
a: recognize that the document isn't arguing *for* limited domains and 
b: he had agreed to add some text addressing my concerns (although this doesn't seem to have been done) - Thread: Telechat update notice: <conflict-review-carpenter-limited-domains-00.txt>, Dec 6th).

I started agreeing with Mirja that the  "Related to IETF work, but go ahead" was a better choice, but when I went to go find the actual text, it says: "2. The IESG thinks that this work is related to IETF work done in WG <X>, but this does not prevent publishing." - I wasn't able to figure out what exactly I would fill in for <X>, which leads me to think that a: replying "The IESG thinks that this work is related to general IETF, but this does not prevent publishing.", or, more likely, what Suresh had already proposed.

In my view this presents a good discussion on limited domains, and explains that they are not airtight / foolproof, and so I think that the document deserves to be published - yes, some people will use it as justification for doing [insert bad idea here], but other will read it an go "Huh. Yeah, let's redesign this to be better..." 

Anyway, the view from this soap-box was grand, but I'll climb down now...

As a side note, I would love that Alvaro's statement could be used for this conflict review.

I support Mirja's DISCUSS, and like the specific proposal that Alvaro has selected from Warren's musings.

I agree with Mirja/Warren on the fact that response may not be the best one: the whole document deals with examples on how the limited-domains concept is related to IETF work.

As Warren, I think that a more appropriate response would be along the lines of "The IESG has concluded that this work is related to IETF work, but this relationship does not prevent publishing."

I can't *imagine* saying that this actually conflicts with or disrupts IETF work.  It clearly does talk about IETF work, in many areas, but if we go by that then just about everything the IRTF or Independent streams produce would be "related to work" in some IETF working group or other, and I don't think that's the intent of that response.

So, that said: it might, indeed, be good to say what Álvaro suggests, or even more specifically, as, "The IESG has concluded that this work is related to IETF work in a number of working groups, including HOMENET, LWIG, 6LO, NVO3, SFC, DETNET, ACE, and others, but this relationship does not prevent publishing."  But I would also be fine with the simple "no conflict" response that Suresh suggests.

Another +1 for Alvaro's take on the conflict-review response.

Additional remarks directed at the authors...

Thanks for this though-provoking read!  Please see the note about RFC 6455,
as well as the minor/nit-level comments in the following.

Abstract

   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a particular set of requirements

nit: double-"requirements" is a bit awkward of a construction.

Section 1

   Some people have concerns about splintering of the Internet along
   political or linguistic boundaries by mechanisms that block the free
   flow of information.  That is not the topic of this document, which
   does not discuss filtering mechanisms and does not apply to protocols
   that are designed for use across the whole Internet.  It is only
   concerned with domains that have specific technical requirements.

That sounds right up the alley of RFC 7754...

   the controlled environment.  The same phrase has been used to delimit
   the useful scope of quality of service or security protocols, e.g.
   [RFC6398], [RFC6455].  It is not necessarily the case that protocols

My understanding was that 6455's "controlled environment" was referring
more to the browser's "sandboxing" role for site content than to any
network-layer division.

Section 3

   10.  Inappropriate standards.  A situation that can arise in an

nit: the title of this item seems a bit jarring or out of place in the
context of the other items' titles.

Section 6

   Firstly, if we drew a topology map, any domain -- virtual or physical
   -- will have a well defined boundary between "inside" and "outside".
   However, that boundary in itself has no technical meaning.  What
   matters in reality is whether a node is a member of the domain, and
   whether it is at the boundary between the domain and the rest of the
   Internet.  Thus the boundary in itself does not need to be
   identified, but boundary nodes face both inwards and outwards.
   Inside the domain, a sending node needs to know whether it is sending
   to an inside or outside destination; and a receiving node needs to
   know whether a packet originated inside or outside.  Also, a boundary
   node needs to know which of its interfaces are inward-facing or
   outward-facing.  It is irrelevant whether the interfaces involved are
   physical or virtual.

(oblig. note that this is only in the context of a specific domain, as a
given node may be a mamber of many different domains, and so there would
be many distinctions on "outward-facing" if we bring into play those
other domains.  Perhaps "any given domain" or "any specific domain" in
the first line would reiterate that more strongly.)

   10.  Verify Role.  A node must be able to learn the verified role of
        another node.  In particular, it must be possible for a node to
        find boundary nodes (interfacing to the Internet).

It's not clear to me how universal this "must" is.