Subject: [newtrk] 3rd meta question

From: [email-masked] (Scott Bradner)
Date: Wed, 22 Jun 2005 10:27:11 -0400 (EDT)

This question was suggested by our AD.

1/ Could we implement something like ISDs (or some other meta document
describing a "standard") without revising RFC 2026?

Or is it time to bite the bullet and attack RFC 2026 (its already been
attacked in some part since section 10 has been superceded by RFCs 3978
& 3979)?

2/ When (not if, it will happen someday) RFC 2026 gets revised should it
become a series of topic-specific documents instead of an omnibus
document?  (e.g. reassimilate RFCs 3978 & 3979 into a single document)

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

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 22 Jun 2005 14:20:29 -0400

> describing a "standard") without revising RFC 2026?

Probably -- std-index.txt lists RFCs which comprise a standard.  STD 1
(RFC xx00) also does so.  Unfortunately, the documents don't always
agree.  On the other hand, while STD 1 is an RFC and presumably is subject
to the RFC 2026 procedures, it's not clear what official status if any
std-index has.  Some clarification of that matter in a 2026 successor
might be nice.

> attacked in some part since section 10 has been superceded by RFCs 3978

As noted separately, some parts of 2026 probably need clarification and/or
reinforcement, particularly the implementation documentation requirements
for Draft Standard.

> document?  (e.g. reassimilate RFCs 3978 & 3979 into a single document)

Separation -- if a sensible and largely orthogonal set of topics can be
formulated -- might make revisions simpler.   On the other hand, cross-
references might be more difficult (though if all documents are suitable
for BCP status and BCP numbers are assigned, reference could use the BCP
numbers).  There are, for example, a couple of known issues with the IPR
boilerplate that probably warrants a further revision of that boilerplate.
My preference would be a set of largely orthogonal BCPs.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Jun 2005 13:28:01 -0700

> describing a "standard") without revising RFC 2026?

Yes, as described in the rough draft, this could be done by establishing
an RFC-Set references using XML linkages.  With these references, a
contemporaneous database could organize this data.  This data could be
the genesis for a more formalized structure within the database, once
what information found useful becomes apparent.  Once this information
gets structured and administrated, then eventually this could impact RFC
2026. 

> attacked in some part since section 10 has been superceded by RFCs 3978

If there was bandwidth to take on this task, this would be good.  My
fear is this will be seen as too much too soon without seeing something
that would approximate the end result, until a great deal of effort was
expended.  The idea behind the XML linkages is that much of this
structuring could be fairly automatic.  Because very little information
would be added beyond the linkages, this should require minimal review.
It still must be reviewed, but not as much as the larger scale effort
would require.

> document?  (e.g. reassimilate RFCs 3978 & 3979 into a single document)

There may be methods more useful for highlighting the relevant RFCs and
to also offer additional information that could be more timely than a
what might be seen as rather rigid in comparison. Eventually we may
arrive at the same destination, but knowing where you want to go would
be easier if the RFC-Sets were organized.

-Doug

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Jun 2005 13:21:39 +0200

> describing a "standard") without revising RFC 2026?

Yes.

> attacked in some part since section 10 has been superceded by RFCs 3978

No.

> document?  (e.g. reassimilate RFCs 3978 & 3979 into a single document)

Yes, it should become a series of documents. I'll go out on a limb and say 
that some of them (including the one that provides the index to all the 
currently valid ones) should not be RFCs.

Note that I think "ISD" for the toplevel document is also a bad solution 
(see earlier discussion), but some of the same reasons as for why ISDs 
should not be RFCs apply.

.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Jun 2005 05:08:14 -0700

>  describing a "standard") without revising RFC 2026?

anyone can generate a document with isd content.

such a document could reasonably be issued as informational or bcp.

neither action requires modifying formal IETF rules.

the purpose of modifying the formal IETF rules would be to change 
*requirements*.

>  document?  (e.g. reassimilate RFCs 3978 & 3979 into a single document)

divide-and-conquor?  modularization?

what an idea!

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

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 25 Jun 2005 23:51:49 -0500

(There aren't any more admission controls on process mailing lists 
than there are on Internet Drafts, but I digress...)

> describing a "standard") without revising RFC 2026?

Sure. As Crocker pointed out, an I-D can say anything, and the IESG 
can certainly approve an I-D that says, "this is what TCP is, as 
practiced in the IETF".

Do I think this is smart? No. There are already too many I-Ds and too 
many RFCs. But we could do it.

> attacked in some part since section 10 has been superceded by RFCs 

<ravemode>

Why are we so reluctant to change the documented standards process to 
match what we are actually doing? The three-stage standards process 
has failed to become the common code path in the IETF. No one 
challenges this, but you can't tell it from our documented process. 
Periodic review of proposed-standard and draft-standard specifications 
has NEVER happened in the IETF - but it has been mandated by our 
documented standards process since RFC 1310 (March 1992).

