Subject: [Ace] Arguments to publish use case document as RFC

From: "Kepeng Li" <[email-masked]>
Date: Thu, 29 Jan 2015 17:54:13 +0800

Hello all,

Recently in SACM WG, there were a lot of discussions about whether or not
to publish their use case document as RFC:
http://www.ietf.org/mail-archive/web/sacm/current/msg02306.html

I understand that we discussed about this before in the mailing list some
time ago.

I am sure that this issue will be raised again during the IESG review
stage or WGLC stage.

So, let’s be prepared for it.

Could you provide any arguments why you think the draft should get
published as RFC if that's what you think or if you think it is fine to
have this as
a WG draft that remains a guiding document that does not get published.

Here are a few arguments for it:
1) 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.
2) Another reason is that it is nice to have it as an RFC for reference
later on, but could a wiki provide a link to the expired draft just as
easily? 
3) The use cases draft helps to frame the problem(s) being addressed by
ACE proposals and is important for guiding future development and
recording the history of consensus about the scope of ACE work.
4) A wiki is too dynamic and can’t be trusted.

Anything else?

Thanks,
Kind Regards
Kepeng (as co-chair)

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 29 Jan 2015 11:41:17 +0100

> that some felt their input wasn't considered when it was an individual

Another reason is that 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 asks them what 
the result of their work was.

> later on, but could a wiki provide a link to the expired draft just as

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.

> recording the history of consensus about the scope of ACE work.

A wiki is good for some living, ongoing work. By putting the use cases 
in a wiki, we would indicate that this work is forever ongoing and that 
we basically haven't reached a stable consensus on what are good use 
cases for ACE.

> 4) A wiki is too dynamic and can’t be trusted.
See above

> Anything else?

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).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 29 Jan 2015 07:19:06 -0500

Thank you, Kepeng & Hannes.  

Please continue the thread from the appropriate message, this is just a quick clarification on how/where the info you help pull together on these questions will be used.

Sent from my iPhone

> On Jan 29, 2015, at 4:54 AM, "Kepeng Li" <[email-masked]> wrote:
> 
> Hello all,
> 

I'll leverage this information in a discussion with the IESG prior to the publication of this use case draft and the one from SACM.  My goal is to get this done separate from your last call process and do appreciate the chairs and WG developing the business case further.

Thank you,
Kathleen

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Jan 2015 13:13:51 -0500

> 4) A wiki is too dynamic and can’t be trusted.

I think this is a simple case of the WG deciding whether to push the use case/requirements (uc/req) draft forward (after somebody asks for it to be published, the chairs review it and agree it’s ready, and it successfully passes WGLC).  If the WG wants it published I think 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.

To me the real question after deciding to publish is when to publish: way before we get done with the protocol(s) or right before/same time as the protocol(s).  If we do it way before 1) we might end up needing to change something in the uc/req based on something we discover later, 2) we will need to reacquaint the IESG with the uc/req draft when pushing the protocol through, 3) we might get a different set of IESGers for the uc/req and protocol drafts that have differing “issues” causing all kinds of delays while we either get re-educated or re-educate.  If we publish at the same time, we run the risk of gotchas later in the process and maybe some complaints if we drop like 8 drafts at once on the IESG.  I’ve seen it go both ways so we just need to pick our poison and move out.

Put me in the camp that thinks this uc/req draft should be published now.  For me, it really helped focus the WG’s vision of what it wanted and got folks talking - that’s all good in my book; we’ll get cross-area and IESG review earlier in the process to avoid gotchas later (one can never completely avoid these but we might get the low hanging fruit).   To avoid a lot of the later uc/req draft woes maybe we could do put some kind of disclaimer in the draft that says: 1) we developed as an initial step in the WG, 2) it might be revised later based on design discussions, and 3) we pushed it before the protocol drafts for reasons x/y/z.  Actually, I’m not sure we need to put this in the draft, but if it’s in the Shepherd’s write-up the IESG and IETF LC reviewers ought to at least keep that in mind when reviewing it later.

spt