Subject: Re: [Trans] [trans] #59 (rfc6962-bis): Clarify STH versioning

From: "trans issue tracker" <[email-masked]>
Date: Mon, 02 Mar 2015 13:40:16 -0000

#59: Clarify STH versioning

Comment (by [email-masked]):

 I can't find anywhere that requires a v2 STH.

 However, I agree that we do not need to make this change yet: if we
 discover a need for extensions in an STH, then we can introduce a v2 STH
 and new APIs that deal with v2 STHs. Existing code can continue to use v1
 STHs and the corresponding APIs.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/59#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 02 Mar 2015 15:14:38 -0000

Comment (by [email-masked]):

 Ben sent this out for review in https://github.com/google/certificate-
 transparency-rfcs/pull/34

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/59#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 02 Mar 2015 18:14:31 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Closed with https://github.com/google/certificate-transparency-
 rfcs/commit/c7fa413ae0bb04c233c3825e00578ae78ad371b3.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/59#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 03 Mar 2015 11:58:31 -0500

Ben,

The issue here is not whether, at this time, we have identified an need for
a v2 STH. The issue is that the doc needs to describe how the system will
transition to a new version, if it is ever needed.

Steve

> Comment ([email-masked]):
>

---

From: Eran Messeri <[email-masked]>
Date: Tue, 3 Mar 2015 17:00:11 +0000

Shouldn't it be described when a new STH version is introduced, depending
on the changes to the STH structure?

On Tue, Mar 3, 2015 at 4:58 PM, Stephen Kent <[email-masked]> wrote:

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

---

From: Ben Laurie <[email-masked]>
Date: Tue, 3 Mar 2015 17:27:33 +0000

> transition to a new version, if it is ever needed.

That may indeed be _an_ issue, but it is not the issue this ticket
describes!

---

From: Stephen Kent <[email-masked]>
Date: Tue, 03 Mar 2015 15:52:36 -0500

Eran,

The means by which a new version is introduced should be described now, to
show that the design will accommodate a new version in a backward 
compatible fashion.

In protocols we usually include an explicit version number from the 
beginning, so
that one can tell the difference between v1 and v2, long before v2 has 
been designed.

Steve

> Shouldn't it be described when a new STH version is introduced, 
> depending on the changes to the STH structure?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 03 Mar 2015 15:52:41 -0500

Ben,

Whoops. Sorry my response was not on target.

But, while we're on the topic of response to issues, I find use of 
github for
communicating of issues to be very inconvenient.

First, the URLs in the messages are broken into two lines, so I have to
cut and paste them together to get to the right page.

Second, the lines in the files are often very long, so I have to scroll
to the right to read what has been written.

Is there a good reason that the text for proposed resolution of issues 
is not being
sent via messages to this list, as is common IETF practice? Someone who 
wants to
track what is happening in trans should be able to look at the mail and 
see what
is being changed/proposed, etc. Using github adds a layer of indirection 
that is
at best awkward, as noted above.

Steve
>
>
> On 3 March 2015 at 16:58, Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Ben,
>
> Â
>         Comment ([email-masked] <mailto:[email-masked]>):
>
>         Â  I can't find anywhere that requires a v2 STH.
>
>         Â  However, I agree that we do not need to make this change
>         yet: if we
>         Â  discover a need for extensions in an STH, then we can
>         introduce a v2 STH
>         Â  and new APIs that deal with v2 STHs. Existing code can
>         continue to use v1
>         Â  STHs and the corresponding APIs.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 3 Mar 2015 21:30:25 +0000

+1

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, March 03, 2015 3:53 PM
Cc: [email-masked]
Subject: Re: [Trans] [trans] #59 (rfc6962-bis): Clarify STH versioning

Ben,

But, while we're on the topic of response to issues, I find use of github for
communicating of issues to be very inconvenient.

Is there a good reason that the text for proposed resolution of issues is not being
sent via messages to this list, as is common IETF practice? Someone who wants to
track what is happening in trans should be able to look at the mail and see what
is being changed/proposed, etc. Using github adds a layer of indirection that is
at best awkward, as noted above.

Steve

On 3 March 2015 at 16:58, Stephen Kent <[email-masked]<mailto:[email-masked]>> wrote:
Ben,

That may indeed be _an_ issue, but it is not the issue this ticket describes!

Â

Steve

Comment ([email-masked]<mailto:[email-masked]>):

Â  However, I agree that we do not need to make this change yet: if we
Â  discover a need for extensions in an STH, then we can introduce a v2 STH
Â  and new APIs that deal with v2 STHs. Existing code can continue to use v1
Â  STHs and the corresponding APIs.

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Mar 2015 12:41:44 -0900

On 3/3/15 11:52 AM, Stephen Kent wrote:
> Is there a good reason that the text for proposed resolution of
> issues is not being sent via messages to this list, as is common IETF
> practice? Someone who wants to track what is happening in trans
> should be able to look at the mail and see what is being
> changed/proposed, etc. Using github adds a layer of indirection that
> is at best awkward, as noted above.

The resolutions are being sent to the mailing list, by the
issue tracker.  You've raised some objections and discussed a
few others, so clearly the information associated with a ticket
state change is being communicated.

We've instituted a change, however, and that's that going forward,
issues will not be closed by document authors but by Paul and me.

