[Trans] Next steps for 6962-bis

[Paul Wouters <[e-mail]>]

We just wanted to clarify where we are with 6962bis. We have scheduled a
meeting at IETF102, and I think it would be a good goal to discuss the
remaining items on the list now and see if we can wrap this up in
Montreal. We have a short timeslot, so let's try and wrap up the
main discussions before Montreal. Rob Stradling gave us a nice summary
list of open items to talk about. Thanks Rob!


1) Document status

There has been a discussion about the document status, which was set to
Proposed Standard. RFC 6962 itself is Experimental. After some discussion
between authors, AD and chairs, we agreed that since the changes between
6962 and 6962bis are not trivial, and that we have no implementations
yet that validate that there are no implementation issues, that we should
change the document status to Experimental. Please speak up if you
disagree with this decision.

Proposed textual change:

 	https://github.com/google/certificate-transparency-rfcs/pull/297

One suggestion by Rob was to perhaps clarify why we are going from
Experimental to Experimental. If you think this is needed, please let
us know (or better, provide text)

2. AD review: Remove the 'no security implications' claim

 	https://github.com/google/certificate-transparency-rfcs/pull/296

No one objected on the list, but Rob would like to hear at least one
more voice agreeing with this change. If we don't hear any objections,
we will proceed with this change.

3. AD revieW: Remove the Preventing Tracking Clients claim

 	https://github.com/google/certificate-transparency-rfcs/pull/295

We had some discussion on the list. Eric has pointed out this
complicated RSA-PSS. Previous discussion talked about removing
this as it was mostly to faciliate the (still incomplete) gossip
protocol. We can either leave it in, remove it, or rewrite it to
more advisory/BCP and less restrictive ? Please dicsuss, otherwise
it seems to consensus is to remove this claim.

4. Fotis Loukos proposed clarifying what we mean by "current NTP Time".

Does this need clarification? Or can it punt this to other documents?
If this is needed, we need someone to write up the text required.
If we don't hear from others, we will not make any change.

5.  Corey Bonnell proposed switching error reporting to use the JSON Problem Details format (RFC7807).

If this is needed, we need someone to write up the text required.
Please discuss. If we don't hear from others, we will not make any change.

6. Option for CT logs to signal when rejections were due to rate-limiting

If this is needed, we need someone to write up the text required.
Please discuss. If we don't hear from others, we will not make any change.

Paul & Melinda