Ian Grigg <iang(_at_)systemics(_dot_)com> writes:
Werner Koch wrote:
On Mon, 25 Oct 2004 11:30:24 +0100, Ian Grigg said:
2. what is the process? Do we vote, do we pray or do we
send bribes?
We need to get a rough consensus within this WG.
OK. I'd say it is good to go. With or without the handful
of minor changes suggested in the last few days.
I'm glad you think it's good to go. Being the chair, it's my job to
call a last call. It's not going to happen before the DC meeting. It
might happen shortly after DC. I need to talk with Jon about it (I'll
be seeing him in about two weeks).
Any other entries into consensual roughness?
Yes, we need to hear from lots of other people in this group, too, and
Jon and I need to go over the list of open issues and make sure they
are all handled. Rough concensus is not one vocal person saying
"we're done", it's the group as a whole saying "we're done". It's my
job to listen to the group as a whole.. And part of that job is
tuning _OUT_ those single vocal voices to make sure they aren't the
only ones saying something.
5. How to we get into Draft Standard status? We have talked for
years about interoperability tests but we never
actually did anything. AFAIK, there is no formal process for such
a tests and I ask myself whether it is sufficient that the 2 oldest
implementations (PGP and GnuPG) have shown over the years that they
are quite good interoperable and that the last OpenPGP glitches
have been sorted out with the last releases of both programs. We
could probably come up with a collection of discussions as evidence
to what we have tested during the development.
Unfortunately that is not sufficient....
OK, I am guessing here that interoperability tests
are required to get to draft standard.
Yes. However I believe 2440bis is still going to Proposed Standard.
There are enough changes to warrant PS instead of DS.
a. does that have a bearing on the RFC process for
bis-11? Or is it independent?
Moving to "draft standard" will be a secondary process once we finish
2440bis.
b. can someone summarise what has been said in the
past about interoperability?
Irrelevant.. We need to work from the draft and perform an actual
bakeoff with multiple implementations and go, feature by feature down
the list in the draft and test each and every MUST/SHOULD in the
draft. (I don't recall if you need to test MAY, but I think you do).
Then you remove anything that hasn't been implemented, or you wait for
it to get imeplemented, and publish yet another draft (with yet
another RFC number) as a DS.
c. without any thought or research, I'd suggest
something like the following:
i. a program for each implementation that produced
an example of each type of message.
ii. a program for each that reads the examples in i.
iii. ideally, a service where an implementation can
be put into random spit mode, where it churns out
a squillion of these random messages of all forms,
iv. again, a service where an implementation can
process a squillion random messages.
Then, take the two implementations and run them against
each other. (This is how I test my stuff.) It has one
particular hole in it, as it doesn't cover how an
implementation deals with an illegal message. But that's
a security issue not an implementation issue.
d. or, anything else?
c is certainly a workable test plan.. But let's get 2440bis finished
before we start working on the bakeoff.. You're welcome to think
about how to implement the bakeoff now but I'd suggest we keep that to
a low simmer until we get the document through WGLC and into the hands
of the IESG.
iang
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant