Subject: netwrk stuff

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 19:28:24 -0400

I can't believe that I just raised my hand after "who is willing to  
work on this tomorrow"... But here is the abstract, let me know if I  
should write the rest:

RFCs are published as Informational, Proposed Standard or  
Experimental. This represents the confidence level the IETF/IESG has  
at the moment of publication. Irrespective of I/PS/E, a document may  
move to Standard (which replaces Draft Standard and Internet  
Standard) or Historic if its implementation and deployment warrant  
this. The IESG publishes a short note explaining the rationale when  
changing designations.

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jul 2006 19:36:35 -0400

On Jul 12, 2006, at 7:28 PM, Iljitsch van Beijnum wrote:

> Experimental. This represents the confidence level the IETF/IESG  
> has at the moment of publication. Irrespective of I/PS/E, a  
> document may move to Standard (which replaces Draft Standard and  
> Internet Standard) or Historic if its implementation and deployment  
> warrant this. The IESG publishes a short note explaining the  
> rationale when changing designations.

Seems mostly reasonable.

I do believe that there is value in the BCP status, and would add it  
to the above. PS presumes that we are testing something, like a  
protocol, while BCP presumes that we are stating something that is  
believed to be true now but might become untrue and need to be  
reconsidered in the future, like a policy.

I would also argue in favor of the "Historic" status. Documents are  
rarely published as historic, although it has happened (RFC 1716).  
But they should be allowed to become historic at some future date.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 02:40:13 +0300 (EEST)

On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote:
> I can't believe that I just raised my hand after "who is willing to work on 
> this tomorrow"... But here is the abstract, let me know if I should write the 
> rest:
...

I'm not sure if Brian was serious about writing, as there are numerous 
proposals already [1], every one of them simplifying the current 
situation.  Having half a dozen _more_ choices probably would not help 
in figuring how to go forward.

[1] hit 'newtrk' in I-D tracker [2]. My personal favourite is 
draft-atkinson-newtrk-twostep-00.txt, which seems to strike a good 
balance between stripping out useless process but keeping at least 
some features (revision based on implementation experience, etc.) 
which at least I have found useful.

[2] there are even more expired ones..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 22:00:39 -0400

On 12-jul-2006, at 19:36, Fred Baker wrote:

>> Internet Standard) or Historic if its implementation and  
>> deployment warrant this. The IESG publishes a short note  
>> explaining the rationale when changing designations.

> I do believe that there is value in the BCP status, and would add  
> it to the above.

Yes, that makes sense.

> But they should be allowed to become historic at some future date.

Sure, I wasn't saying anything to the contrary, except that I didn't  
include publishing as historic, which I hope should be rare.

On 12-jul-2006, at 19:40, Pekka Savola wrote:

> I'm not sure if Brian was serious about writing, as there are  
> numerous proposals already [1], every one of them simplifying the  
> current situation.

Yes, but spending tons of time in netwrk is exactly part of the  
problem. I took his talking about it in the plenary to indicate that  
a different way forward is desireable. That's why I posted just a few  
lines rather than read drafts and then write one of my own.

> [1] hit 'newtrk' in I-D tracker [2]. My personal favourite is draft- 
> atkinson-newtrk-twostep-00.txt, which seems to strike a good  

Yes, there is a lot of good stuff in there, including the two-step  
standards track. Can someone explain the complexity in the tradeoffs  
between having one, two or three steps that was alluded to in the  
meeting?

However, the problem I have with that draft is that it still tries to  
formalize the progression of documents. We heard "declare success" a  
lot and "declare failure" once or twice tonight, and I'd like to take  
this opportunity to do both:

1. The internet works: success
2. Few specifications mature to Internet Standard: failure

Since the current rules prevented a lot of progressing of  
specifications but at the same time there doesn't seem to be a  
negative effect on the operation of the internet, it looks like these  
rules don't accomplish anything. So get rid of them. All of them. The  
IESG is full of smart people who are more than competent enough to  
decide on the fate of a document without a long list of rules to  
follow in doing this. When they get it wrong once in a blue moon, the  
last call and appeal processes should take care of that.

And while we're at it, let's cut down on all the documents that  
accompany the actual specifications. I'm not saying they're all  
worthless, but many applicability documents seem to exist because of  
formalities rather than because they contain crucial information that  
couldn't be put anywhere else. As a "user" of RFCs in the years  
before I got involved in the IETF I generally ignored these  
documents. The protocol specifications is where it's at. So extra  
documents when they add something, but don't require them.

