Subject: [Gen-art] Gen-art LC review: draft-mahalingham-dutt-dcops-vxlan-08

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Mar 2014 16:35:06 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-malingham-dutt-dcops-vxlan-08
Reviewer: Robert Sparks
Review Date: 20 Mar 2014
IETF LC End Date: 24 Mar 2014
IESG Telechat date: not yet scheduled for a telechat

Summary: This document is not ready for publication as an Experimental 
IETF Stream RFC

(Apologies to the everyone on the long list of authors - this review is 
primarily about process, but I do have some comments for you below.)

To the AD and shepherd: Why is the proposed status Experimental and not 
Informational?
The text in the shepherd writeup provides a strong motivation for 
Informational, but not Experimental.

I understand the concern that led to the inclusion of the last sentence 
of the abstract and the first part of the introduction
(" The IETF consensus on this RFC represents consensus to publish this 
memo,  and not consensus on the text itself."), but
this sentence does not address that concern.

If you are wanting to document what exists so that other documents can 
talk meaningfully about it (as the writeup suggests),
please use Informational, and replace the sentence with an adaptation 
of  the bulk of the answer to question 1 in the writeup.

If you are wanting more people to implement exactly what this document 
describes and learn something from those implementations,
describe in the document what you're trying to learn and get IETF 
consensus that the experiment is a good one to pursue.

The combination of Experimental and "there is no consensus on the text 
in this document" is not a good one.

It might be easier to find the right way to bring the important parts 
forward if you split the format definition and the sketch of protocol 
behavior into a separate document from the motivation text at the 
beginning and the deployment scenario discussions at the end.

To the authors:

This _is_ good information, and clearly has already been useful in IETF 
protocol development discussions.
The number of documents referencing this one is a strong indicator of that:
<http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/referencedby/>

The document reads clearly, and complete enough to inform a basic 
implementation.
(Though I encourage you to be more explicit about what to do if you 
receive a packet with the I flag set to 0).

Please reread each sentence that begins with "Another" and consider 
either restructuring the sections where you have a string of them so 
that they are not necessary, and simply removing the clause when you use 
it in isolation.

6.1 is out of place - please move it to be with the other places where 
you put requirements on an implementation. I suggest it belongs at the 
end of section 4 or as its own section between section5 and section 6.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Mar 2014 21:46:22 -0000

Thanks Robert,
 
I also noted some of these process concerns as shepherding AD, but took over the
document half way through IETF last call. I am currently in discussion with the
authors about the best way forward.
 
Cheers,
Adrian
 
From: ietf [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 20 March 2014 21:35
To: General Area Review Team; [email-masked];
[email-masked]
Subject: Gen-art LC review: draft-mahalingham-dutt-dcops-vxlan-08

 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 

    
Summary: This document is not ready for publication as an Experimental IETF
Stream RFC

To the AD and shepherd: Why is the proposed status Experimental and not
Informational?
The text in the shepherd writeup provides a strong motivation for Informational,
but not Experimental.

I understand the concern that led to the inclusion of the last sentence of the
abstract and the first part of the introduction
(" The IETF consensus on this RFC represents consensus to publish this memo,
and not consensus on the text itself."), but
this sentence does not address that concern.

If you are wanting to document what exists so that other documents can talk
meaningfully about it (as the writeup suggests),
please use Informational, and replace the sentence with an adaptation of  the
bulk of the answer to question 1 in the writeup.

If you are wanting more people to implement exactly what this document describes
and learn something from those implementations,
describe in the document what you're trying to learn and get IETF consensus that
the experiment is a good one to pursue.

The combination of Experimental and "there is no consensus on the text in this
document" is not a good one.

It might be easier to find the right way to bring the important parts forward if
you split the format definition and the sketch of protocol behavior into a
separate document from the motivation text at the beginning and the deployment
scenario discussions at the end.

To the authors:

This _is_ good information, and clearly has already been useful in IETF protocol
development discussions.
The number of documents referencing this one is a strong indicator of that:
 
<http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/referencedby/
<http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/referencedby/

The document reads clearly, and complete enough to inform a basic
implementation.
(Though I encourage you to be more explicit about what to do if you receive a
packet with the I flag set to 0).

Please reread each sentence that begins with "Another" and consider either
restructuring the sections where you have a string of them so that they are not
necessary, and simply removing the clause when you use it in isolation.

6.1 is out of place - please move it to be with the other places where you put
requirements on an implementation. I suggest it belongs at the end of section 4
or as its own section between section5 and section 6.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Mar 2014 07:46:02 -0400

FWIW, this document should be informational. I'm not sure why the
shepherd writeup went experimental. My recollection of the discussion
within the NVO3 WG was that Informational was the way to go. More
importantly, this document has all the hallmarks of a document that
has traditionally gone out as informational (i.e., it is documenting
something that industry has implemented, and it is being published for
the good of the community).

Also,I object to the following wording in the abstract:

  The IETF consensus on this RFC represents consensus to publish this
  memo, and not consensus on the text itself.

When was it decided that we need to add yet more disclaimers to
informational documents? Has the IESG now decided that all
info/experimental documents need yet another disclaimer in them? If
so, please explain to the community what your new position is and be
consistent in applying it to all documents going forward. I'll note
that looking at a very recent AD-sponsored informational RFC that just
appeared, no such disclaimer appears there.

Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 21 Mar 2014 12:09:57 +0000

Since I put this into IETF LC

> the good of the community).
It has always been experimental. I should have picked this up.
I am not sure why, but I assume that this is to do with its relationship
to LISP which is also experimental.
> appeared, no such disclaimer appears there.
At the time when I was getting this ready for the IESG, there was a strong
view by the IESG that the IETF stream should not be used to publish
this type of document, i.e. that this type of draft should go to the
ISE. The view was that there were far too many AD sponsored drafts.
There was also a strong view expressed to me that the concept of IETF
consensus (necessary for AD sponsorship) was inappropriate if the
IETF could not change the technical solution, which it could not do if
the document was describing an existing deployed system.

The text that Thomas refers to  was intended to note the scope of the
consensus being sought - i.e. consensus to publish, and to defuse
the ongoing push back at continuing to publish this type of draft
in the IETF stream.

Of course the new sponsoring AD and the new IESG may take a
different view.

- Stewart

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Mar 2014 08:18:47 -0400

Hi Stewart.

> the document was describing an existing deployed system.

If the above is really the case, I would have expected an IESG note to
the community documenting/proposing that position and allowing the
community to comment, as it seems to me to be a significant change in
policy and/or exisiting practice. Did I miss such a note?

> the document was describing an existing deployed system.

This would be a very significant change in policy wrt what the IETF
has historically published. I would not expect the IESG to make such a
shift unilaterally without significant consultation with the
community.

Thanks!

Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 21 Mar 2014 13:59:46 +0000

On 21/03/2014 12:18, Thomas Narten wrote:
> .
My preference would be to remove the text, provided this did not
result in an immediate discuss stopping the text from progressing.

Stewart