Melinda

---

From: Karen Seo <[email-masked]>
Date: Tue, 03 Mar 2015 19:15:10 -0500

Melinda et al.,

As an ordinary participant who doesn't have anywhere near a photographic 
memory and who's often swamped just like most everyone else,  I find 
it's hard to keep track of the discussions, especially when they stop 
and start over several months.  So I'd like to distinguish between 2 
parts of the problem.  First, I'd be most grateful if the person 
addressing an issue wrote a description of the proposed final 
resolution.  If the I-D text is being changed, this would just need to 
be the new text.  For example, the email that Eran sent on 3/2 re: 
Errata for RFC6962 made it really easy for me to quickly review it.  And 
this work, e.g., the new text, has to be written in any case -- so 
hopefully this doesn't require more work than would otherwise be done. 
Second, it would be slightly easier (one fewer steps) and therefore I'm 
more likely to find the time,  if the proposed resolution were 
distributed to the list in email, rather than in a link.  But since the 
proposed resolution should be documented in the issue tracker, it would 
be fine to do this via the ticket system. But in any case, please put 
the proposed resolution (new text, etc.) at the top of the ticket for WG 
review.  That way when I receive the ticket, the thing to be reviewed is 
right there.

Thank you,
Karen

-------- Forwarded Message --------
Subject: 	Re: [Trans] [trans] #59 (rfc6962-bis): Clarify STH versioning
Resent-Date: 	Mon, 2 Mar 2015 07:14:39 -0800 (PST)
Resent-From: 	[email-masked]
Resent-To: 	[email-masked]
Date: 	Mon, 02 Mar 2015 15:14:38 -0000
From: 	trans issue tracker <[email-masked]>
To: 	[email-masked], [email-masked], 
[email-masked]
CC: 	[email-masked]

---

From: Ben Laurie <[email-masked]>
Date: Wed, 4 Mar 2015 14:40:30 +0000

> to the right to read what has been written.

This only occurs in the "conversation" view, as far as I know. If you click
on "View full changes" you get a wrapped view of the change.

> at best awkward, as noted above.

The obvious answer to this particular awkwardness is to "watch" the
repository on github (button on the top page:
https://github.com/google/certificate-transparency-rfcs).

The good reason for not sending issues via messages is that it adds a layer
of indirection for the authors that is at best awkward.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 5 Mar 2015 12:07:29 +0000

By the way, if it would be helpful, I can easily post the current rfcdiff
between the last I-D and our proposed next I-D any time anyone wants it.

You can also check out the git repo and make it yourself.

And, of course, once we update the I-D on the IETF site, the diff is also
available there.

On 4 March 2015 at 14:40, Ben Laurie <[email-masked]> wrote:

> This only occurs in the "conversation" view, as far as I know. If you
> click on "View full changes" you get a wrapped view of the change.
>
>
>>
> The good reason for not sending issues via messages is that it adds a
> layer of indirection for the authors that is at best awkward.
>
>
>
>>
>> Steve
>>
>>
>>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 05 Mar 2015 12:23:10 -0500

Melinda,

yes, I am seeing the issue state changes. My concern is that they
often point to github postings. Sometimes I can comment on the
proposed change based on the terse text that may accompany the
issuer tracker message. In other cases one has to follow the
embedded link to see what has changed.

If the individual proposing changed text sent it to the list, I think 
that would be
preferable, independent of the process change you noted about how/when 
issues will be closed.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 5 Mar 2015 17:28:32 +0000

On 5 March 2015 at 17:23, Stephen Kent <[email-masked]> wrote:

> If the individual proposing changed text sent it to the list, I think that
> would be

Would a diff included in the issue be sufficient?

---

From: Karen Seo <[email-masked]>
Date: Thu, 05 Mar 2015 12:47:30 -0500

Hi, Ben,

That would be great (speaking just for myself) if you mean that for a 
given issue, you'd post the before and after applicable to just that 
issue, not a complete diff between draft versions.

Thanks very much,
Karen

On 3/5/15 7:07 AM, Ben Laurie wrote:
> By the way, if it would be helpful, I can easily post the current 
> rfcdiff between the last I-D and our proposed next I-D any time anyone 
> wants it.
>
> And, of course, once we update the I-D on the IETF site, the diff is 
> also available there.
>
> On 4 March 2015 at 14:40, Ben Laurie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On 3 March 2015 at 20:52, Stephen Kent <[email-masked]
>     This only occurs in the "conversation" view, as far as I know. If
>     you click on "View full changes" you get a wrapped view of the change.
>
>
>     The obvious answer to this particular awkwardness is to "watch"
>     the repository on github (button on the top page:
>     The good reason for not sending issues via messages is that it
>     adds a layer of indirection for the authors that is at best awkward.
>
>
>         Steve
>>
>>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 05 Mar 2015 16:31:18 -0500

yes, that would be better than the current approach.

Steve

>
>
> On 5 March 2015 at 17:23, Stephen Kent <[email-masked] 
>     If the individual proposing changed text sent it to the list, I
>     think that would be
>     preferable, independent of the process change you noted about
>     how/when issues will be closed.
>
>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 14:23:35 +0000

>  yes, that would be better than the current approach.

OK, I will do that from now on.