Also, it's not by accident that people remember RFC numbers and not  
STD numbers. There is a big difference between implementing RFC 822  
and implementing RFC 2822. Saying you have implemented STD 11 is  
useless because a year from now STD 11 may be something different  
than it is today, while RFCs 822 and 2822 will still be the same.  
That's why I think it's useful to have some IESG notes accompany each  
RFC. This can be a simple "updates XXX, obsoletes YYY, obsoleted by  
ZZZ" or more text that describes certain issues where required. This  
removes one or two layers of indirection in determining a document's  
status.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 05:11:43 +0300 (EEST)

On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote:
> Since the current rules prevented a lot of progressing of specifications but 
> at the same time there doesn't seem to be a negative effect on the operation 
> of the internet, it looks like these rules don't accomplish anything. So get 
> rid of them. All of them. The IESG is full of smart people who are more than 
> competent enough to decide on the fate of a document without a long list of 
> rules to follow in doing this. When they get it wrong once in a blue moon, 
> the last call and appeal processes should take care of that.

At least the way I heard in the plenary, people underlined that most 
folks make little difference between maturity levels.  So the above 
model wouldn't probably buy us much but instead would make the IESG 
make do more work.  The more important feature seems to be revision 
based on implementation, interoperability and deployment experience 
which is demonstrated with an implementation/interoperability report.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Jul 2006 09:50:43 -0400

On 12-Jul-06, at 19:28 , Iljitsch van Beijnum wrote:

> work on this tomorrow"... But here is the abstract, let me know if  
> I should write the rest:
>

I also like this basic proposal.
I feel there is good value in indicating to people which documents  
have clearly succeeded, which have clearly failed, and which  
documents are still indeterminate (= the jury is still out). I have  
been asked by employers to prepare documents describing this for  
various protocols in the past.

- Philip

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Jul 2006 10:15:44 -0400

>this. The IESG publishes a short note explaining the rationale when 

Without a very explicit set of rules for the PS -> S transition, this 
is not much better than what we have today. Protocol developers will 
still want to get "their" protocol into the S state, regardless of 
demand from vendors or customers.

Moving PS -> H seems reasonable, but is the effort of defining and, 
more important, implementing PS -> S worth the benefit of having some 
things have a special status?

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jul 2006 00:06:12 -0700

Paul Hoffman wrote:
>> move to Standard (which replaces Draft Standard and Internet Standard)
>> or Historic if its implementation and deployment warrant this. The
>> IESG publishes a short note explaining the rationale when changing
>> designations.
> 
> Without a very explicit set of rules for the PS -> S transition, this is
> not much better than what we have today. Protocol developers will still
> want to get "their" protocol into the S state, regardless of demand from
> vendors or customers.

We need to ask what "problem" might be solved, by having an additional maturity
level, beyond Proposed?  The problem needs to be something that is actually
useful to solve.

As I said at the plenary (and before) my own favorite is our serious lack of
tracking, to determine what IETF work actually gets used. We have no regular,
formalized method for assessing success or failure.

Hence it would be useful both to us and to the rest of the Internet community,
to have a status that acknowledges that an IETF standards effort has reached
"substantial" community adoption and use.

We can quibble about the criteria for "substantial" separately.  The key point
is having a status that is determined by market penetration, rather than
technical details.  Proposed is for the technical work.  Full is for market success.

By way of providing some incentive, I suggest that Proposed have a limit, such
as 3 or 5 years (and, yes, we can quibble about that, too.) If the work cannot
gain sufficient adoption by the end of that time, it has failed and warrants
moving to Historic.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Jul 2006 07:36:30 -0700

>gain sufficient adoption by the end of that time, it has failed and warrants

