IETF conflict review for draft-nachum-sarp
conflict-review-nachum-sarp-01

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-nachum-sarp@ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-nachum-sarp-10

The IESG has completed a review of draft-nachum-sarp-10 consistent with
RFC5742.


The IESG has no problem with the publication of 'Scaling the Address
Resolution Protocol for Large Data Centers (SARP)'
as an Experimental RFC.


The IESG has concluded that this work is related to IETF work done
in the NVO3 and PALS working groups, but this relationship does
not prevent publishing.



This work, like RFC 7342, has its origins in the ARMD working
group. That working group closed down, having produced just one
RFC, for lack of consensus on the need for or direction of any
solutions work.  Since the IETF has no active work in this area, it
cannot be claimed that this draft conflicts with any IETF efforts.
Furthermore, the IETF has published no work on solutions for
scaling ARP.

However, there are existing techniques using IETF protocols that
address the problem that this document seeks to solve and that do
not require this approach. Indeed, an existing deployed solution
places each data center in a separate L2 domain and connects them
with IP.

This, in itself, does not predicate against an experiment with
SARP, but the IESG needs to give clear guidance that other
solutions from within the IETF stable already exist. Therefore, the
IESG requests the ISE to include the following IESG note in this
document if it is published as an RFC.

  The IESG notes that the problems described in RFC 6820 can
  already be addressed through the simple combination of existing
  standardized or other published techniques including Layer 2 VPN
  (RFC 4664), proxy ARP (RFC 925), proxy Neighbor Discovery (RFC
  4389), IGMP and MLD snooping (RFC 4541), and ARP mediation
  for IP interworking of Layer 2 VPNs (RFC 6575).


The IESG would also like the RFC-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:
http://datatracker.ietf.org/doc/conflict-review-nachum-sarp/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-nachum-sarp/

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

Thank you,

The IESG Secretary

[Ballot comment]
The only issue I have is that an IESG statement on an Independent stream document comes with a great deal of subtext, if only due to how rare they are.  It's essentially saying that we think this is a bad idea and you shouldn't do it.  No, it doesn't say that, but that's the subtext.

[Ballot comment]
I would be pushing back on Barry's DISCUSS if RFC 7342 were standards track.  However, I note that even in the case of ZRTP vs. DTLS-SRTP, there's no IESG note on the loser (RFC 6189).

[Ballot comment]
I do not have a strong opinion on the recommended evaluation, but as I read draft-nachum-sarp, I was unable to understand how it works in detail on IPv6 and whether there's an effect to SeND (RFC 3971). The IPv6 details that I was unable to understand relate to whether there are impacts to SLLA and TLLA options in ND.

Finally, the currently recommended IESG note does not mention RFC 4541; at least for IPv6 it would seem to provide some level of optimisation to the problems discussed in the document and in ARMD.

In any case, scaling of very large networks is an issue. What I want to convey is that there are a multitude of solutions that address the situation in their specific ways.

[Ballot discuss]
OK, as you want a discussion, I'll start a discussion -- I had thought not to block things, and we could have discussed it with my "abstain" ballot as well.

I don't have the background to evaluate why this is different, as I didn't follow the ARMD work, but:
There are a great many things that we do in the IETF that could be done in other ways, but someone is proposing what they consider to be a better way to do it.  We used to send email over FTP until we decided that having a dedicated protocol for that was better, and we developed SMTP.  We also have many things that go through the Independent stream that we might think about putting an IESG statement on, but we don't: it's rare, very rare.

So: Why is this document different, in that it merits such a strong statement from the IESG?  Why is it so important in this case that we point out that one could put together a solution from a broad set of existing mechanisms, rather than consider another proposal?  And why does *this* document merit our sticking our collective oar in and putting an IESG statement on it -- why do we get to do that in this case?

