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

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-carpenter-limited-domains@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-carpenter-limited-domains-13

The IESG has completed a review of draft-carpenter-limited-domains-13
consistent with RFC5742.

The IESG has no problem with the publication of 'Limited Domains and Internet
Protocols'  as an Informational RFC.

The IESG has concluded that this work is related to work happening in
multiple IETF working groups, but this relationship does not prevent
publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-carpenter-limited-domains/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
I think the review response is appropriate.
It does not say there is no IETF work, on the contrary it implies there is, and says that there is no conflict.

[Ballot comment]
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.

[Ballot comment]
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."

[Ballot comment]
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: , 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 , but this does not prevent publishing." - I wasn't able to figure out what exactly I would fill in for , 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...

[Ballot discuss]
I'm not sure if this is the right conflict review reply as this work seems related to work in the IETF (given all the things listed in section 4). So this would at least indicate that we should maybe reply with option 2. However, maybe we should even discuss option 3 ("...publication could potentially disrupt the IETF work...") as people could potentially try to use this draft as a justification to lower security requirements, even though the document does not explicitly say so.

The document say the following
  "We conclude that it is reasonable to explicitly define limited-domain
  protocols, either as standards or as proprietary mechanisms, as long
  as they describe which of the above scenarios apply and they clarify
  how the domain is defined."
Which seems fine but we should maybe still discuss if this could "disrupt the IETF work".

The document further says:
"  Note that this conclusion is not a recommendation to abandon the
  normal goal that a standardized protocol should be global in scope
  and able to interoperate across the open Internet.  It is simply a
  recognition that this will not always be the case."
but still... maybe worth discussing for a second.