Fully disagree. If there is "some implementation but not enough" it 
should remain "proposed". Otherwise, vendors will hesitate to 
implement protocols that might eventually make them look silly ("why 
does the box include the FrobzBaz protocol when everyone knows that 
it is Historic?").

This leads to two designations: Proposed and Full. An implementer 
looking at a Proposed standard would assess how long it has been out 
and which other implementers have put it in competing products to 
assess whether they want to put it in theirs. Things labelled Full 
standard would probably be put in by default.

Vendors really do care about this. They don't want to look bad for 
including the "wrong" features, and they don't want to look bad for 
not including popular ones. I regularly get calls from VPNC members 
asking about whether or not they should implement various standards, 
both in the positive sense ("is it worth paying an OEM to include 
this?") and in the negative sense ("will we look silly if we include 
this, even though it is in the standard?").

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jul 2006 15:06:06 -0700

Paul Hoffman wrote:
>> By way of providing some incentive, I suggest that Proposed have a limit,
>> such as 3 or 5 years (and, yes, we can quibble about that, too.) If the 
>> work cannot gain sufficient adoption by the end of that time, it has failed
>> and warrants moving to Historic.
> 
> should remain "proposed". Otherwise, vendors will hesitate to implement
> protocols that might eventually make them look silly ("why does the box
> include the FrobzBaz protocol when everyone knows that it is Historic?").

That sounds like an extremely reasonable concern, except for all the empirical
evidence to the contrary.

Vendors do not look silly by being aggressive in providing new features.

And they take risks about the future, formal approval and market-wide acceptance
of a technology all the time.

> looking at a Proposed standard would assess how long it has been out and
> which other implementers have put it in competing products to assess
> whether they want to put it in theirs. Things labelled Full standard
> would probably be put in by default.

So, we are in agreement about having 2 levels and having the second one be based
on market acceptance?  Our disagreement is about deprecating Proposed specs that
have not reached Full after a period of time.

Note that we already have this policy, although it applied erratically by the
decade, not mechanically by the year.

ALso as you worry about incentives, note that automatic deprecation provides an
incentive for those asserting community need to prove it and to do the proving
in a timely fashion.  (What specifications have failed to gain significant
adoption after, say, 5 years but have, nonetheless, become "successful"?)

> including the "wrong" features, and they don't want to look bad for not
> including popular ones. 

I've never seen one that was faulted for having extra features, no matter their
"formal" status.

I regularly get calls from VPNC members asking
> about whether or not they should implement various standards, both in
> the positive sense ("is it worth paying an OEM to include this?") and in
> the negative sense ("will we look silly if we include this, even though
> it is in the standard?").

The best I can guess is that anyone worrying about looking silly, for having
extra features, probably is new to the marketing game or is hopelessly naive
about their product space.

d/

-- 

  Dave Crocker

---

From: "todd glassey" <[email-masked]>
Date: Sat, 22 Jul 2006 06:51:55 -0700

Dave -
----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Friday, July 21, 2006 3:06 PM
Subject: Re: netwrk stuff

> >> and warrants moving to Historic.

The question as to why that initiative's process was stalled would have to
be answered to be fair. One would have to take into consideration whether
the underlying technologies were the issue, those undertaking the effort
abandoned it, or whether it was the WG and AD who had failed to properly
marshal their WG Vetters to complete this effort.

Since the IETF has said it needs to be smart about what projects and
initiatives it undertakes, then it should want as much assurance up-front as
possible. That said when a formal project is proposed it should be well
enough defined and documented, and have commitment formally from those who
are the core of the Initiative's Vetting Team.
.
There is also a disconnect I think (IMHO) in thinking that it takes an
entire WG to approve some protocol - "the ONLY people who should have to
approve the protocol are those involved inside of the development of the
protocol project". Allowing others to cast votes which effect whether that
initiative is advanced creates a condition where one group can tortuously
interfere with another's IETF Standard's initiative, and having personally
been a victim of this I assure you it happens.

The issue here is just in making it such that anyone who is willing to step
to the plate and commit hours to the vetting process should be allowed to.
Also the folks to implement the protocol-interoperability ports should be
committed WHEN THE PROJECT IS ORIGINALLY SUBMITTED *(did I say that loud
enough?). A plan for the vetting and fabrication of the reference ports for
interoperability testing should be put in place to assure the IESG that the
proposal is 'properly funded and staffed outside the IETF ' - two key
requirements for successful completion of an IETF initiative these days.

> > include the FrobzBaz protocol when everyone knows that it is
Historic?").

Paul's probably right - but so is Dave. The real issue I think is how the
IETF wants to be perceived and which classes of End-User customers it wants
to focus on. Which is to say - that it would make more sense to unify the
Standards Vetting Process and to define it such that one could select
different types of vetting models inside the IETF's Processes. Also
cafeteria
style.  This would address BCP's and RFC's for Standards alike.

> Vendors do not look silly by being aggressive in providing new features.

True -

> of a technology all the time.

Especially if those differentiate them as being more and better that their
competition.

> > whether they want to put it in theirs. Things labeled Full standard

I think the way to address whether deprecation is some level of use in the
world. Set a use minimum for any protocol - and anyone that falls below that
use level - is deprecated. This way the IETF active standards track the
Internet's tastes and desires since it is the Internet that the IETF is to
track... But rather than true deprecation - lets just change their names to
"Reference and Active" Standards. Reference are any non-active Standards.
Active Standards are those that are voted (did I really say that?) by the
IESG to track the Industry's use.

This review should be done annually at one of the meetings as a process
model and the level of penetration of any protocol needs to be factored into
the equation somehow.

>
> Note that we already have this policy, although it applied erratically by

In closing  lets put blame for a failed project where it belongs... in the
WG Chair's
lap. I think there is a fundamental failing in the mindset of the IETF and
that is that "the failings of the WG Vetters to come to consensus documents
the failure of the WG Chairs  for not better controlling their resources or
projects".

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Jul 2006 07:24:19 -0700

On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote:

> The question as to why that initiative's process was stalled would
> have to be answered to be fair. One would have to take into
> consideration whether the underlying technologies were the issue,
> those undertaking the effort abandoned it, or whether it was the WG
> and AD who had failed to properly marshal their WG Vetters to complete
> this effort.

The completion of documents, and the closing of WGs remains within the
competence of the IETF.  Beyond describing the intended use and the
vetting initially achieved, there is little benefit derived revisiting a
document unless a change is required.  When a change is required, the
affected document should be marked as updated or replaced, where again
the intended use and the vetting initially achieved should once again be
noted.

Designations of Experimental seems to be an indication of a vetting
level.  BCP versus Information also seems to be an indication of a
document having undergone different vetting.  Clarify the initial
vetting (the related confidence the organization is willing to initially
signify). This clarification can be conveyed by noting the intended use.
Conveying how popular a particular document has become in subsequent
years has proved either outside the competence or the concern of the
IETF.

While as a matter of pride the IETF may wish to place accolades upon
popular documents, such efforts will likely be a distraction and provide
little benefit.  These efforts could be seen as attempting lead the
parade by running in front of the crowd.  While popular documents are
indicative of having done a good job, very few documents involving
popular use remain static.  

> initiatives it undertakes, then it should want as much assurance
> up-front as possible. That said when a formal project is proposed it
> should be well enough defined and documented, and have commitment
> formally from those who are the core of the Initiative's Vetting Team.
...

Is there some benefit derived revising documents where the intended use
has not changed?  Those deploying applications based upon these
documents will separately publish their own conclusions by way of
call-outs.  The IETF has made the call-out process difficult, and this
should be improved.   

> I think the way to address whether deprecation is some level of use in
> the world. Set a use minimum for any protocol - and anyone that falls
> below that use level - is deprecated. This way the IETF active
> standards track the Internet's tastes and desires since it is the
> Internet that the IETF is to track... But ratwould need toher than
> true deprecation - lets just change their names to "Reference and
> Active" Standards. Reference are any non-active Standards. Active
> Standards are those that are voted (did I really say that?) by the

This seems to suggest competency and popularity are synonymous.  There
should be at least four levels maintained by industry when using these
documents.

1) Current (development)
2) Stable (production)
3) Deprecated (still supported)
4) Obsolete (not supported)
   
