Subject: [newtrk] newtrk not following its charter

From: [email-masked] (Scott Bradner)
Date: Mon, 6 Jun 2005 12:05:50 -0400 (EDT)

One overall statement before starting on the parts of the IESG message
I was told that a number of IESG members (and a few others) complained 
that newtrk was not following its charter (i.e., that ISDs or anything 
like them were not in the charter).

I agree that we have not been foloowing the charter.

What I said during the last two (or more) newtrk sessions was
that I felt that ISDs could significantly lessen the reliance on the
N-stage (with N being 1 between 1 & 3) standards track for RFCs.  Thus I 
felt that it was important to figure out if ISDs (or something like them)
were going to be adopted before doing work on the RFC standards track
that might just be rendered moot.

For example RFC 2026 says about Draft Standard: 
   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  ...

i.e., Draft Standard is a reflection of implementation and
interoperability experience (plus some  IPR licensing stuff we have
never really exercised).  If ISDs include pointers to implementation &
interoperability experience and (through a last call on the ISD) state
that the technology specified by the ISD (or specific parts of it) have
had sufficient implementation and interoperability to be considered
mature to the level of a draft standard.  This can be done in prose
instead of a binary flag - giving the opportunity to more fully explain
the status.  If this were to be the case then we might not need separate
maturity levels on the RFCs themselves.  (or so I felt & feel)

You may disagree with this conclusion but I felt it would be useful to
spell it out.

Scott

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2005 12:38:19 -0400

--On Monday, 06 June, 2005 12:05 -0400 Scott Bradner
<[email-masked]> wrote:

> One overall statement before starting on the parts of the IESG
> message I was told that a number of IESG members (and a few
> others) complained  that newtrk was not following its charter
> (i.e., that ISDs or anything  like them were not in the
> charter).
> 

Well, I disagree.  If a charter, especially for process work, is
interpreted so specifically and narrowly that a re-analysis of
the general problem and an approach that attacks it from a
different direction that the WG believes is more appropriate are
excluded, then we are killing work on narrow procedural grounds
(I could use some other words) and going very far down the path
that Brian described as "judge and jury" and perhaps to "police
and prosecutor" as well.  Now, granted there is a case to be
made that the charter should have been explicitly updated to
include this approach, but the then-responsible AD was certainly
aware of it and at least generally supportive of it.  Had a
charter update been submitted to the IESG and blocked or
stalled, we would have had a different version of a
constitutional crisis, but no mechanism for forward progress.

At the time procedural details become more important in the IETF
than getting working done, we are in bad trouble indeed.  And,
if the procedural details become a mechanism for blocking
getting work done...

    john

.

---

From: John Leslie <[email-masked]>
Date: Mon, 6 Jun 2005 13:25:22 -0400

John C Klensin <[email-masked]> wrote:
> Well, I disagree. 

   I could agree with John here; but I must admit there's room for
argument.

   The charter is too long to reproduce here. Read it yourself if you
haven't recently:

http://www.ietf.org/html.charters/newtrk-charter.html

   IMHO, the essence is that we're supposed to rewrite RFC2026:
" 
" The goal of this working group is to agree on a revised IETF Standards
" Track, taking into consideration the above points, to replace the
" standards track described in RFC 2026.

   It's certainly reasonable to read into that (and what follows) that
work on ISDs is consistent with the charter.

   But please note, Scott said IESG _members_ were questioning whether
this work is on-charter.

   I'm afraid that, if the IESG reads this as not on-charter, it really
makes very little difference how _we_ read it.

   I quite disagree with Scott that it's OK to pursue this even if it's
off-charter: I think we should have IESG agreement that this is on-charter
before going much father.

   (Hopefully, our Area Director at least agrees that it's on-charter.
Scott says _most_ IESG members are subscribed to the list. I'd be very
interested in their opinions as to whether this ISDs are on-charter.)

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2005 14:05:05 -0400

--On Monday, 06 June, 2005 13:25 -0400 John Leslie
<[email-masked]> wrote:

