Subject: RE: The future of DVCS...

From: Carlisle Adams <[email-masked]>
Date: Thu, 12 Oct 2000 12:18:25 -0400

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Thursday, October 12, 2000 3:25 AM
> To: 	Carlisle Adams
> Cc: 	[email-masked]'; [email-masked]'; [email-masked]
> Subject: 	Re: The future of DVCS...
> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
 
(...some text deleted...)

> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also
> means
> that this subset is not the right direction for the long run and thus
> should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC.  
 
Actually, this is a very good reason why this subset *should* be placed in
an Experimental RFC.  These other protocols, which differ in some details
with what is in DVCS, go on to become standards, whereas our early
"experimental" work on this same functionality is archived as something that
was tried but not standardized.

> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
 
Actually, this again *is* a good argument for saving this material in an
Experimental RFC.  DVCS represents something that was conceived, discussed,
and implemented, but all in quite limited circles.  When it comes time to
discuss this sort of topic more broadly, this early "experimental" work can
perhaps serve as a reasonable starting point for that discussion.

> > Furthermore,
> > we are aware of only a single implementation at this time, so any
> > interoperability testing is out of the question, at least at the moment.
> > But enough work has gone into this protocol that letting it expire as an
> > Internet Draft and disappear completely seems inappropriate, especially
> if
> > (as we suspect) this higher-layer functionality will begin to be
> required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.
 
Within the IETF environment, what alternatives are there for preserving this
work?  As you well know, the only archival documents in IETF are RFCs, so if
we all agree that DVCS is not appropriate for the standards track at this
time, we are left with Experimental, Informational, Historic, and Best
Current Practice.  The description for Experimental is given in RFC 2026 as
follows:

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

DVCS was certainly the result of some early research work centering on the
possible uses of a notarization-type server, and did undergo some limited
development (i.e., implementation) effort.  It may be useful as a source of
information on this topic to at least the Internet technical community, if
not the broader Internet community.  It makes sense to have an archival
record of this work, especially if this topic may arise again in the future.
I see pretty-much an exact fit between DVCS and the stated purpose of the
Experimental RFC category.

Perhaps, however, you are suggested that this document should be preserved
outside the IETF process.  This can certainly be done, but I must confess to
having a hard time seeing what value that would serve to the Internet
community.

> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
 
(...substantial and valuable comments deleted for the sake of brevity...)

Thank you once again for your careful consideration of this document and for
your thoughtful input.  I skimmed quickly through Peter's responses and am
in agreement with what I saw there.  But ultimately the question is this:
"Is it worth revising this document further, given that it is not targeted
for the standards track?"  Why don't we simply freeze it as-is and call it a
day.  I suspect we all have other things we could be working on...

Carlisle.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 Oct 2000 10:07:27 +0200

Carlisle,

My comments are along the lines.

>> I agree that more clearly-defined subsets of the DVCS functionality
>> should be handled by these other protocols (TSP, OCSP, etc.) .. 
>> but this also means that this subset is not the right direction for 
>> the long run and thus should be deprecated. For that reason, this 
>> subset should *not* be placed in an experimental RFC.

> an Experimental RFC.  

Sorry, I do not see any argument for supporting your assertion.

> These other protocols, which differ in some details
> "experimental" work on this same functionality is archived as something
> that was tried but not standardized.

(text deleted) 
 
> Experimental RFC.  DVCS represents something that was conceived,
> discussed, and implemented, but all in quite limited circles.  When it
> comes time to discuss this sort of topic more broadly, this early
> "experimental" work can perhaps serve as a reasonable starting point for
> that discussion.

(text deleted)
 
> Within the IETF environment, what alternatives are there for preserving
> this work?  As you well know, the only archival documents in IETF are
> RFCs, so if we all agree that DVCS is not appropriate for the standards
> track at this time, we are left with Experimental, Informational,
> Historic, and Best Current Practice.  The description for Experimental is
> given in RFC 2026 as follows:
> 
> development (i.e., implementation) effort.  It may be useful as a source
> of information on this topic to at least the Internet technical community,
> if not the broader Internet community.  It makes sense to have an archival
> record of this work, especially if this topic may arise again in the
> future.  I see pretty-much an exact fit between DVCS and the stated
> purpose of the Experimental RFC category.

Let me provide a copy of the text in the next following section of RFC 2026:

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.  The IESG shall review such a referred document
   within a reasonable period of time, and recommend either that it be
   published as originally submitted or referred to the IETF as a
   contribution to the Internet Standards Process.

   If (a) the IESG recommends that the document be brought within the
   IETF and progressed within the IETF context, but the author declines
   to do so, or (b) the IESG considers that the document proposes
   something that conflicts with, or is actually inimical to, an
   established IETF effort, the document may still be published as an
   Experimental or Informational RFC.  In these cases, however, the IESG
   may insert appropriate "disclaimer" text into the RFC either in or
   immediately following the "Status of this Memo" section in order to
   make the circumstances of its publication clear to readers.

   Documents proposed for Experimental and Informational RFCs by IETF
   Working Groups go through IESG review.  The review is initiated using
   the process described in section 6.1.1.

So the first question is whether this document is proposed for Experimental
and Informational RFCs by some individuals or by the PKIX Working Groups. I
am not supportive of presenting this document as a PKIX WG proposal.

The next point, as far as I understand, is that in any case it will go
through IESG review. Should the document be proposed as an Experimental RFC,
the concerns I have might then be brought to the attention of the IESG.

> outside the IETF process.  This can certainly be done, but I must confess
> to having a hard time seeing what value that would serve to the Internet
> community.

All drafts which are submitted do not need to become RFCs (even Experimental
or Informational). There are numerous examples for this. Since it is very
likely that some of the authors of DVCS are going to remain present in the
PKIX working group, parts of this document might be brought up, when
necessary, by one of the authors and alternatively by someone else who saved
the document. Once again, preserving the document does not mandate the
issuance of an Experimental RFC.

> Thank you once again for your careful consideration of this document and
> for your thoughtful input.  

:-)

> I skimmed quickly through Peter's responses
> and am in agreement with what I saw there.  But ultimately the question is
> this:  "Is it worth revising this document further, given that it is not
> targeted for the standards track?"  Why don't we simply freeze it as-is
> and call it a day.  I suspect we all have other things we could be working
> on...

I agree we have other things todo. However, pushing the document to
Experimental RFC would *not* save our time. :-)

Denis