Current is simply the latest.  This output may never become designated
as being Stable.  Stable indicates few issues are unresolved by several
implementations.  Deprecated indicates modes or features will no longer
be supported in future versions. Obsolete indicates that interchange is
no longer assured.

It seems the industry and not the IETF should make these
classifications.  The results of interchange testing is the determining
factor and this is not an area handled by the IETF.  There will always
be a company that does something different.  If company X happens to
have a large install base, how does that affect the ratings?  There
could be separate ratings indicated by company X.

> This review should be done annually at one of the meetings as a
> process model and the level of penetration of any protocol needs to be
> factored into the equation somehow.

Why?  What would be the benefit?  What information is used?

> In closing  lets put blame for a failed project where it belongs... in
> the WG Chair's lap. I think there is a fundamental failing in the
> mindset of the IETF and that is that "the failings of the WG Vetters
> to come to consensus documents the failure of the WG Chairs for not
> better controlling their resources or projects".

The lack of substantial benefits for pursuing a meaningless
administrative effort may explain the mindset.  Instead, the IETF should
attempt to facilitate a call-out that can easily track Current, Stable,
Deprecated, or Obsolete by each company or distribution.  Many of these
protocols involve a compilation of many RFCs.  Using an overlay as
described by the SRD draft, for example, would allow a
Name.Serial-number approach where there would be real benefits derived.

Focus on describing the intended use and providing a serialized
reference to track the evolution of the change process.  Don't spend any
time going from three levels to two or one.  The industry must be
allowed to track at least four levels of use, but leave this to the
industry.  The IETF should simply attempt to facilitate this tracking
and clarify the intended use.

-Doug