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:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Robert Sparks
Sent: 20 March 2014 21:35
To: General Area Review Team; ietf(_at_)ietf(_dot_)org;
draft-mahalingham-dutt-dcops-vxlan(_at_)tools(_dot_)ietf(_dot_)org
Subject: Gen-art LC review: draft-mahalingham-dutt-dcops-vxlan-08
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>
<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/
<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.