Subject: [Ace] Use Case drafts - should they be published summary

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Feb 2015 18:26:41 -0500

Hello,

Sorry for the cross post, both WGs helped develop a list of arguments on
why their use case draft should be published.  I didn't get many messages
(and the chairs didn't either in private), so it seems most are in favor of
publishing use cases drafts.

I'll plan to chat about this with the IESG next week and wanted to share my
summary of reasons.  I ordered them, but didn't spend too much time
editing, as this won't be a living document (at least in this state).

Thanks again for your assistance!

----

*Use Case Drafts: Should they be published?*

*Reasons in favor:*

   1. If this is part of the WGs charter and a milestone, the work has
   already been agreed to be done and there is an expectation from those
   working on it that it will be published.  The WG has probably already
   sucked up this time if it's on the charter.  It would be unfair to pull it
   now.
   2. The IESG is here to serve the IETF.  If there is consensus to publish
   a use case draft, it should go forward.
   3. If the WG wants it published, it ought to be darn well be published.
   There’s no prohibition against uc/req drafts that I’m aware of *AND* it’s
   an Informational RFC after all it’s *NOT* a standards track RFC.  There
   ought to be a lower bar for informational vs standards track and if there
   isn’t one then that’s really the IESG’s fault.
   4. The use cases draft helps to frame the problem(s) being addressed by
   the WG proposals and is important for guiding future development as well as
   recording the history of consensus about the scope of work.
   5. Allows WGs to get cross-area review and IESG input earlier in the
   process on the whole WG concept.  That might be possible with just an IETF
   LC, but that seems like a bit of a waste of time and probably wouldn’t be
   taken seriously by the reviewers without a “threat” of publication.
   6. They are usually informational with no RFC2119 language and should be
   easier to process.
   7. It is desirable to have a published document that can be found later
   to better understand the scope of work produced by a WG or can be used to
   get a newcomer up-to-speed.  While an expired draft can technically be
   found, it's existence may not be known by those interested to read the
   draft. Dave Crocker's dependency graph off the WG page in the data tracker
   include expires drafts.  Some expired drafts should go away, how would one
   distinguish in a traceable and helpful way?  You can't rely on wiki's to be
   maintained after WGs disappear.
   8. A wiki to maintain this type of data is too dynamic and can't be
   trusted.  How do you distinguish versions and changes over time even if it
   isn't published as an RFC until the solutions are closer to final?
   9. In most scientific publications, referencing a weblink (like e.g. a
   wiki) is strongly discouraged due to their ephemeral nature. Having an RFC
   number is not only nice to have, it is quite essential if one is to refer
   to this document in any serious article.
   10. The process of getting it published usually supplies a final jolt of
   energy that can make the document even better (and increase the focus of
   the WG in the process).  It is hard to overestimate this effect.
   11. From the ACE WG: One obvious reason for having this as a WG draft
   (published or not) is that some felt their input wasn't considered when it
   was an individual draft.
   12. People might be more motivated to contribute to a WG draft than to
   an individual draft.  People will also be more motivated to contribute if
   the final result is a published document that they can point to when
   someone (employer, sponsor) asks them what the result of their work was.
   13. Publishing the draft as (informational) RFC also helps to valorize
   the work that the authors put into this document.  If the draft is just
   published as a wiki, this sends the message to many readers that IETF
   didn't consider this a worthy enough contribution for a real publication.
   This would also discourage future contributions to such documents
   (especially by scientists).
   14. WGs still have the energy*, and want to get this off the table so
   they can use it (as intended) as input for the specification-level
   discussion of the WG. Note: this may be especially true for newcomers to
   the IETF, it will help for them to see a progression of drafts and that
   work can move along.
   15. Diversity: If we want to encourage customer participation, this is
   one of the key areas in which they can contribute and have a positive
   impact on the work.  This may also help researchers who may be involved in
   use cases or subsequent phases where they raise awareness of existing work
   to solve the problems discussed in the scope of work.

*Opposition:*

   1. It's time consuming for the IETF and ideally would have been
   completed prior to WG formation.  By the time use cases are complete, folks
   interested in solutions may have walked away already to go do something
   real, develop code.
   2. This process doesn't keep pace with the open source community and
   should be a pre-cursor to WG formation.  We need to figure out how to speed
   up.
   3. Use cases may be a moving target and may evolve over the course of
   the WG life.

----

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Feb 2015 19:10:49 -0500

I;m just going to amend #2 so it's not misunderstood, this is specific to
use case drafts.  If a draft is harmful to the Internet and it gets to the
IESG, it probably won't get published even if there is consensus.

On Thu, Feb 5, 2015 at 6:26 PM, Kathleen Moriarty <
[email-masked]> wrote:

> I'll plan to chat about this with the IESG next week and wanted to share
> my summary of reasons.  I ordered them, but didn't spend too much time
>    2. The IESG is here to serve the IETF.  If there is consensus to
>    publish a use case draft, it should go forward.  Cross area review may help
>    identify early problems with the work or things that could be harmful to
>    the Internet.
>    3. If the WG wants it published, it ought to be darn well be
>    published. There’s no prohibition against uc/req drafts that I’m aware of
>    *AND* it’s an Informational RFC after all it’s *NOT* a standards track
>    RFC.  There ought to be a lower bar for informational vs standards track
>    and if there isn’t one then that’s really the IESG’s fault.
>    4. The use cases draft helps to frame the problem(s) being addressed
>    by the WG proposals and is important for guiding future development as well
>    as recording the history of consensus about the scope of work.
>    6. They are usually informational with no RFC2119 language and should
>    be easier to process.
>    7. It is desirable to have a published document that can be found
>    later to better understand the scope of work produced by a WG or can be
>    used to get a newcomer up-to-speed.  While an expired draft can technically
>    be found, it's existence may not be known by those interested to read the
>    10. The process of getting it published usually supplies a final jolt
>    of energy that can make the document even better (and increase the focus of

-- 

Best regards,
Kathleen