Our documented process misled every new IETF participant who started 
after IETF 23. The smart ones learned what to ignore and moved on.

And yet we are amazed that people don't trust the standards process 
leadership ("black helicopter with IESG markings sighted, film at 
11").

Why don't we tell participants what we actually DO?

</ravemode>

> document?  (e.g. reassimilate RFCs 3978 & 3979 into a single 

While I note that IPR is a problematic topic (and not just in the 
IETF), I also note that we have been through two revisions of the 2026 
IPR revisions so far, and may have another one coming. I think this 
means people are actually reading the new BCPs, trying to do business 
as documented, encountering issues, and proposing text to resolve the 
issues. I would expect more of this if 2026 splinters further. I think 
this is actually good (see previous rave on what it's like when we 
just ignore the inconvenient parts of our process and move on).

I feel sorry for anyone who tries to figure out what our process  is 
when it's spread across a few more RFCs without an ISD that ties it 
together in one place, of course, but that's not the question Scott 
asked. 

.

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 26 Jun 2005 09:47:32 -0400

On Sun June 26 2005 00:51, Spencer Dawkins wrote:

> match what we are actually doing?

Probably for the some of the same reasons that a certain country hasn't
changed its constitution to match what the current regime is actually
doing.

Freedom of speech, no established religion, due process, etc. are
specified by that country's constitution and are principles which are
supported by the vast majority of that county's citizens.  In theory,
that constitution could be amended to match what the current regime is
actually doing -- locking people whose religion or ethnicity or speech
is inconvenient to the regime in power away in concentration camps on
occupied foreign soil without due process -- but that would be
inconvenient because it would require obtaining support for those
policies which are in conflict with the principles that are supported.
It's much simpler for the regime to simply do as it pleases; the appeals
process is so onerous and sluggish that the regime will have had its
way before any effective action could be taken. 

Now analogies are OK for illustrating points, but often fail if taken
too literally.  So please don't take that analogy too literally.
The point is simply that changing principles isn't always the best
approach, or the easiest approach to implement, to resolve discrepancies
between the principles and observed practice.

I would have no objection in principle to an Informational RFC
documenting what the IESG is currently doing which differs from the
documented, approved, consensus-based standards process, provided
it is clear that consensus approval of such a document is clearly
specified and understood to mean that there is agreement that that
is in fact what the IESG is doing, not what the community wants
the IESG to do.  That precludes any statements of "why", as the IETF
at large isn't in a position to determine why the IESG does what it
does, but can reasonably determine what it in fact does or does not
do.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 28 Jun 2005 15:53:06 -0400

Speaking for myself (as opposed to, say, for my cat):

> attacked in some part since section 10 has been superceded by RFCs 3978

I think it's exactly the right issue to address, though
not for the mechanical reasons.

If such a meta-document is going to have any more (perceived)
weight than "interesting non-authoritative commentary", then
it must go through AN ietf review process and AN ietf
approval process.  And that either means it fits within the
processes and document types defined in RFC2026, or
RFC2026 needs to be updated.

Personally, I think we have a crying need for meta documents
(there is a URI roadmap document with my name on it in
the pile of long-since expired I-D's).

But I also believe that the decision has to be made upfront:

If they are truly intended to be lightweight, we (collectively)
must work to keep them as such, and have them perceived as
such.  (I'm somewhat dubious about this -- think about what
"RFC" stands for/is perceived as, etc...).

Otherwise, we should bite the bullet, and be explicit in
integrating them in our IETF processes.

And no one should be left guessing about which outcome is
selected.

Leslie.

.

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jun 2005 08:19:27 -0400

While I am trying to mostly stay out of this discussion because
I continue to believe that ISDs are dead, at least in the
absence of more significant and basic reforms...  and speaking
for myself rather than my rubber ducky or pet rathole expert...

I think Leslie is exactly correct.

I would add that we already have, and have had, a selection of
"interesting non-authoritative commentaries", most of them in
the form of books that combine reprints of selected RFCs with
author opinions about how they relate and what they ultimately
mean.  Some of them have even been useful to some populations.
We have made it clear, when we have had the opportunity, that
neither the commentaries nor the selections of materials are
authoritative.  But, whatever those collections have
accomplished, it is fairly clear to me that they have not made a
significant contribution to getting standards produced.

Over the years, there have been discussions about slightly more
authoritative tutorials or summaries of standards-track
materials and how they hung together to be prepared as some
combination of IETF and ISOC efforts.  I still favor those ideas
in principle, although the questions of how to prevent the
summaries from being substituted in the mind of the public for
the standards themselves (i.e., considered authoritative) and of
how to get the work done, and done well, remain (and are among
the reasons the idea has never gotten off the ground).

The moment we Last Call an ISD --as the WG draft on the table
explicitly required-- we are modifying the standards process.
Conversely, to treat an ISD as authoritative without a Last Call
seems fraught with dangers.

     john

.