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]> wrote: > > > On 3 March 2015 at 20:52, Stephen Kent <[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]> 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]): >>>> >>>> Â 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] >>> 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
