How to Contribute Research Results to Internet Standardization
RFC 6417

Note: This ballot was opened for revision 03 and is now closed.

(Wesley Eddy) Yes

Comment (2011-08-22 for -)
No email
send info
It may be worth considering adding a sentence (or paragraph) to indicate the difference between a document being adopted by an IETF working group and eventually published as an RFC versus the process for a traditional academic journal or conference presentation.  Specifically, it's worth warning that an RFC through an IETF WG will receive significantly more reviews than any academic journal gives (at least several WG participants, the WG chairs, and several IESG reviews are guaranteed), and that in many cases updates to the document (and perhaps even technical changes to the content and re-thinking bits of it) will be required in order to obtain consensus and move forwards.  It seems like Section 4 would be a good place to store some text on this.


It seems to me that section 3.1 (on finding the right WG) is akin to finding the right conference, workshop, or journal to submit a paper to, though perhaps *much* more crucial.  However, many working groups and ADs these days are helpful in "routing" work to more appropriate groups if you choose poorly.


In section 4.2, it strikes me that one potential difference between IETF work and common academic research is that we do a lot more "synthesis" of competing proposals, viewpoints, etc. and try to address the common use cases, requirements, etc., but in normal publications, it's more common to focus on one's own proposal only and cite "related work" in order to describe flaws or shortcomings that you improve on, even if the motivations of the work may differ a lot or the work is even misunderstood.  In the IETF you're collaborating with others toward a common goal and product instead of publishing separate works in parallel tracks alongside them.  It also often involves greater sensitivity about what else the IETF is doing or what *other* problems exist in the Internet today than what narrow research generally requires, since people working on these other issues can block your work if doesn't align well with theirs.


There are some typos, but I'm sure the RFC Editor can take care of them:

- extra space before last period in Abstract

- double ":" at end of third paragraph in Introduction

- inconsistent use of periods to terminate bullet points (e.g. in section 3.4)

(David Harrington) Yes

(Pete Resnick) (was Discuss) Yes

(Jari Arkko) No Objection

(Stewart Bryant) (was Discuss) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Stephen Farrell) No Objection

Comment (2011-08-23 for -)
No email
send info
Nice document that would have been useful for me to point at a few
times, thanks.

- I think its worth saying somewhere that research can often 
properly ignore some aspects that become important in the IETF (or
even IRTF) such as security, performance, mgmt etc. so knowing
which of those your research hasn't addressed before you start out
with the IETF is useful, or even better is if you start addressing
them before turning up at the IETF, or ask for IETF help in doing
that. For that you could maybe add a bullet to the list on p3/4
along the lines of "- when the research hasn't focused on aspects
of the technology that are important to the IETF such as security,
management etc."

- In 3.3 I think it'd be worthwhile to explicitly encourage people
to actually submit an I-D and say that that's the format that IETF
people are used to reading. Extracting the IETF-relevant parts of
publications into an I-D is also often going to help identify
parts that need more work (e.g. protocol details glossed over
in simulations/PhD code) that could be done in the IETF.

- I think a reference to IPR would be useful since a lot of
researchers might not be aware of the IETF's rules on that.  (I've
seen some express surprise when told.) I'm sure there's a
potential rathole in figuring out how to say that succintly, so I
won't suggest text for that:-)

(Dan Romascanu) No Objection

Comment (2011-08-25 for -)
No email
send info
I have no problem with the publication of this document. I would observe that many of the recommendations about how to take new work in the IETF would be valuable for a broader audience, not only the research community. Out of the good comments that were made I support the ones made by Wesley concerning the need to take into consideration security, transport and operational aspects which are usually not that much in the focus of research projects. I would also make a crisp recommendation to submit proposals to the IETF as Internet-Drafts - this is actually the almost ubiquituous requirement made for all new contributions. 

(Peter Saint-Andre) No Objection

Comment (2011-08-22 for -)
No email
send info
This is a helpful document. Thanks for writing it.

(Robert Sparks) (was Discuss, No Objection) No Objection

(Sean Turner) No Objection

Comment (2011-08-23 for -)
No email
send info
Thanks for this.  I'd like to echo Stephen's and Wes' comments.

spt