>    But please note, Scott said IESG _members_ were questioning
> whether this work is on-charter.
> 
>    I'm afraid that, if the IESG reads this as not on-charter,
> it really makes very little difference how _we_ read it.
> 
>    I quite disagree with Scott that it's OK to pursue this
> even if it's off-charter: I think we should have IESG
> agreement that this is on-charter before going much father.

See my response to Margaret.   I don't believe we should spend
much more time on the ISD idea if there are clear signals that
the IESG doesn't like it or even that a few IESG members are
just unenthused about it.  Whether "doesn't like" is substantive
or based on interpretation of charters and scope is largely
irrelevant.   Also, because of the nature of the ISD proposal, I
don't think there is any path that involves reaching a consensus
to move forward with which the IESG does not agree: ISDs can
easily be made to fail even if we make a procedural switch to
them.

It seems to me that leaves Newtrk with several choices (other
than beating our heads against the wall):

	(i) Abandon ISDs and go to work on something that will
	make the IESG happy.   Note that the character of the
	IESG responses to ISDs puts us in the position that was
	complained about a good deal during the "Problem"
	effort, i.e., playing "guess what we will accept" with
	the IESG.  In fairness to the IESG, I suspect they don't
	know what they want in this case, so we can practice
	guessing together.
	
	(ii) Make some trivial changes that will get past the
	IESG but probably not change things enough to be worth
	the disruption and transition.
	
	(iii) Give up, drop the effort, and close newtrk.
	
	(iv) Start thinking about ways to change the standards
	process and standards track to produce a system that is
	compatible with an ISD-like model.  I think that would
	require changing, not merely the definition of the
	standards track, but the approval process for standards.
	Whether that is in-scope or not is, of course, another
	interesting issue.

john

.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 06 Jun 2005 12:30:06 -0700

On Mon, 2005-06-06 at 12:38 -0400, John C Klensin wrote:
> > I agree that we have not been following the charter.
> 
> Now, granted there is a case to be made that the charter should have
> been explicitly updated to include this approach, but the
> then-responsible AD was certainly aware of it and at least generally
> supportive of it.

Should there be a review of the charter?

The focus should be on allowing an aggregated use of the RFC documents
be more apparent than provided through the index or 100 series.  I
suspect there is consensus that something is needed in this area.  Bill
Fenner's automatic generation of RFC relationships illustrates the
complexity confronting attempts to resolve a comprehensive list of RFCs
pertaining to a specific endeavor.  I suspect there was also consensus
that this should be done using XML templates as a means to define these
relationships.

It seems there should be reluctance having another document add
explanations, or clarifications of information contained within any RFC.
The RFC should remain the authoritative document to prevent added
complexity.  Something that resembles an RFC seems possibly counter
productive.

Making sense of related RFCs requires diligence, working with references
that also need checked in various ways.  While all of this is possible,
it remains clumsy.  Some changes could relate to adopting a practice of
formulaic links for both errata and perhaps a new status database
referenced from some RFC set.  This status could include
interoperability.  Interoperability changes over time, as does what is
considered adequate.  This aspect of an evolving practice seems to need
an ongoing dialog, rather than a description that can not hold up over
time.  Perhaps this more flexible status could eventually supplant the
present standards process.

A utilitarian use of the ISD approach (RFC set), could be distilled into
generic XML templates that join together RFCs into simple categories,
such as core, extensions, experimental, etc.  While some may not view
that as a substantial document, it still provides a means to pull
together RFCs into coherent sets.  That set, combined with a dynamic
status database, could form the ground work for an evolution into more
formalized standardizations.  These structures and status, once refined
though use, could then perhaps supplant RFC2026.

Allow people to becoming familiar with these RFC sets and status in a
painless fashion by offering it as extensions to the features of the
IETF web site.  These features would be auto-generated from the ISD XML
files.  These XML structures could be initially created by scripts
similar to the one used by Bill Fenner, and then manually repaired as
needed.  By not having _any_ unique text other than labels themselves
included in an ISD, this structure should be rather straight forward to
implement and understand.  If this proves untenable, scrap it.

