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.
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 protected]
<mailto:[email protected]>> wrote:
On 3 March 2015 at 20:52, Stephen Kent <[email protected]
<mailto:[email protected]>> wrote:
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.
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.
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 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.
Steve
On 3 March 2015 at 16:58, Stephen Kent <[email protected]
<mailto:[email protected]>> wrote:
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.
That may indeed be _an_ issue, but it is not the issue this
ticket describes!
Â
Steve
#59: Clarify STH versioning
Comment ([email protected] <mailto:[email protected]>):
 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.
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
