Subject: [Pppext] removing the milestones

From: James Carlson <[email-masked]>
Date: Tue, 23 Nov 2004 08:34:05 -0500 (EST)

I've had a request to remove our stale milestones from the list.  I
agree, and I'm sending mail to the AD and secretariat now.

Essentially, we have a null list of goals and milestones at this point
and are effectively dormant.

Below are my notes on the existing list of milestones.  If you have
any interest in restoring these with new target dates, or would like
to have new milestones added, please speak up.

> Dec 99	  	Advance AODI draft to Proposed Standard

There's been no activity on this draft in quite some time, and I don't
expect it to end up advancing.

> Dec 99	  	Advance CHAP (RFC 1994) to Standard
> Dec 99	  	Advance Multilink (RFC 1990) to Standard
> Dec 99	  	Advance LQM (RFC 1989) to Standard
> Dec 99	  	Advance IPCP (RFC 1332) to Draft Standard
> Dec 99	  	Advance CCP (RFC 1962) to Draft Standard
> Dec 99	  	Advance ECP (RFC 1968) to Draft Standard
> Dec 99	  	Advance PPP over ISDN (RFC 1618) to Draft Standard
> Mar 00	  	Advance LCP MIB (RFC 1471) to Draft Standard
> Mar 00	  	Advance CHAP MIB (RFC 1472) to Draft Standard
> Mar 00	  	Advance IPCP MIB (RFC 1473) to Draft Standard

These could be advanced, but it would take some minor work to do the
documentation necessary, and it's not clear that there's substantial
value in it.

> Dec 99	  	Add VLAN support to BCP (RFC 1638) and recycle at Proposed Standard

This milestone has been achieved: RFC 2878 obsoleted 1638.

-- 
James Carlson, IP Systems Group?               <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 23 Nov 2004 09:25:38 -0800

James Carlson <> wrote:

> Essentially, we have a null list of goals and milestones at this
> point and are effectively dormant. 
> 
> There's been no activity on this draft in quite some time, and I
> don't expect it to end up advancing. 
> 

I find this an extremely interesting statement, esp. coming from a
WG chair.  You seem to be saying that there is doubtful value in
advancing a document beyond Proposed Standard, essentially
dismissing the most of the IETF standards process as irrelevant.
This is particularly interesting (and somewhat distressing) since
Draft Standard is, I believe, the only level that requires evidence
of interoperability...

> 
>> Dec 99	  	Add VLAN support to BCP (RFC 1638) and
recycle at Proposed
>> Standard 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

---

From: James Carlson <[email-masked]>
Date: Tue, 23 Nov 2004 12:40:04 -0500

> dismissing the most of the IETF standards process as irrelevant.

We need people who are interested in doing the work necessary for
advancing those documents.  It's been months since I called to see if
anyone was interested in stepping up to do that work, and there's been
no response.

I'm not dismissing the standards process as "irrelevant."  Those are
your words, not mine.

What I did say was that it wasn't clear whether advancing the
documents (after so many years has passed) has any substantial value
for anyone consuming the documents.  I don't know that it does.

> Draft Standard is, I believe, the only level that requires evidence

True.  And, as I said before, someone has to speak up to take
ownership of a document of interest, or it's just going to stay at
that maturity level forever.

In the meantime, it's just silly for us to have milestones listed that
expired five years ago.  I'd like to put down new dates for those, but
if there's nobody working on them, then there's no plausible date that
I can put on them.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 23 Nov 2004 13:19:14 -0500

> for anyone consuming the documents.  I don't know that it does.

I think I understand what Glen is saying.  If implementing product based
on documents at Proposed Standard is "good enough" for the industry, why
would anyone ever expend the extra energy to advance a document to Draft
Standard of Full Standard?

I also understand that the IETF cannot compel work, so if there is
currently no interest...

-- Dave

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 23 Nov 2004 10:27:01 -0800

James Carlson <mailto:[email-masked]> wrote:

...

> 
> I'm not dismissing the standards process as "irrelevant."  

That's nice to hear.

> Those are

Note that I wrote "You seem to be saying..."; less an attribution of
meaning than a somewhat oblique query thereof.

> for anyone consuming the documents.  I don't know that it does. 

Just to be fair, there seems to be a _very_ thin line between
lacking "substantial value" and irrelevance.

> that maturity level forever.  

OK, what work needs to be done on the documents (aside from the MIBs
which probably need editing to comply w/the new boilerplate, etc.)?

> 
> In the meantime, it's just silly for us to have milestones listed
> that expired five years ago.  

True.

> I'd like to put down new dates for
> those, but if there's nobody working on them, then there's no
> plausible date that I can put on them.   

Hope this helps,

~gwz

---

From: James Carlson <[email-masked]>
Date: Tue, 23 Nov 2004 14:25:45 -0500

> Standard of Full Standard?

That's a fair question, and I don't have a good answer for it.

> I also understand that the IETF cannot compel work, so if there is

Yep.

> lacking "substantial value" and irrelevance.

Maybe.  I see the distinction as being whether anyone is willing to do
the (non-trivial) testing and (likely trivial) documentation required
to the work.  That's the substantive part.  It's not irrelevant; it's
just (apparently) not of enough value, or we'd have volunteers.

> which probably need editing to comply w/the new boilerplate, etc.)?

It looks like this:

   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.

Someone needs to show that two implementations (A) implement all of
the options and features and (B) that the options and features work
together.  I then get the task of 'documenting' these implementations
and citing them to the Area Director as a reason to advance the
standards process for that document.

I suspect that this is likely to be 'hard' for some cases, as some
implementation either don't have all the features or don't have any
way to control the features.  It may mean writing new drafts and
*removing* sections that either nobody implements, or not enough
people agree on.  I don't think it's zero effort.