Subject: last call?

From: Ian Grigg <[email-masked]>
Date: Mon, 25 Oct 2004 11:30:24 +0100

It has been mooted that we might be moving to a last call for
changes on the draft bis-11 (perhaps only by me :-)

Questions of procedure:

1.  is this the case?  Are we entering into a last call?
And if not, how do we proceed to get there?

2.  what is the process?  Do we vote, do we pray or do we
send bribes?

3.  What is the procedure for doc changes within the process?
None at all?  Only severe security changes?  Or something
in between?

(I note that there seem to be at least 2 changes that have
to be made, being the year, I pointed out a few days ago,
and the RFC # which apparently has to change.)

4.  What's the story about the RFC number change?  Is it
possible to get an allocation at this point?

iang

---

From: Werner Koch <[email-masked]>
Date: Mon, 25 Oct 2004 13:06:36 +0200

> 2.  what is the process?  Do we vote, do we pray or do we

We need to get a rough consensus within this WG.

> possible to get an allocation at this point?

That is the task of the RFC-Editor.

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.

Salam-Shalom,

   Werner

---

From: Ian Grigg <[email-masked]>
Date: Mon, 25 Oct 2004 13:49:06 +0100

> 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.

Any other entries into consensual roughness?

>    to what we have tested during the development.

OK, I am guessing here that interoperability tests
are required to get to draft standard.

a.  does that have a bearing on the RFC process for
bis-11?  Or is it independent?

b.  can someone summarise what has been said in the
past about interoperability?

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?

iang

---

From: David Shaw <[email-masked]>
Date: Mon, 25 Oct 2004 09:41:03 -0400

>On Mon, Oct 25, 2004 at 01:49:06PM +0100, Ian Grigg wrote:

> Any other entries into consensual roughness?

I am not part of such a consensus.  There were several minor open
issues when the list went silent.  I am traveling right now, but will
repost them tomorrow.

David

---

From: Derek Atkins <[email-masked]>
Date: Mon, 25 Oct 2004 10:10:13 -0400

> 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

Unfortunately that is not sufficient....

> 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.

> bis-11?  Or is it independent?

Moving to "draft standard" will be a secondary process once we finish
2440bis.

> 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.

> a security issue not an implementation issue.

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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Werner Koch <[email-masked]>
Date: Mon, 25 Oct 2004 19:36:22 +0200

> Unfortunately that is not sufficient....

Is there an RFC defining the rules?  

FWIW, from the minutes of the 45th IETF OpenPGP WG on 14-July-1999:

  Advance to Draft, Collect $200
     6 months have passed
     Requirements
       2 implementations
       No IPR problems
       6 months of experience
  
     JN: We have the experience but we do not have the interoperability
     fully checked. Suggest: Enumerating all the musts and publishing a
     document so implementors can easily see requirements for
     compliance. Finally, we can get implementors into a room for
     testing.
  
     Implementors' survey & results are at:
       noc.rutgers.edu/~mione/ietf/ietfopgp.html
  
> Moving to "draft standard" will be a secondary process once we finish

:-(

Okay, to make the later interop testing easier we should now really
consider to make all PGP2 things OPTIONAL or even remove them.

  Werner

---

From: Derek Atkins <[email-masked]>
Date: Mon, 25 Oct 2004 14:20:52 -0400

> Is there an RFC defining the rules?  

Good question.  There is a document on the process in general,
and "The Dao of the IETF".  As for when a 'bis' document progresses
to Draft or stays at Proposed tends to be a combination of time,
effort, interop, and the amount of changes between the original
and new document.  In particular, to go from Proposed to Draft
you generally can NOT add new features...

>        noc.rutgers.edu/~mione/ietf/ietfopgp.html

This was a long long time ago and under the previous chair, so my
applogies for not being in the loop for this.

> consider to make all PGP2 things OPTIONAL or even remove them.

Eh, we can always drop that when we move to draft.  Dropping
"features" is perfectly reasonable in Proposed -> Draft.  The main
purpose of the interop testing is to see what's been implemented but
also to weed out what cannot be implemented (or hasn't been
implemented) and drop it from the draft _then_.

So, if we're going to Proposed now, as I suspect we are, then there's
no need to drop RFC1991 compatibility now.  We can drop in 6ish months
later when we go to Draft.

-derek

---

From: Ian Grigg <[email-masked]>
Date: Tue, 26 Oct 2004 12:42:04 +0100

> you generally can NOT add new features...

As an observation, I don't think too many features
have been added since 1999, so I can't see the
problem with that.

>>consider to make all PGP2 things OPTIONAL or even remove them.

I personally think this is an excellent idea, but...

> later when we go to Draft.

That's encouraging.  Cryptix already made the decision
several years back to drop pgp2 from our OpenPGP library.

It just doesn't make sense to maintain separate paths in
the code for such a small user base, our users are much
better served with us spending that time on applications.

iang

---

From: Jon Callas <[email-masked]>
Date: Tue, 26 Oct 2004 13:05:04 -0700

I don't think we're ready for -11 to be last call.

As I've said before, what's missing from -11 is removing / deprecating 
/ etc. PGP 2 stuff. I haven't done that. That is in my opinion a 
requirement for last call.

Beyond that, I know of no remaining open issues (from the last time 
Derek and I talked) for which there was something actionable. I mean by 
'actionable' that while it might be true that X could be improved, 
there's no offered actual text. I'm loathe to go fix something that's 
suboptimal because there's a significant risk that my fix will be no 
better or even worse than the previous thing.

I offer as an example of where I did this in the past is the whitespace 
and trimming issue in text and clearsigned signatures. I took a good 
complaint with a reasonably vague description of what should be changed 
and made a good guess. That good guess wasn't good enough. I don't want 
to repeat this.

Restating again and tying in what Derek has said, he and I are going to 
be in the same place in a couple-three weeks. I believe there are no 
actionable open items. I believe that the remaining ones should be 
discarded, if for no other reason that they don't seem to be burning 
issues and finishing a new RFC takes precedence. (Modulo PGP 2 
deprecation) I'm willing to be corrected or overruled on either of my 
beliefs by him or the working group. But in the interests of finishing, 
I'm going to assert these beliefs in a clear voice.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Tue, 26 Oct 2004 13:14:38 -0700

I also want to issue my agreement with Werner on interoperability. 
Recent releases of GnuPG and PGP offer an existence proof of 
interoperability. (I'll go further and say that in the PGP cases, the 
interop problems we used to have were caused by our not upgrading 
pre-2440 behavior to be 2440-compliant.) The places where there *are* 
interop problems, they are caused by PGP 2 backwards compatibility. In 
2440, backwards compatibility is encouraged but not required; it's a 
SHOULD. Since one of the remaining items is to demote that SHOULD, we 
don't need to consider these issues. When you do this, Ian's 
implementation is a third one. There is interoperability.

	Jon