Subject: RE: [newtrk] web pages for RFCs

From: <[email-masked]>
Date: Fri, 13 May 2005 10:04:54 +0300

Hi Larry,

I originally proposed something like this, not for RFCs, but for
protocols.  A sort of one-stop shopping for protocols on the web.
If you wanted to know about SMTP, there would be a page with info
about the RFCs, which are current, which are obsolete, etc. It could
also link to other related documents.

I thought that we discussed this already in NEWTRK that while
this might be valuable, it doesn't solve the problem about providing
a stable reference, that it couldn't be used in RFPs, etc.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Larry Masinter
> Sent: 13 May, 2005 09:47
> To: 'Bruce Lilly'; 'NEWTRK'; 'Hallam-Baker, Phillip'
> Subject: [newtrk] web pages for RFCs
> 
> 
> Maybe this belongs on the 'tools-discuss' list instead?
> I wonder how much of 'newtrk' discussion is really
> trying to solve problems that could be addressed
> without process changes but with a few more tools?
> 
> Personally, I think we would be better to have
> a (automatically generated) web page for every RFC
> that will tell you about the status of that RFC:
> 
> (pointer to) errata for the RFC
> Status of RFC (Standards track, historical, etc.)
> Pointer to other RFCs and standards actions that affect
>   this RFC (updates, obsoletes)
> 
> (possibly) pointer to any "roadmap" RFCs that put
> this one in context, or ISDs.
> 
> (possibly) pointer to (charter of) working group
> which developed the RFC, if any
> 
> pointer to mailing list archive for mailing list that
> discussed this RFC.
> 
> pointer to any IPR statements that specifically
> mention this RFC.
> 
> All of the information should be specific to THIS
> RFC, not a pointer to some general list that you
> have to search to figure out what does and doesn't
> apply.
> 
> And then we could add to the RFC boilerplate
> "for information about the status of this
> RFC, please consult 
>    <URI for this RFCs status>
> 
> The status pages don't have to be automatically
> generated on the fly, they could easily be
> batch generated whenever information changes.
> 
> Larry
> 
> 
> 
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2005 14:52:10 +0200

Nevertheless, my personal opinion is that a web structure like
that would be enormously beneficial (and would make it easy
to generate a list of relevant RFCs to use as stable references
in RFPs).

That's why I keep harping on about the fact that
http://www.rfc-editor.org/rfcxx00.html is close, but
made unfit for that purpose because it recognizes rather than
ignores the 3 stage process.

    Brian

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 May 2005 13:19:31 -0400

> ignores the 3 stage process.

Brian,

<tirade>
I continue to consider the notion that we do not "finalize" a
standard until there is implementation and deployment experience
the _key_ differentiator between the IETF and its products and a
number of products of other bodies which we often, and with some
justification, deride.  Those groups have historically believed
that standards can be developed on paper, without benefit of
implementation testing, then reviewed, refined, and approved by
professional standardizers whose expertise is in process and
methods of review, rather than subject matter.  Those beliefs,
and the resulting products, have resulted in a long series of
marketplace failures (because the ideas could not be implemented
in practice at costs consistent with likely ROI, independent of
how potential consumers felt about them).   They, and the
"working groups and projects last forever" policies they spawn,
are also wonderful at producing second- (and third and fourth)
system effects in standards development: even when the initial
specs are of decent quality, subsequent ones tend to become a
laundry list of everyone's ideas for improvements, without a
solid engineering basis and requirements for inclusion, followed
by "interoperability profiles" in the hope of holding things
together.

I note that neither we, nor our esteemed colleagues at ISO or
ITU, are actively using MHS/X.400 mail, International Standard
Page Description Language, etc., for distribution or discussion
of evolving standards and much less are they products or
development models anyone is pushing.

To the extent to which the IETF is determined to go down their
path, I think there is a strong case to be made that we should
just give it up instead.  I fear that is exactly where we are
headed, as the IESG (and other factors) get more insistent on a
"get things right the first time and do it by desk-checking
rather than by implementation and deployment" model, the RFC
Editor process drags the time between approval and publication
out, and everyone runs out of incentive to advance documents for
any of a dozen reasons.  I see no reason to try to compete with
the ITU or ISO on their own turfs and with their own style of
standards-development and decision-making: as the ITU frequently
points out, they have well over a century of experience leading
up to doing things the way they do them.  If we are convinced
that is the right way, or that the less-government-centered ISO
system is the right way, let's just join them rather than trying
to reinvent what they are doing.  

I am not convinced that their models are the right ones, but
maybe I'm stuck in earlier times and represent only a minority
voice.
</tirade>

Now, I actually don't know if we disagree or not.  I believe
that the current three-level system was much better adapted to a
world in which the complexity level of the typical standard was
much lower and in which the length of time between designer or
WG agreement (whatever that meant at various times) and RFC
publication was quite short.   I can't see looking at a fairly
new and complex standard and saying "well, every bit of this is
qualified for full standard", at least without gutting the
thing.  Empirically, attempts to do things that way have, in the
last several years, largely been failures.  I think we need to
use finely-tuned and, if necessary, subsection-specific, prose
to describe the status of a standard, not broad, but largely
undifferentiated, categories.  That concern was the key thing
that started me down the path toward the ISD draft (John L
started from somewhere else, but we rapidly converged).  

So, we both agree, I think, that the existing "maturity level"
model needs drastic revision.

