Subject: [therightkey] Ramping up

From: Melinda Shore <[email-masked]>
Date: Mon, 17 Feb 2014 10:01:35 -0900

1) I've asked Ben and his co-authors to resubmit
   draft-laurie-rfc6962-bis as draft-ietf-trans-rfc6962-bis

2) We need to nail down milestones.  In particular we need
   to have a reasonable ballpark estimate of when we'll get
   the bis draft into working group last call.  I'd like more
   feedback from the authors and working group participants
   on what they and you feel needs to be done to wrap up
   the draft.  Does late 2014 seem reasonable for working
   group last call?

3) Another question is whether or not there are sections
   of 6962bis which ought to be moved to separate documents,
   such as client behavior.

4) London planning: I am generally not a fan of burning up
   meeting time on PowerPoint-driven presentations - they're
   sometimes unavoidable but IETF meetings are working meetings
   and I'd rather use the time productively, for face to face
   discussion of things which are difficult to work out on
   the mailing list or which would benefit from more interactivity
   than we can get with email.  We don't have a huge amount of
   spare time in London but we can squeeze in some people in
   if they've got something that needs attention or that would
   help move the document along

5) the corollary to 4 is that I do try to get as much done on
   the mailing list as possible.  One thing that's been useful
   in some circumstances in the past has been an issue tracker.
   We do have a working group wiki page with an issue tracker,
   and I'd like to get a sense of whether the working group in
   general and the authors more specifically would find it
   helpful in progressing the document.

6) Are there other process issues you'd like to see addressed?

Once I hear from Ben et al. I'll get a draft agenda for London
posted.

Thanks,

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Feb 2014 15:08:08 -0500

The fact that designers have been forced to go through the process of
generating a description is often very useful.

What I have been doing is to make the presentation of what and why into
podcasts that are up on YouTube.

I think UNIX would have come out very differently if the designers had been
required to work with a technical writer and explain what was going on. Lot
of needless obfustication would have been easier to fix than to explain.

Which is of course why there is a resistance to doing such exercises.

On Mon, Feb 17, 2014 at 2:01 PM, Melinda Shore <[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Feb 2014 19:25:14 +0000

>    draft-laurie-rfc6962-bis as draft-ietf-trans-rfc6962-bis

Now done: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 20 Feb 2014 20:42:15 +0000

On 17/02/14 19:01, Melinda Shore wrote:
<snip>
>     helpful in progressing the document.

Hi Melinda.  Thanks for taking on the WG chair role.  :-)

Given the close relationship between RFC6962(-bis) and the open-source 
CT project, we've so far been logging issues for RFC6962-bis on the 
issue tracker at 
https://code.google.com/p/certificate-transparency/issues/list

I don't suppose it really matters which issue tracker we use.  Using an 
issue tracker will definitely be "helpful in progressing the document" 
though, IMHO.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Melinda Shore <[email-masked]>
Date: Thu, 20 Feb 2014 12:09:22 -0900

> issue tracker will definitely be "helpful in progressing the document"

Thanks, that's really helpful.  We ran into a parallel situation
in scim and ended up transitioning the issues that were specific
to the spec to the IETF issue tracker and keeping ones specific
to the implementation (and granted, that line isn't always
clear) in the Google code issue tracker.

There are two main questions when using an existing tracker (well,
maybe 2.5):

1) making sure that what goes into the tracker reflects working
   group issues with the spec (and that when an issue is closed
   it's because it reflects working group consensus), and
2) making sure that people who are involved with the spec but
   not with the implementation can add/comment/close working
   group issues
2.5) making sure that working group participants cannot scribble
   all over implementation issues

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Mon, 24 Feb 2014 16:26:18 +0000

There are ~8 issues in the open-source CT issue tracker that pertain to
RFC6962-bis. I'll happily migrate them to another issue tracker if that's
the consensus.

Eran

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Feb 2014 08:57:17 -0900

On 2/24/14 7:26 AM, Eran Messeri wrote:
> RFC6962-bis. I'll happily migrate them to another issue tracker if
> that's the consensus. 

I'm personally good with that, if there are no objections.
The issues tracker is associated with a Trac wiki, at
http://trac.tools.ietf.org/wg/trans/trac/wiki.  You'll
need a tools account.  If you don't already have one you
can request one here: http://trac.tools.ietf.org/tools/loginmgr/newlogin

Thanks again!

Melinda