Would such an approach be okay, or not enough?

-Doug 

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2005 16:08:30 -0400

--On Monday, 06 June, 2005 12:30 -0700 Douglas Otis
<[email-masked]> wrote:

>...
> Allow people to becoming familiar with these RFC sets and
> status in a painless fashion by offering it as extensions to
> the features of the IETF web site.  These features would be
> auto-generated from the ISD XML files.  These XML structures
> could be initially created by scripts similar to the one used
> by Bill Fenner, and then manually repaired as needed.  By not
> having _any_ unique text other than labels themselves included
> in an ISD, this structure should be rather straight forward to
>...

Doug,

First, my opinion, which follows, doesn't count for much.  I
think the ISD idea is basically dead, but would encourage those
who still believe in it, or some subset of it, to pursue that
and see what they can come up with.  

That said...

One of the key goals for the ISD series, since the first
incarnation of the idea nearly a decade ago, was to try to get
us away from "this whole thing is either at level X or it isn't"
(where X is "proposed", "draft", "standard") and, in more recent
years, away from the "every 't' must be crossed and 'i' dotted,
at exactly the right height and angle" view of proposed
standards, permitting, instead, making an accessible public
record of "this isn't quite right, but it is good enough for
Proposed" or even "this particular feature is still
controversial, implement and deploy with care" statements and
moving on.   In all of these cases, in a perfect world, we'd
must make the needed fixes to the RFCs.  But the amount of
process required to do that is precisely 
one of the factors that has gotten us into our "things take so
long that they aren't relevant when finished so people have
little choice but to implement from I-Ds or ignore the IETF
entirely" situations.

If one views an ISD as a collection of links only, one gives up
those goals.  That might be ok, but...