However, I believe that, if we give up the more general idea
that documents that are untested by implementation and
deployment are fundamentally different from, and inferior to,
documents that have benefited from, and reflect, both, then I
think we would have given up something that is essential to the
role and position of the IETF.  There I'm not certain if we
agree or not.

    john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 13 May 2005 20:38:49 -0500

> any of a dozen reasons.

I agree with JohnK, and note that this portion of JohnK's note maps 
very well onto our experience with process reform as well - trying to 
"desk-check" process improvement just kills any hope of doing anything 
(look no further than ICAR for an excellent example of what happens 
when we take a good idea about how to do something important and 
torture it to perfect death, but ICAR's not the only example, by a 
long shot).

Spencer 

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 14 May 2005 11:05:37 -0500

>>>>>> "Spencer" == Spencer Dawkins <[email-masked]> writes:
>
>    Spencer> I agree with JohnK, and note that this portion of 
> JohnK's
>    Spencer> note maps very well onto our experience with process
>    Spencer> reform as well - trying to "desk-check" process
>    Spencer> improvement just kills any hope of doing anything (look
>    Spencer> no further than ICAR for an excellent example of what
>    Spencer> happens when we take a good idea about how to do
>    Spencer> something important and torture it to perfect death, but
>    Spencer> ICAR's not the only example, by a long shot).
>
> I don't think that is a fair description of ICAR from where I sit.

Hi, Sam,

I wrote the text in Section 3 of 
http://bgp.potaroo.net/ietf/all-ids/draft-klensin-process-july14-01.txt 
that got dropped, so we could move to RFC 3933, but I thought it was 
accurate (just not worth the candle of getting it published as an 
RFC).

I saw ICAR as starting with something like what SIR was trying to do a 
year earlier. I believe in better reviews, supported SIR (I'm still 
listed as a reviewer), supported ICAR, and attended/scribed for almost 
every ICAR meeting, and when we got to the end, we didn't have 
reviews, reviewers, or a plan that was working to find reviewers.

I admire Joel and Mark for taking ICAR on (I would have agreed to take 
it on, if asked, but they did a better job than I could have done), 
but my read was (and continues to be) that polishing without 
experience doesn't take us to a happy place in process improvement, 
and I noticed that this matched JohnK's read that polishing without 
experience doesn't take us to a happy place in protocol work, either.

If I've misrepresented JohnK's read, my apologies, and I hope Joel and 
Mark understand that I didn't intend any criticism of either them or 
anyone else who supported ICAR/improved reviews. In my previous 
posting, I typed, but then deleted, "The problem isn't the people, 
it's the process." I wish I'd left that in.

Other people's mileage may vary, of course.

Thanks, and have a great weekend.

Spencer 

.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 14 May 2005 16:03:24 -0400

>>>>>>> "Spencer" == Spencer Dawkins <[email-masked]>
    Spencer> I agree with JohnK, and note that this portion of JohnK's
    >>  I don't think that is a fair description of ICAR from where I

    Spencer> Hi, Sam,

    Spencer> I wrote the text in Section 3 of
    Spencer> http://bgp.potaroo.net/ietf/all-ids/draft-klensin-process-july14-01.txt
    Spencer> that got dropped, so we could move to RFC 3933, but I
    Spencer> thought it was accurate (just not worth the candle of
    Spencer> getting it published as an RFC).

    Spencer> I saw ICAR as starting with something like what SIR was
    Spencer> trying to do a year earlier. I believe in better reviews,
    Spencer> supported SIR (I'm still listed as a reviewer), supported
    Spencer> ICAR, and attended/scribed for almost every ICAR meeting,
    Spencer> and when we got to the end, we didn't have reviews,
    Spencer> reviewers, or a plan that was working to find reviewers.

    Spencer> I admire Joel and Mark for taking ICAR on (I would have
    Spencer> agreed to take it on, if asked, but they did a better job
    Spencer> than I could have done), but my read was (and continues
    Spencer> to be) that polishing without experience doesn't take us
    Spencer> to a happy place in process improvement, and I noticed
    Spencer> that this matched JohnK's read that polishing without
    Spencer> experience doesn't take us to a happy place in protocol
    Spencer> work, either.

OK.  My disagreement is not so much with what you wrote above but with
a causal link between publishing without experience with ICAR and
ICAR's failure.  I think ICAR's problems are that we don't know how to
find reviewers and possibly we don't know how to get the right people
to ask for reviews.

No amount of publishing or not publishing seems likely to fix ICAR
until we find answers to these questions.

--Sam

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 May 2005 11:14:24 +0200

(Replying directly to John - I will read the follow-ups
later)

John C Klensin wrote:
...
> model needs drastic revision.

yes

> role and position of the IETF.  There I'm not certain if we

I agree with that too.

What I've been thinking for a while is that our current process
is kind of sticky, i.e. has friction points, and that's
why we don't exercise it often enough. So (takes deep breath)
the model I'm straining towards is one where we *decouple*
the acceptance of interoperability reports from the notional
status of a particular RFC.  And the web page, or the ISD,
or whatever it turns out to be, says "The interop report X
documents the interoperable features of RFCs P, Q, and R."

(In case it isn't clear, this is me speaking, not the IETF
Chair or the IESG.)

     Brian

.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 May 2005 17:45:27 -0700

>  I think ICAR's problems are that we don't know how to
>

SIRS had no problem getting reviewers.

The problem in both cases is that we gave up after a few months of effort, as 
if this sort of strategic/cultural change can be instantly mandated.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

.