Subject: RE: OCSP identifiers

From: Carlisle Adams <[email-masked]>
Date: Tue, 28 Nov 2000 11:15:53 -0500

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Tuesday, November 28, 2000 10:32 AM
> To: 	Carlisle Adams
> Cc: 	[email-masked]; Michael Myers
> Subject: 	Re: OCSP identifiers
> 
> Carlisle,
> 
> I am clearly opposed to the current OCSP v2 proposal, I am not opposed in
> principle to extensions, ... IF a rational is provided for these
> extensions
> AND we care for OCSCP v1 backward compatibility. In an E-mail posted to
> Mike
> this morning (Paris time), I raised a point raised much earlier, which
> remains to be answered:
> 
> "Besides the ASN.1, explanations would need to be given to tell which
> combinations of these parameters make sense. The problem is that for the
> basic service (i.e. a simple revocation status request), some combination
> may be fine, but not sufficient for additional services (supported through
> extensions). So we would have to anticipate the needs for these
> extensions. 
> 
> In order to make sure we do not miss anything, a study should be done, at
> least for the three services that we are attempting to support, to explain
> and identify which combinations of these parameters are needed and thus
> make
> sense." 
> 
> Would you have an answer ?
 
I agree with this, although in government and academic circles (at least),
the words "a study should be done" often imply a delay of a year or longer
before anyone hears an answer.  I hope that this is not what you have in
mind here and that, instead, this "study" could be completed by 2 or 3
people at the San Diego meeting after they've ordered their lunch and before
they've finished eating it.  It's just a matter of figuring out which
combinations make sense for each service and writing it down in the spec as
a set of MUSTs and SHOULDs.  This should not be difficult.

> >> This makes four oppositions, if I count correctly and - maybe - eight
> >> in favor: this is NOT a rough consensus.
> > 
> > Actually, my impression is that in IETF any majority can be considered
> > "rough consensus" if an issue has dragged on long enough and a
> > specification needs to progress.  Certainly, a 2/3 majority would be
> > considered "rough consensus" in many circles (even outside IETF!).
> While
> > it is likely the case that not all the opinions are in yet, at the
> moment
> > I doubt that many would claim that this vote was "too close to call".
> 
> The fact is that we have no consensus on any ASN.1 syntax change today.
> Simon might be right when saying: "The bottom line is, lets stick with
> RFC2560, and move on with it", ... unless arguments are given to explain
> the
> use of every extension and reduce the number of cases of practical
> combinations.
 
Perhaps  we have no "consensus" on a specific ASN.1 syntax change, but all
I'm claiming is that (at the moment) there appears to be "rough consensus"
on the need for (or utility of) a change.  I agree that we shouldn't just
add lots of new options for the fun of it; we should consider carefully what
is really needed and specify the mandatory combinations.  Again, I think
that progress can be made on this front fairly quickly.

Carlisle.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 28 Nov 2000 17:25:41 +0100

Carlisle,

We basically agree in principle. However, I have some difficulties to eat,
discuss and write at the same time. So a lunch is certainly not the best way
to handle this problem. Why don't you prepare a first shot and sent it on
the list ? If we have some minor disagreements, then we can certainly
discuss these during a lunch time. However, knowing that you are already
booked for a lunch on Wednesday and that you will not be there on monday the
number of remaining lunches gets very limited.

:-)

Denis

>      AND we care for OCSCP v1 backward compatibility. In an E-mail posted
>      to Mike
>      and identify which combinations of these parameters are needed and
>      thus make
>      sense."
> 
> people at the San Diego meeting after they've ordered their lunch and
> before they've finished eating it.  It's just a matter of figuring out
> which combinations make sense for each service and writing it down in the
> spec as a set of MUSTs and SHOULDs.  This should not be difficult.
> 
>      RFC2560, and move on with it", ... unless arguments are given to
>      explain the
> add lots of new options for the fun of it; we should consider carefully
> what is really needed and specify the mandatory combinations.  Again, I
> think that progress can be made on this front fairly quickly.
> 
> Carlisle.