If you think an "abstain" ballot comes with subtext (which I didn't intend), consider that an IESG statement on an Independent stream document comes with a great deal of subtext, if only due to how rare they are.  It's essentially saying that we think this is a bad idea and you shouldn't do it.  No, it doesn't say that, but that's the subtext.  I think there needs to be a very strong justification for us to put this statement on there.

And, so, let's discuss.

[Ballot comment]
To be clear, I would be a No-Obj on the RFC 5742 position being proposed. What follows is about the proposed IESG Note.

I realized after Pete's helpful list of the alternatives (which omitted No Position, and that was also a possibility I considered), that I hadn't thought carefully about balloting when we had IESG Notes on conflict reviews.

I searched my IESG mail folder for the last two years, and found two conflict reviews that had IESG Notes (the curious can keep reading past the first "--" to see them).

It seems to me that neither previous conflict review was as robust as the one I'm looking at on this telechat.

I'm not comfortable saying something in an RFC that the community could say at "BOF time"/"WG charter time"/"IETF Last Call time" if anyone did try to take this work forward. For me, I'm balloting on a proof by assertion that I can't evaluate on my own.

Having said that, the threshold of "yes plus no-obj" ballots required for approval on a conflict review is really low, the IESG is well within its rights to add the proposed IESG Note, and me Abstaining won't change a thing, nor should it, so ... I'm Abstaining.

And thanks, Barry, Pete, and Stephen, for helping me choose a more appropriate position for me.

--

The IESG has completed a review of draft-irtf-samrg-common-api-08
consistent with RFC5742.

The IESG recommends that 'A Common API for Transparent Hybrid Multicast'
NOT be published as an Experimental
RFC.

The IESG has concluded that this document extends an IETF protocol in a
way that requires IETF review and should therefore not be published
without IETF review and IESG approval.

IESG NOTE:

Specifically, the document appears to propose incompatible extensions
to URIs: using URIs with unregistered schemes (ip: and sha-2:, for
example) and using registered schemes, such as sip: and reload:, in
ways they were not intended to be used and that deployed software
would not support.

This document seems to be overloading URIs to make them serve as
multicast group names, and overloading URI schemes to serve as
namespaces in the proposed SAM system.  Having identifiers that look
like URIs but have different semantics and are used in different ways,
is a very bad approach and is likely to cause serious breakage as
those identifiers become intermixed with and indistinguishable from
true URIs that applications expect to dereference.

The IESG would also like the IRTF 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:
http://datatracker.ietf.org/doc/conflict-review-irtf-samrg-common-api/

--

The IESG has completed a review of draft-hausenblas-csv-fragment-07
consistent with RFC5742.

The IESG has no problem with the publication of 'URI Fragment Identifiers
for the text/csv Media Type'  as an
Informational RFC.

The IESG has concluded that there is no conflict between this document
and IETF work.

The IESG asks that the following IESG note be attached to the document:
The change to the text/csv media type registration requires IESG
approval, as the IESG is the change controller for that registration.
The IESG has, after consultation with the IETF community, approved the
change, which is specified in Section 5 of this document.

The IESG would also like the RFC-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:
http://datatracker.ietf.org/doc/conflict-review-hausenblas-csv-fragment/

[Ballot comment]
I am abstaining because I haven't the background to agree or disagree with the proposed IESG statement we're asking for.  I have no objection to the conflict review response, but can't object nor no-object to the IESG statement.

Carry on...

[Ballot comment]
During my review of this document I noticed the following issues
that the authors and ISE may want to address.

---

There are some abbreviations that should be expanded on first use.
Note that Section 2 covers many of these terms but comes later in
the document.

---

The term "mobile VM" is introduced without explanation. Indeed, the
idea that a VM might be seamlessly mobile within a data center has
been debated by the IETF and considered unlikely because of problem
of moving and synchronising associated state. The idea of
seamlessly moving a VM between data centers was considered
correspondingly complex. Thus, in using this term, the authors
would be well advised to give a very clear description of their
understanding of a "mobile VM", what features are associated with
such mobility, and under what circumstances such mobility might be
employed.

---

[ARMDStats] seems to be present twice in 6.2

---

This document is positioned as Experimental which is fine. but the
document does not set out the scope of the experiment, how the
experiment might be contained, and how the experiment may be
judged.

---

The term "hypervisor" is used freely without reference or
explanation. This may be a sufficiently new concept that some hints
would be useful.

---

It is not clear what the boxes marked "ACC" in figure 2 represent.
Similarly "Agg" in figure 3.