Even Bill's amazingly useful work can't show degrees and
intensity of connections: one can get to "these are related" or
"those are dependent", but not to any qualitative description of
the relationship.  There is considerable value, IMO, in such
qualitative descriptions, indeed they are another major argument
for ISDs rather than an expanded version of the STD-index.  For
existing documents, I believe that precisely the right thing to
do is to build on Bill's processing and then patch/ correct/
revise when doing so is needed and the energy exists.  But there
is, it seems to me, a huge value proposition going forward in
telling WGs that part of their job (not the IESG's job) is to
explain, in ISD text, how whatever they are proposing to
standardize fits, in context, with relevant other standards and
IETF work.

Just my opinion.

    john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 6 Jun 2005 15:21:18 -0500

> But there

I could not agree more ... for what that's worth.

Spencer

.

---

From: mcr <[email-masked]>
Date: Mon, 06 Jun 2005 16:32:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "John" == John C Klensin <[email-masked]> writes:
    John> 	(iii) Give up, drop the effort, and close newtrk.
	
    John> 	(iv) Start thinking about ways to change the standards
    John> process and standards track to produce a system that is
    John> compatible with an ISD-like model.  I think that would require
    John> changing, not merely the definition of the standards track,
    John> but the approval process for standards.  Whether that is
    John> in-scope or not is, of course, another interesting issue.

  I just re-read the charter.
  (Btw, it looks like it is in <PRE>, and has a poor cut&paste job...)

  Frankly, I can't conceive of any other solution other than ISD.
  It looked to me that ISD was in-charter.

The sense of the room at the end of the newtrk BOF was that:
    1/ some change was needed to the IETF Standards Track	  <- YES
    2/ a revised standards track should have more than one stage  <- YES
                                  
    3/ there should be some form of "working group snapshot,"..
	     <- ISD, with a lower publication standard does the trick.

    4/ at least one stage should require multiple interoperable
	     <- documented in ISD rather than with DS.

    5/ any revised standards track should include some type of "IPR hook"
       
I have no idea how #5 can be accomplished.  I can go on for along time
about what I think about IPR, and how our process essentially issues
"get out of jail free" cards, but this isn't the place.

So, unless someone has a really solid idea about (iv), I'd say (iii).

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [
.
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: Mon, 06 Jun 2005 18:03:30 -0700

On Mon, 2005-06-06 at 16:08 -0400, John C Klensin wrote:

> the relationship. 

The difference between "in perfect agreement" and "good enough"
describes the difference between the goals of science and engineering.

There is some qualitative value offering simple categories under a
general endeavor.  As mentioned, there would be core, extensions,
experimental, and perhaps obsoleted RFCs, grouped together into a set to
indicate somewhat qualitative relationships.  The status of the RFC-set
could add further qualifications when needed.  RFC-set category
information will likely be manually derived.

Eventually, as some experience is gained as to what is often needed to
amend the RFC-set information, this structure can be refined.  The
status information can also transition from being free-form into highly
structured, once it is determined how this information is used.

> There is considerable value, IMO, in such qualitative descriptions,
> indeed they are another major argument for ISDs rather than an
> expanded version of the STD-index.

The XML structure being described is a significant departure from merely
an expanded STD-index.  It represents enough added information to
warrant technical review. (Less than need for an RFC hopefully.)

> For existing documents, I believe that precisely the right thing to 

Borrowing from the ISD structure, there would be {name.number} that
would reference the RFC-set.  The stature defined by current practices
could be noted in the links.  In addition, there would be a Status
reference link to a database that augments this information.  Stature
information tends to be out-of-date and does not clarify how the RFCs
are being used.

Take advantage of automation needed to support the IETF web site.  Add a
standardized prefix to indicate work-in-progress by a WG.  Something
along the lines of {Xnumber-} where the number in the prefix indicates
the number of attempts by a WG to modify such a document.  Once the
RFC-set XML file is adopted, it would increment the number in
{name.number} portion.  It would be helpful to relax the reference rules
in the {Xnumber-name.number} to permit auto-updated links to IDs, as
well as RFCs.  Acceptance of the  {Xnumber-name.number} as 
{name.number+1} would require that all IDs be accepted as RFCs.

The text of what is being done should remain the exclusive duty of the
RFC and not the RFC-set.  To know what the RFC-set is about, read the
core RFCs.  To get an idea as how it all fits together, review the
RFC-set.  Let the RFCs speak for themselves, but allow the Status
information augment this information by relating present
interoperability, as example.

-Doug

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2005 22:20:05 -0400

Doug,

It may be just weakness of mind on my part, but I can't figure
out what you are talking about in sufficient detail to know
whether I think we are close to agreement or not.   It feels
like you have a clear picture, but the way in which you are
describing it sounds like handwaving to someone who isn't using
your precise vocabulary.    Any change of your quickly
generating an I-D that is a bit more specific about this,
defines what you are talking about, etc.

Or perhaps I'm the only one with this problem.

    john

--On Monday, 06 June, 2005 18:03 -0700 Douglas Otis
<[email-masked]> wrote:

>> If one views an ISD as a collection of links only, one gives
>> up those goals.  That might be ok, but...
>> 
>> intensity of connections: one can get to "these are related"
>> or "those are dependent", but not to any qualitative
>> description of the relationship. 
> 
> There is some qualitative value offering simple categories
> under a general endeavor.  As mentioned, there would be core,
> extensions, experimental, and perhaps obsoleted RFCs, grouped
> together into a set to indicate somewhat qualitative
> relationships.  The status of the RFC-set could add further
> qualifications when needed.  RFC-set category information will
> likely be manually derived.
> 
> Eventually, as some experience is gained as to what is often
> needed to amend the RFC-set information, this structure can be
> refined.  The status information can also transition from
> being free-form into highly structured, once it is determined
> how this information is used.
> 
> 
>> There is considerable value, IMO, in such qualitative
>> descriptions, indeed they are another major argument for ISDs
>> rather than an expanded version of the STD-index.
> 
> The XML structure being described is a significant departure
> from merely an expanded STD-index.  It represents enough added
> information to warrant technical review. (Less than need for
> an RFC hopefully.)
> 
> 
>> For existing documents, I believe that precisely the right
>> thing to  do is to build on Bill's processing and then patch/
>> correct/ revise when doing so is needed and the energy
>> exists.  But there is, it seems to me, a huge value
>> proposition going forward in telling WGs that part of their
>> job (not the IESG's job) is to explain, in ISD text, how
>> whatever they are proposing to standardize fits, in context,
>> with relevant other standards and IETF work.
> 
> Borrowing from the ISD structure, there would be {name.number}
> that would reference the RFC-set.  The stature defined by
> current practices could be noted in the links.  In addition,
> there would be a Status reference link to a database that
> augments this information.  Stature information tends to be
> out-of-date and does not clarify how the RFCs are being used.
> 
> Take advantage of automation needed to support the IETF web
> site.  Add a standardized prefix to indicate work-in-progress
> by a WG.  Something along the lines of {Xnumber-} where the
> number in the prefix indicates the number of attempts by a WG
> to modify such a document.  Once the RFC-set XML file is
> adopted, it would increment the number in {name.number}
> portion.  It would be helpful to relax the reference rules in
> the {Xnumber-name.number} to permit auto-updated links to IDs,
> as well as RFCs.  Acceptance of the  {Xnumber-name.number} as 
> The text of what is being done should remain the exclusive
> duty of the RFC and not the RFC-set.  To know what the RFC-set
> is about, read the core RFCs.  To get an idea as how it all
> fits together, review the RFC-set.  Let the RFCs speak for
> themselves, but allow the Status information augment this
> information by relating present interoperability, as example.
> 
> -Doug
> 
> 
> 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jun 2005 12:02:00 +0200

One front comment and one tail comment (and yes, I have
read the rest of the thread).

Front comment (AD hat on): the charter is a tool. If the tool is
blunt, we'll sharpen it. In plain English, if the charter is no longer
appropriate, the WG can propose an updated version to me, and if I
agree I will take it to the IESG.

> You may disagree with this conclusion but I felt it would be useful to

Tail comment (AD hat off): I don't completely agree, which is
why I wrote draft-carpenter-newtrk-twostep-00.txt. I think the step
from "interoperability not proved" to "interoperability proved" is
important, may sometimes require a new RFC, and is in any case a
change of status. Now that change of status could indeed be
signalled only by an update to an ISD, but my feeling from earlier
discussions was that people seemed to want a formal change of
the status of the RFC. Personally, I don't feel that's
absolutely required, but I've come to believe recently that we
need to decide this at the same time as we define a workable ISD-like
mechanism. Decoupling the two questions, as Scott hoped we could
do, seems to have led to more confusion than it avoided.

    Brian

.

---

From: mcr <[email-masked]>
Date: Tue, 07 Jun 2005 17:21:01 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> why I wrote draft-carpenter-newtrk-twostep-00.txt. I think
    Brian> the step from "interoperability not proved" to
    Brian> "interoperability proved" is important, may sometimes require
    Brian> a new RFC, and is in any case a change of status. Now that

  I agree.

    Brian> change of status could indeed be signalled only by an update
    Brian> to an ISD, but my feeling from earlier discussions was that
    Brian> people seemed to want a formal change of the status of the
    Brian> RFC. Personally, I don't feel that's absolutely required, but
    Brian> I've come to believe recently that we need to decide this at
    Brian> the same time as we define a workable ISD-like

  My experience with IPsec (three revisions now, plus two revisions of
SKIP), IKE (in second revision), and DHCP is that we never show
interoperability on the whole document.
  As such, this is one place that the ISD really is nice.

  Revising it takes a long time, and "as long as the document is open"
occurs a lot. 

  Look at IKEv2:
  Many proposed to rewrite the IKEv1 documents to a single sane
document. (no on-the wire changes)
  "That would take too long" was the answer. Well, we are done finally,
about 2.5-3 years after the rewrite was proposed.  We seem to
continuously put off simple things (small, incremental steps), because
they might get in the way of completing a complex thing. The complex
thing is never completed on time, and the result is that anyone wanting
the simple extension, has to implement to the ID.

  Had we had ISDs, we would have simply declared in an ISD, that whole
sections of IKEv1 had never been tested/interoperated.  We could have
removed them from the IKEv1-prime document, which could have progressed
at the same time as IKEv2 things.  The IETF consensus for the ISD
content would have guided the rewrite, because it would have made each
item more explicite.

  The same thing would have helped a lot, I think, with rfc2401bis.

  As for the ISD just being a set of links... that's okay, if they links
have meta-data. Having not read the XML DTD at all, I'll make something up.

     <STATE RFC="2401" PARA="3.4" STATUS=DS INTEROPREPORT="4134">

  That works for me, really.

- -- 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jun 2005 13:59:20 +0200

>   That works for me, really.

In your view, would it make sense to have only *two* standards track
actions?

1. Approve a document as a Proposed Standard (or BCP).
[of course this can be a revised document obsoleting a previous version]

2. Accept an ISD as factually accurate (with respect to interoperability,
dependencies, and errata).
[the words were chosen carefully]

    Brian

    Brian

.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 10:23:01 -0400

> maturity levels on the RFCs themselves.  (or so I felt & feel)

more 2026 for background:
   For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used. [...]

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed. [...]

Several issues:
1. is the intent of the multi-stage process merely to document issues
   during progression, or "to make the Internet work better" (RFC 3935)
   by encouraging interoperability at the system component level?
2. is the purpose of the multi-stage process to improve the clarity
   of the specifications only, or does improvement of the underlying
   protocol, format, etc. described by the specification play any role?
3. is there value (in terms of making the Internet work better) in
   removing unused features (which may represent potential security
   loopholes) as opposed to merely documenting which features are
   unused (or worse, saying nothing at all about implementation of
   unused features)?

I believe these issues are important ones, and are relevant whether or
not the number of steps in the standards track are changed, and may
be relevant to the nature of ISD documents (as those have been described
as documenting interoperability).

I further believe that the 2026 text may be ambiguous, based on my
understanding of how the IESG interprets 2026.  My understanding is
that the IESG uses interoperability reports not to gauge the quality
of the underlying protocol/format/etc., but the clarity of the
specification, and that that clarity is judged based on independent
consideration of individual features rather than functional
equivalence at the system component level.  I.e. given a hypothetical
specification with two BCP 14 imperatives:
  MUST do X
  MUST NOT do Y
and three independent implementations:
  A: does X, does Y
  B: does not do X, does not do Y
  C: does X, does not do Y
while there are not two functionally equivalent implementations, the
clarity of the specification is judged to be sufficient for Draft
Standard status because there are two implementations meeting the
first requirement (viz. A & C), and two implementations meeting the
second imperative (B & C).  This is related to issues 1 & 2 above.

In practice, it's not clear that removal of unused features is
considered; that relates to issue 3 above.  I know of at least one
case where an unimplemented feature known to cause confusion was
retained in a specification on advancement to Draft Status.

The point of this message is not to take issue with particular IESG
decisions, but to engage a discussion about the underlying values
that we believe should be present in the standards Track whether
the number of steps are changed and whether or not some new document
series is devised.  I believe we need to agree on those goals before
we can undertake a revision of the process which is supposed to lead
to those goals.

To recap, the issues are:
1. documentation of interoperability status vs. encouraging interoperability
2. progression of specification only, or of underlying practice
3. degree of concern for removal of confusing or potentially harmful
   unused provision during progression
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 9 Jun 2005 19:43:55 -0700 (PDT)

> [the words were chosen carefully]

This is a variant two step proposal, with the first step similar to
the existing PS, but with the second step being very different from
the existing DS.

In my view this would make a lot of sense, particularly for MIB
documents.

A problem that frequently arises is that we can't put new object
definitions into a MIB module if we want to advance it along the
standards track.  When new objects are required -- which will surely
be the case for MIB modules that manage an evolving technology such
as Ethernet -- our current choices are to put the objects in an
existing MIB module, and not advance it along the standards track,
or to put the new objects into a supplemental MIB module, which can
result in confusion by scattering of related objects into multiple
modules, particularly when there are several rounds of updates, each
with a small number of objects.

A related problem is that we are required to deprecate objects that
are not present in at least two implementations in order to advance
a MIB module along the standards track, even if if can be reasonably
anticipated that the objects will eventually enjoy multiple
interoperable implementations.

One example:  the EtherLike-MIB (RFC 3635) and MAU-MIB (RFC 3636)
have recycled at proposed several times over the years owing to the
presence of new objects needed to support newer flavors of Ethernet.
The Ethernet Interfaces and HUB MIB working group made the decision
that it was more important to have the functionality in a coherent
set of MIB modules than it was to advance these MIB modules along
the standards track.  Ironically, most of the objects in these MIB
modules have been widely implemented, and some date back to the
early 1990s.  However, there is currently no mechanism to document
that fact.  The proposal above would provide such a mechanism.

Another example:  the ENTITY-MIB working group recently decided not
to advance that MIB module to Draft Standard because doing so would
have required deprecating some objects that were in the process of
being implemented.  A mechanism to permit partial advancement would
have been ideal in this case, especially since the implementation
report that was collected could have provided the necessary
justification for that action.

I would very much like to see the variant two-step proposal
described above fleshed out.  Although it would involve ISDs, it
would NOT entail extra work at the initial stages.  And since it
would permit interop to be documented incrementally, which would
be a lot more rational than our current all-or-nothing approach.

Mike Heard

.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 10 Jun 2005 12:05:35 -0700

> ....  Ironically, most of the objects in these MIB

Could this requirement be met by having a better way of
documenting interoperability on a module-by-module basis,
independent of the standards track?

Certainly not all "newtrk" requirements can be met by improved
reporting tools, but perhaps some can.

Larry

.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 10 Jun 2005 16:28:49 -0700 (PDT)

> independent of the standards track?

Something like that.  What I was thinking of was a means to document
interoperability on an object-by-object (or group-by-group) basis,
much as is done in the following implementation reports:

http://www.ietf.org/IESG/Implementations/ifmib-implementation.txt
http://www.ietf.org/IESG/Implementations/RFC2558-Implementation.txt
http://www.ietf.org/IESG/Implementations/RFC2021-Implementation.txt
http://www.ietf.org/IESG/Implementations/RFC2613-Implementation.txt
http://www.ietf.org/IESG/Implementations/RFC2493-Implementation.txt

These reports were made for advancing to DS, but there is no reason
why something of that nature could not be done in an ISD for a
module where only some of the objects or groups enjoyed multiple
implementations.  Having the report, I think, is much be more useful
than the formal step of advancing to DS, and I'd like to see it done
more often than it is.  Replacing DS with this:

% 2. Accept an ISD as factually accurate (with respect to interoperability,
% dependencies, and errata).

would allow that to happen.

Mike Heard

.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 10 Jun 2005 16:54:00 -0700

You know, I wonder if it is really the case that the IESG does,
or can, "assess an ISD as factually accurate (with respect to
interoperability)".

In one case, when I complained about an "interoperability report"
being inaccurate and misleading, I was told fairly clearly that
the IESG had no process for independently evaluating interoperability
reports (or assertions about independent exercise of licensing
process) and they just took people at their word.

So perhaps the problem with "Draft Standard" is that it
doesn't actually represent any real assessment, and a
more informal mechanism of allowing individuals to make
(more clearly identified) assertions about interoperability
would match reality better.

That is: eliminate Draft Standard. Have Proposed Standard
and Standard. For Proposed Standard, create some informal
mechanism for individuals to post assertions about
implementation, interoperability testing, intellectual
property and independent licensing. (With the individuals
making those assertions clearly identified.)

This would allow for finer grained, and more useful information
to the implementing community.

Larry

.