Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread RJ Atkinson

On 05  May 2011, at 12:13 , The IESG wrote:
 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Reducing the Standards Track to Two Maturity Levels'
  draft-housley-two-maturity-levels-06.txt as a BCP
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. 

Yes, please, and as soon as possible.
This is very long overdue.

Many thanks to Russ H for being patient and persistent on this topic.

Yours,

Ran Atkinson


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave Cridland

On Thu May  5 18:31:33 2011, Dave CROCKER wrote:



On 5/5/2011 10:22 AM, Dave Cridland wrote:
On balance, whilst I appreciate the aims of this document, I think  
the proposals

are not suitable for adoption.

1) This document radically lowers the quality of Proposed  
Standards.



What, specifically, are the parts of the proposal that you believe  
will lower the quality of a Proposed Standard?


The parts unmentioned in the document, in effect.

It states:

2.1. The First Maturity Level: Proposed Standard


  The stated requirements for Proposed Standard are not changed; they
  remain exactly as specified in RFC 2026 [1].  Various influences  
have

  made publishing a Proposed Standard much harder than the stated
  requirements in RFC 2026.  The intention of the two-tier maturity
  ladder is to restore practice to the requirements for Proposed
  Standard from RFC 2026, and stop performing more scrutiny than
  intended in IETF working groups and the IESG.  No new requirements
  are introduced; no existing published requirements are relaxed.

RFC 2026 essentially defines a PS document as being a first cut,  
likely to change, and as such unsuitable for production deployment.  
In particular:


  Implementors should treat Proposed Standards as immature
  specifications.  It is desirable to implement them in order to gain
  experience and to validate, test, and clarify the specification.
  However, since the content of Proposed Standards may be changed if
  problems are found or better solutions are identified, deploying
  implementations of such standards into a disruption-sensitive
  environment is not recommended.

So this clearly states that should we revert to RFC 2026, then we  
should immediately consider that HTTP, IMAP, and XMPP, for instance,  
should not be deployed in disruption-sensitive environments. Are you  
really sure that's what you think our consensus opionion is? It  
certainly isn't mine.


I don't think this reflects the current status quo in the slightest.  
I think our current PS maturity is essentially considered production  
quality, although we anticipate that clarifications in the  
specification may be required, and consultation with other  
implementors is likely to be beneficial.


In particular, for better or worse, the wider internet technical  
community - ie, the people who are aware of, but not involved in, the  
IETF - expect our PS documents to have high quality, and would be  
caught unawares by a sudden shift back to this stance.


So to make this clear, I think that as the requirements and scrutiny  
of PS documents have increased, the quality has as a result, and -  
undoubtedly more important - the expected quality has also. I am  
suprised that you don't see this as quite apparent.


We have, in general, raised the bar over the years for PS documents,  
and - whether or not you think this was a good idea - this horse has  
left the station, and it's too late to put the lid back on - the  
wider world now expects this.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Dave Cridland

On Thu May  5 23:47:50 2011, Dave CROCKER wrote:

Folks,

On 5/5/2011 11:33 AM, Scott O. Bradner wrote:
As I have stated before, I do not think that this proposal will  
achieve

anything useful since it will not change anything related to the
underlying causes of few Proposed Standards advancing on the  
standards

track.



We currently have a standards process that largely ignores two of  
its stages.




That's part of the story. It's not a complete observation, though.

We have a standards process that is four stage, not three, and a  
first step should be to document what we're doing. That's how we work  
- we document running code.



At the least, our community should be embarrassed about this cruft  
and should want to streamline things and make them more likely to  
be fully exercised.




No. The minimum is that we should be embarrassed about the cruft.

It is a trivial observation that we do not follow RFC 2026, and we  
should ensure that we have a standards process we actually follow.


   1. The criteria for the second stage are significantly clarified  
and rely exclusively on actual adoption and use (again, modulo some  
important nuances.) Whatever happens with the practice of getting  
to Proposed, this should make it more predictable and easier to get  
to (Full) Internet Standard, based solely on actual success of the  
specification.




More predictable is good. Easier? I'm not sure.

But the real problem I have is the phrase hidden away in the above -  
Whatever happens with the practise of getting to Proposed. You're  
not seriously intending to put forward another document which  
defines our standards process yet not expecting anyone to follow  
it, are you?


   2. The model is cleaned up, in my opinion significantly.  This  
improves transparency of the process a bit.  Also, I think Draft  
made sense when our whole endeavor was less mature and we needed to  
help the community understand what is needed for achieving  
interoperable deployments.  Today we need the /practice/ of interop  
efforts, but we do not need it in the formal process, as  
demonstrated by how few specs get to Draft in spite of becoming  
entirely successful community services.[1]




I'll go along with this one.


   3. The changes are likely to remove bits of community confusion  
about the IETF standards labels.  Not entirely of course, because  
people are creative. But the proposed changes make a very clean  
distinction between the initial technical work and the later  
adoption/deployment/use work.




This one is hysterically funny.

To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk).

  4/ there seems to be a reinforcing feedback loop involved: vendors
 implement and deploy PS documents so the IESG tries to make the  
PS

 documents better

This is the core issue, which far from addressing, the proposal tries  
to discard the feedback loop, stick its fingers in its ears, and sing  
la-la-la-I'm-not-listening.


The fact remains that vendors treat PS maturity RFCs as standards.  
By reverting to the letter of RFC 2026, this will undoubtedly  
increase confusion - indeed, it's apparent that much of the deviation  
from RFC 2026 has been related to this very confusion.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducingthe Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread t.petch
I oppose publication of this as an RFC.

It is about politics, not about technical matters, and politics is the art of
the possible.  Even if this
proposal succeeds in persuading (most of) the IETF to rethink the meaning of
'Proposed Standard',
its impact on the rest of the world will be nil.  The rest of the world will see
more 'Proposed Standard's and will assume that they have been produced with the
same care, consideration and review as in the past decade.  Which will be a
mistake.

If you must have a new lightweight, 'back-to-the-2026' offering, then the name
must make it clear that that is what it is and any use of the word 'Standard'
for it would be wrong, regardless of the original intention of RFC2026.  Rather
it should be along the lines of 'Prototype Specification' or Experimental or
Preliminary or ...

Tom Petch

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread John Leslie
Dave Cridland d...@cridland.net wrote:
 
 To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk).
 
   4/ there seems to be a reinforcing feedback loop involved: vendors
  implement and deploy PS documents so the IESG tries to make the  
  PS documents better
 
 This is the core issue, which far from addressing, the proposal tries  
 to discard the feedback loop, stick its fingers in its ears, and sing  
 la-la-la-I'm-not-listening.

   Please excuse the hyperbole -- Dave's just trying to get our attention.

 The fact remains that vendors treat PS maturity RFCs as standards.  
 By reverting to the letter of RFC 2026, this will undoubtedly  
 increase confusion - indeed, it's apparent that much of the deviation  
 from RFC 2026 has been related to this very confusion.

   Nothing we put in a rfc2026-bis will change this. Nothing we put in
a rfc2026-bis _CAN_ change this.

   If we want to change this, we need to start putting warning-labels
in the _individual_ RFCs that don't meet a ready for widespread
deployment criterion.

   (I am speaking neither for nor against two-maturity-levels here:
warning-labels need to happen if we expect to change implementors'
expectations of PS RFCs.)

--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Eliot Lear
Jari, and others,

I support this draft with the caveat that we can establish a set of
significant metrics that provide us an understanding as to the impact of
the change.

Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Dave Cridland

On Fri May  6 11:44:48 2011, John Leslie wrote:

Dave Cridland d...@cridland.net wrote:

 To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing  
newtrk).


   4/ there seems to be a reinforcing feedback loop involved:  
vendors
  implement and deploy PS documents so the IESG tries to make  
the

  PS documents better

 This is the core issue, which far from addressing, the proposal  
tries
 to discard the feedback loop, stick its fingers in its ears, and  
sing

 la-la-la-I'm-not-listening.

   Please excuse the hyperbole -- Dave's just trying to get our  
attention.



I concede that the draft neither has fingers nor sings; the point  
remains valid however.



 The fact remains that vendors treat PS maturity RFCs as  
standards.

 By reverting to the letter of RFC 2026, this will undoubtedly
 increase confusion - indeed, it's apparent that much of the  
deviation

 from RFC 2026 has been related to this very confusion.

   Nothing we put in a rfc2026-bis will change this. Nothing we put  
in

a rfc2026-bis _CAN_ change this.


I'm in total agreement with this, which is why I'm so against a  
proposal which exacerbates the issue.



   If we want to change this, we need to start putting  
warning-labels

in the _individual_ RFCs that don't meet a ready for widespread
deployment criterion.


I do not believe this will work, actually.

In general, I think boilerplate warning messages get ignored - people  
quickly learn to expect and ignore them as routine - and I don't  
think we're likely to be able to construct unique and varying warning  
messages for every RFC we publish.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Jari Arkko
As the sponsoring AD for Russ' draft, I'm very interested in hearing 
what everyone thinks about this. Please keep those comments coming! The 
last call was started as it was felt that discussion may have converged 
enough so that we could perhaps move forward with this proposal, or at 
least agree that its harmless and does not stand in the way of other 
improvements that some people may wish in addition. We'll see what the 
consensus will be. I can also see that some specific changes have 
already been discussed. Thanks for all those suggestions.


But I also wanted to provide my own opinion. I would like to see the 
draft adopted. I personally do not believe that it will make a very 
significant change by itself; to a large extent the two (or even one) 
level model is already the running code. However, it does make the 
process a bit easier and it does allow us to get rid of at least some of 
the cruft from the IETF process. I think it is very important to 
simplify the process and align process documents with actual practice, 
as these will make it easier to describe, use, and evolve the IETF 
process. There are plenty of IETF process problems to address, even if 
this draft moves forward.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread John Leslie
Dave Cridland d...@cridland.net wrote:
 On Fri May  6 11:44:48 2011, John Leslie wrote:
 
 If we want to change this, we need to start putting  
 warning-labels in the _individual_ RFCs that don't meet
 a ready for widespread deployment criterion.
 
 I do not believe this will work, actually.

   It is at least a step which _might_ work...

 In general, I think boilerplate warning messages get ignored -
 people quickly learn to expect and ignore them as routine -

   It's not fair to compare this to government-warnings on
cigarette packs.

   However, I agree that if warning-labels look like boilerplate,
folks will ignore them.

 and I don't think we're likely to be able to construct unique
 and varying warning messages for every RFC we publish.

   I offer as evidence the quite-limited warning-labels that the
IESG may put on RFCs that are not IETF series RFCs. These happen
routinely and seem to be accomplishing their intent.

   And, if I may speculate, we might consider warning-labels
that refer readers to status pages maintained by area teams to
show progress on issues not (yet) resolved at the time of
publication.

   There _are_ things worthy of trying here.

--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave CROCKER



On 5/6/2011 1:31 AM, Dave Cridland wrote:

On Thu May 5 18:31:33 2011, Dave CROCKER wrote:

1) This document radically lowers the quality of Proposed Standards.


What, specifically, are the parts of the proposal that you believe will lower
the quality of a Proposed Standard?


The parts unmentioned in the document, in effect.

It states:

...

The stated requirements for Proposed Standard are not changed; they
remain exactly as specified in RFC 2026 [1].

...

RFC 2026 essentially defines a PS document as being a first cut, likely to
change, and as such unsuitable for production deployment. In particular:



You appear to be saying that the new document lowers quality by continuing to 
use the same basic criteria and qualifiers for Proposed that we've used for many 
years.


Forgive me, but I do not understand how that logic works.  How can the new 
process document lower quality by holding the established criteria for Proposed 
stable?


It appears that your actual concern is not about the new document, but rather 
the existing process specification (RFC 2026).



d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Andrew Sullivan
On Fri, May 06, 2011 at 08:08:54AM -0700, Dave CROCKER wrote:
 
 The parts unmentioned in the document, in effect.
 ^^^

 You appear to be saying that the new document lowers quality by
 continuing to use the same basic criteria and qualifiers for
 Proposed that we've used for many years.

I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation ought to be made to match.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Scott Brim
Dave: the issue is that PS was previously not seen as a finished product,
now it has much more exalted status, but the criteria have not changed.
On May 6, 2011 11:09 AM, Dave CROCKER d...@dcrocker.net wrote:


 On 5/6/2011 1:31 AM, Dave Cridland wrote:
 On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
 1) This document radically lowers the quality of Proposed Standards.

 What, specifically, are the parts of the proposal that you believe will
lower
 the quality of a Proposed Standard?

 The parts unmentioned in the document, in effect.

 It states:
 ...
 The stated requirements for Proposed Standard are not changed; they
 remain exactly as specified in RFC 2026 [1].
 ...
 RFC 2026 essentially defines a PS document as being a first cut, likely
to
 change, and as such unsuitable for production deployment. In particular:


 You appear to be saying that the new document lowers quality by continuing
to
 use the same basic criteria and qualifiers for Proposed that we've used
for many
 years.

 Forgive me, but I do not understand how that logic works. How can the new
 process document lower quality by holding the established criteria for
Proposed
 stable?

 It appears that your actual concern is not about the new document, but
rather
 the existing process specification (RFC 2026).


 d/
 --

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Martin Rex
I am strongly opposed to this 2 document maturity level proposal.

The real problem tha the IETF is regularly facing are constituencies that
will fight hard against specifications getting updated, improved or fixed,
once they have been published as RFC. 


Dave Cridland wrote:
 
 Dave CROCKER wrote:
 
  Dave Cridland wrote:
   
   1) This document radically lowers the quality of Proposed  
   Standards.
  
  What, specifically, are the parts of the proposal that you believe  
  will lower the quality of a Proposed Standard?
 
 2.1. The First Maturity Level: Proposed Standard
 
 The intention of the two-tier maturity
ladder is to restore practice to the requirements for Proposed
Standard from RFC 2026, and stop performing more scrutiny than
intended in IETF working groups and the IESG.

The proposal literally says stop performing more scurtiny than
intended.  The lower quality of the documents at Proposed is
an explicit goal of this proposal.  When this proposal is adopted,
good quality for documents at Proposed is only going to happen
by accident, but no longer by peer review and scrutiny.



I believe that this proposal is based on a premise that is inverse
to reality.

The real causality is:

  - very few Working Groups go through the effort on fixing or
improving documents once they're published as RFCs, which,
for standards track documents usually means, they stay at
proposed for years

  - the widespread adoption of protocols  specifications on the
internet happens based on specification that are at Proposed,
if it happens at all.


And the logical consequence of Working Groups not updating and fixing
Proposed Document specification within a year after publication as RFC,
in order to improve interoperability and the quality of the specification
on which the software is based that runs the internet -- is to apply
more thorough peer review and scrutiny at that point of the
standardization process that can not be evaded by WG constituencies,
before the adoption of the specification as Proposed Standard.


I recently saw a proposal (by a WG chair) to adopt a new charter item
following a list of 3 WG documents at or heading for PS:

  The WG will attempt to avoid gratuitous changes to these protocols.

I do not believe that such a statement is motivated by the three
maturity levels for documents, but rather caused by constituencies
and emotional engagement by individuals with documents they authored
or contributed to, that do not want specification to be updated,
fixed or changed after these have been published as RFC.


 
 I don't think this reflects the current status quo in the slightest.  
 I think our current PS maturity is essentially considered production  
 quality, although we anticipate that clarifications in the  
 specification may be required, and consultation with other  
 implementors is likely to be beneficial.

Some IETF participants do, some don't, which results in controversy.

My understanding of the IETF standardization process, in particular
with respect to specification at PS is updating a spec to improve
interoperability is good, reducing complexity is good, i.e.
making stuff optional that is hardly used or creates interop
problems.  And when there are several different extensibility
options in a protocol, some of which with very high interop
in the installed base and some of which with poor interop in the
installed base, then redefining useful features to use the
more interoperable extensibility is useful.

However, there sometimes are constituencies in IETF WGs that take the
position the PS spec MUST NOT be updated or changed, unless proven
beyound all doubt, that the spec does not work at all.


 
 In particular, for better or worse, the wider internet technical  
 community - ie, the people who are aware of, but not involved in, the  
 IETF - expect our PS documents to have high quality, and would be  
 caught unawares by a sudden shift back to this stance.

+1

I assume that for every IETF spec implementer within the IETF, there
are 10 or more implementors that do not participate the IETF.
And it is for those others that we should produce, and update/improve
our specifications, at least once in a while.



 So to make this clear, I think that as the requirements and scrutiny  
 of PS documents have increased, the quality has as a result, and -  
 undoubtedly more important - the expected quality has also. I am  
 suprised that you don't see this as quite apparent.
 
 We have, in general, raised the bar over the years for PS documents,  
 and - whether or not you think this was a good idea - this horse has  
 left the station, and it's too late to put the lid back on - the  
 wider world now expects this.

+1


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave CROCKER



On 5/6/2011 9:15 AM, Martin Rex wrote:

The real problem tha the IETF is regularly facing are constituencies that
will fight hard against specifications getting updated, improved or fixed,
once they have been published as RFC.



That seems particularly true about possible changes to RFC 2026.

It is, indeed, a problem...

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave CROCKER



On 5/6/2011 9:01 AM, Andrew Sullivan wrote:

I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation ought to be made to match.



Oh.  But then that doesn't mean that the /current/ draft lowers quality but that 
the existing process has exhibited the lower.


In that case, it seems like the concrete way to resolve such concerns is to 
propose specific text to add to the current draft?


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Andrew Sullivan
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote:
 
 
 On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
 I think he is saying that there is are _de facto_ criteria that are
 neither called out in 2026 nor in this draft, and that those criteria
 are the running code, so the documentation ought to be made to match.
 
 
 Oh.  But then that doesn't mean that the /current/ draft lowers
 quality but that the existing process has exhibited the lower.

No, it does not.  

RFC 2026 has a low bar of entry to get something published as PS.

As a matter of fact, we don't do what's in 2026.  Things published as
PS are often quite mature.  Since just about nothing moves past PS
anyway, people regard it as the effective final level of
standardization and therefore require high degrees of review before
publication.  And once something is published at PS, it is all but
impossible to change it in any but the most trivial ways, because of
all the contracts that refer to that RFC and require conformance.  So
in fact a document published as PS has met criteria more stringent
than RFC 20206 would have one believe.

The present draft explicitly says that the actual criteria as actually
published in RFC 2026 are the right ones, and that additional
unwritten conventions and so on are to be removed.  

Therefore, if one thinks those more stringent criteria make for higher
quality, then the current draft will lower quality.  

I think we could state this all more neutrally by saying only that the
existing actual criteria do not match the published criteria, and that
therefore when the current draft says go back to RFC 2026 published
criteria is is in fact changing the criteria.  Then we don't have to
have an argument about whether the quality is better, since I don't
know how that would be measured anyway.  But in any case, the document
flat out admits that it is changing these criteria:

   Various influences have made publishing a Proposed Standard much
   harder than the stated requirements in RFC 2026.  The intention of
   the two-tier maturity ladder is to restore practice to the
   requirements for Proposed Standard from RFC 2026, and stop
   performing more scrutiny than intended in IETF working groups and
   the IESG.

So we should not pretend that the draft doesn't change criteria for
PS.  It just reiterates a position about what should happen.  It
remains to be seen what will actually happen.

And again, I have no horse in this race.  I don't believe the document
will make any difference at all, but for that very reason I don't care
whether it is adopted.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread John C Klensin


--On Friday, May 06, 2011 18:15 +0200 Martin Rex m...@sap.com
wrote:

 The real problem tha the IETF is regularly facing are
 constituencies that will fight hard against specifications
 getting updated, improved or fixed, once they have been
 published as RFC. 

Martin,

That is an interesting observation/ claim.  Because I don't
think I've seen that happen, I'd appreciate some examples.  

I have seen:

* Insistence that any updated version of a document
address all known outstanding issues, including
insistence that the revised document not move forward
until specific changes for which there is no clear
consensus be included.  In other words, if there is
community consensus for changes A and B to document X,
but no consensus that change C is needed (or
appropriate, or even correct) some people will try to
block approval of an X-bis that incorporates only
changes A and B until everyone agrees to C.  That is a
very difficult problem in any standards body.  We have
sometimes gotten around it by explicitly noting that
issue C remains controversial, but rarely without some
resistance.  But the problem isn't resistance to updates
and improvements, only controversy about whether the
changes are sufficient.

* Insistence by various groups, often (at least
apparently) only the IESG, that any document being
revised be altered to conform to multiple requirements
for content or editorial style that are more recent than
the original document and in spite a no evidence that
that older style or organization was causing any
problems.  That clearly makes it more difficult to get
an update with actual corrections, etc., issued than it
might be.  But I've not seen anything that I interpret
as evidence of resistance to change or updates once an
RFC is published, only procedural and editorial
requirements for publication of updated documents that
sometimes create barriers that seem unnecessary and
inappropriate.

* Certainly WGs and others tend to run out of energy
once initial RFCs are published.   If no one is willing
to produce a new or updated draft and persuade others to
review it, then revisions are not going to happen.  But
your comment implies active opposition to such
revisions: no energy is not active opposition.
Indeed, while I don't think it is justified in today's
environment, IIR part of what caused the 2026 advance
or die provision was the belief that, if no one cared
enough about a given specification to advance it, maybe
we didn't need it any more.

As someone who has been responsible for several RFCs and who has
worked on updates to a large subset of them, I've seen a lot of
pushback asking for more, but little or no pushback for the
idea of reviewing and revising specs.

While I see those issues as significant, none of them have
anything to do with this particular proposal: they apply equally
regardless of how many steps there are in the Standards Track,
apply to documents being recycled in grade, and even apply to
non-standards-track materials.

So you may be seeing things that I'm not (behaviors do differ
between areas and even among protocol families within an area)
but, if you are seeing active pushback on making revisions, I'd
be interested in hearing specifics about that, what you would
propose to do about it, and why this document is either helpful
or unhelpful in that regard.

regards, 
john




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave Cridland

On Fri May  6 17:50:07 2011, Andrew Sullivan wrote:

On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote:


 On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
 I think he is saying that there is are _de facto_ criteria that  
are
 neither called out in 2026 nor in this draft, and that those  
criteria
 are the running code, so the documentation ought to be made to  
match.



 Oh.  But then that doesn't mean that the /current/ draft lowers
 quality but that the existing process has exhibited the lower.

No, it does not.

RFC 2026 has a low bar of entry to get something published as PS.

As a matter of fact, we don't do what's in 2026.  Things published  
as

PS are often quite mature.  Since just about nothing moves past PS
anyway, people regard it as the effective final level of
standardization and therefore require high degrees of review before
publication.  And once something is published at PS, it is all but
impossible to change it in any but the most trivial ways, because of
all the contracts that refer to that RFC and require conformance.   
So

in fact a document published as PS has met criteria more stringent
than RFC 20206 would have one believe.

The present draft explicitly says that the actual criteria as  
actually

published in RFC 2026 are the right ones, and that additional
unwritten conventions and so on are to be removed.

Therefore, if one thinks those more stringent criteria make for  
higher

quality, then the current draft will lower quality.

I think we could state this all more neutrally by saying only that  
the
existing actual criteria do not match the published criteria, and  
that

therefore when the current draft says go back to RFC 2026 published
criteria is is in fact changing the criteria.  Then we don't have  
to

have an argument about whether the quality is better, since I don't
know how that would be measured anyway.  But in any case, the  
document

flat out admits that it is changing these criteria:

   Various influences have made publishing a Proposed Standard much
   harder than the stated requirements in RFC 2026.  The intention  
of

   the two-tier maturity ladder is to restore practice to the
   requirements for Proposed Standard from RFC 2026, and stop
   performing more scrutiny than intended in IETF working groups and
   the IESG.

So we should not pretend that the draft doesn't change criteria for
PS.  It just reiterates a position about what should happen.  It
remains to be seen what will actually happen.



Thanks for explaining that; it is indeed what I'm trying to say.


And again, I have no horse in this race.  I don't believe the  
document
will make any difference at all, but for that very reason I don't  
care

whether it is adopted.


I would rather not make the situation worse, especially without  
documentation which shows we have a real understanding of the  
de-facto standards process.


Ideally, I'd rather we first - before any attempts are made to change  
the standards process - document what it *is*.


Then, we should have a clearer understanding of the problems we're  
attempting to solve, and it should prove a lot less contentious.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Eliot Lear
Martin,

I think you may actually be arguing for a 1 step process.

Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread John Levine
I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation ought to be made to match.

This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.

I'm not sure whether I'm serious or not.

R's,
John

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Draft Secretariat SOW for Community Comment: Deadline 20 May

2011-05-06 Thread IETF Administrative Director
The IETF Administrative Oversight Committee (IAOC) plans to issue a
Request for Proposal (RFP) in late May for a vendor to perform the
Secretariat functions when the current contract ends on 31 January 2012. 
To that end the IAOC invites community comments on the draft Statement of
Work (SOW) that is located at http://iaoc.ietf.org/rfpsrfis.html.

The community comment period will run from 6 to 20 May 2011.  The IAOC
will consider all comments it receives during that period. 

The Secretariat provides various meeting, IT, clerical, finance and other
services to Supporting Organizations, including Working Groups, Internet
Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF
Administrative Oversight Committee (IAOC), and the Internet Research
Steering Group (IRSG). 

Changes in this proposed SOW from the current Secretariat SOW include,
but aren't limited to:

1.  Provision of IAB Administrative Services (IAB Executive Assistant)
2.  Provision of NomCom Administrative Services (NomCom Executive
Assistant)
3.  Provision of RFC Publisher Services, which will replace the current
separate contract,
4.  Adding the RFC Series Editor (RSE), Independent Submissions Editor
(ISE) and Nominating Committee (NomCom) to the list of Supported
Organizations for which services may be provided in the future.
5.  Production of minutes of the IETF Meeting Plenaries
6.  Requirement to book meeting venues three years in advance, instead 
of
two years, and
7.  Requirement to cryptography sign Internet-Drafts

Community comment is due no later than 20 May 2011 to
secretariat-2...@ietf.org.  One may subscribe to that list here:
https://www.ietf.org/mailman/listinfo/secretariat-2012.

All information submitted in response to this announcement is voluntary
and may be used in the development of the SOW and a subsequent RFP.

Thanks for your continuing advice and support.

Ray Pelletier
IETF Administrative Director
Internet Society 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: TSVDIR review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications

2011-05-06 Thread Livingood, Jason
Hi Joe – Thank you for your thorough review and detailed response. Your 
feedback will be incorporated into a –04 update with other changes received in 
last call and from the IESG. (I'm still working through all of the changes 
though.)

In any case, see my detailed responses inline below. I appreciate any suggested 
changes to the proposed new text of course.

Regards
Jason

On 4/28/11 4:38 PM, Joe Touch to...@isi.edumailto:to...@isi.edu wrote:

Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-...@ietf.orgmailto:tsv-...@ietf.org if you reply to or forward this 
review.

The document describes the issues associated with the practice of
whitelisting in DNS servers, in an attempt to limit which recursive
resolvers receive responses to requests for  (IPv6) records.

The practice of whitelisting can have significant impact on transport
protocols in the reachability of IPv6 endpoints. There are no transport
issues of a more specific nature discussed or determined as part of this
review.

I do have some other concerns which are noted below, and which are
offered for consideration.

I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.

Joe

-

Overall, this document is quite long and has many gratuitous digressions
which could easily be omitted. It is unnecessarily verbose and lengthy
for its topic. E.g., the architectural implications that stretch this
issue into network heterogeneity are a bit of a stretch, and the
discussion (and citation) for Newton's notion of momentum is unnecessary.

[JL] Thanks for the general feedback. As for the inclusion of CPE homogeneity 
being encouraged (Section 7.4) as a result of whitelisting, I am attempting to 
highlight that on the one hand there is a natural trend towards greater 
heterogeneity while whitelisting policies may encourage an opposite trend back 
towards homogeneity. In part this is due to the fact that so may different 
types of CPE exist and these vary widely with respect to IPv6-related 
impairments and capabilities. But it seems that whitelisting approvals for 
domains may occur more readily for those networks with a greater level of 
control (or complete control) over endpoints, where less variation in those 
devices exists as a result of that control, since the network can then push out 
device fixes for IPv6 impairments and so on. This is a tension that I know I as 
an ISP feel – on the one hand it seems desirable to have greater control over 
and less variation of CPE in order to win approval to be added to whitelists, 
while on the other hand there is a great deal of pressure in the opposite 
direction to enable any IP-capable CPE to connect (often this is encompassed in 
various countries' open Internet or network neutrality guidelines).

Blacklisting is noted in other environments in Sec 6, and noted as an
alternative for the DNS  issue in a cursory fashion in Sec 7.3.7. It
should certainly be introduced and defined earlier, and included in the
alternatives discussed in Sec 8. Blacklisting provides a useful
alternative because it requires explicit action to inhibit, rather than
requiring explicit action to avoid, and the tradeoff between
blacklisting and whitelisting should be discussed in more detail.

[JL] This is an excellent suggestion. I have acted on it in the following ways:
1 – Added this to Section 2, How DNS Whitelisting Works:
At a high level, using a whitelist means no traffic is permitted to the 
destination host unless the originating host's IP address is contained in the 
whitelist. In contrast, using a blacklist means that all traffic is permitted 
to the destination host unless the originating host's IP address is contained 
in the blacklist.

2 – I have added a new section in the solutions/alternatives, 8.4 Implement DNS 
Blacklisting, with the following text:
Some domains may wish to be more permissive than if they adopted DNS 
whitelisting [Section 8.2], but not still have some level of control over 
returning  record responses [Section 8.3]. An alternative in this case may 
be to employ DNS blacklisting, which would enable all DNS recursive resolvers 
to receive  record responses except for the relatively small number that 
are listed in the blacklist. This could enable an implementer to only prevent 
such responses where there has been a relatively high level of IPv6-related 
impairments, until such time as these impairments can be fixed or otherwise 
meaningfully reduced to an acceptable level.


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Barry Leiba
 This suggests that perhaps we should rename Proposed Standard to
 Not a Standard But Might Be One Later, promote the PS published
 under the overstrict rules to DS, and we're done.

 I'm not sure whether I'm serious or not.

Whether you are or not.., the only way to do this is to stop calling
them RFCs.  Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.

Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread John R. Levine

This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.

I'm not sure whether I'm serious or not.


Whether you are or not.., the only way to do this is to stop calling
them RFCs.  Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.


Well, you know, the Not a Standard But Might Be One Later really are 
requesting comments.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave Cridland

On Fri May  6 22:12:35 2011, Barry Leiba wrote:

 This suggests that perhaps we should rename Proposed Standard to
 Not a Standard But Might Be One Later, promote the PS published
 under the overstrict rules to DS, and we're done.

 I'm not sure whether I'm serious or not.

Whether you are or not.., the only way to do this is to stop calling
them RFCs.  Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.


This is not far off Scott Bradner's 2004 suggestion of Stable  
Snapshots of I-Ds.


It's also like the (much more versatile) labelling proposal Keith  
Moore made here.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Barry Leiba
John said...
 Well, you know, the Not a Standard But Might Be One Later really are
 requesting comments.

Yes, well, we all know that RFC has lost any real sense of its
expansion long ago.  It certainly has done so in the eyes of most of
the world, for whom RFC means Internet standard.

Dave Cridland sid...
 It's also like the (much more versatile) labelling proposal Keith Moore made
 here.

Perhaps, but Keith's labelling proposal is still not sufficient if we
CALL them RFCs.  The *only* way to make people not look at them as
already standard is by NOT giving them RFC numbers.

Now, I'm not sure that's what we should do.  But I *am* sure it's the
only way to do it.

Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave CROCKER



On 5/6/2011 2:29 PM, John R. Levine wrote:

Whether you are or not.., the only way to do this is to stop calling
them RFCs. Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.


Well, you know, the Not a Standard But Might Be One Later really are
requesting comments.



seems like that is rather cumbersome phrasing for a label.  perhaps we can come 
up with a term that is shorter but implies a similar status with regard to now 
and later.


hmmm.  what about the word 'proposed'?

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Dave Cridland

On Fri May  6 22:37:20 2011, Barry Leiba wrote:

John said...
 Well, you know, the Not a Standard But Might Be One Later  
really are

 requesting comments.

Yes, well, we all know that RFC has lost any real sense of its
expansion long ago.  It certainly has done so in the eyes of most of
the world, for whom RFC means Internet standard.


Actually, for most of the world, it means Rugby Football Club. But  
yes, for the majority of folk who know about protocol specs, then RFC  
means Standard.




Dave Cridland sid...
 It's also like the (much more versatile) labelling proposal Keith  
Moore made

 here.

Perhaps, but Keith's labelling proposal is still not sufficient if  
we

CALL them RFCs.  The *only* way to make people not look at them as
already standard is by NOT giving them RFC numbers.


Right, which is why both Scott and Keith's proposals involve I-Ds,  
not RFCs.


Now, I'm not sure that's what we should do.  But I *am* sure it's  
the

only way to do it.


I think it represents the sanest approach proposed so far.

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Martin Rex
Barry Leiba wrote:
 
 John said...
  Well, you know, the Not a Standard But Might Be One Later really are
  requesting comments.
 
 Yes, well, we all know that RFC has lost any real sense of its
 expansion long ago.  It certainly has done so in the eyes of most of
 the world, for whom RFC means Internet standard.

Correct.  It really does not matter how *WE* call it, it is not going
to affect in any way what the world does with it as long as it has
the published status.

In many areas 90% of the implementors are outside of the IETF.
And if they get the task to implement and ship some protocol in
a product -- they will check the RFC index for a document describing
the protocol.  And if there is exactly one version of a protocol
(and ultimately just one RFC document describing it), then they
going to use exactly that document for their implementation,
indepent of what labelboilerplate the IETF has slapped on the
front page.  It really does not matter whether it reads
Informational, Proposed Standard, Draft Standard or Standard.

They need to implement it, there is just one document describing it,
so really, what does this matter?

And frankly, large parts of the internet run with protocols and
specification that are Informational and Proposed, and a
non-marginal part even runs on I-Ds.


The large majority out there just doesn't care how many document
maturity levels the IETF uses.


And the folks that prefer more numerous and easier I-D - RFC transitions
are likely the early adopters which are frequently shipping products
based on I-Ds, and often the members of constituencies that would love
to completely lock down a specification as soon as they ship a product
based on it.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Brian E Carpenter
Ship it. We are way past the point of diminishing returns in
polishing this.

Regards
   Brian Carpenter
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: draft-housley-two-maturity-levels-06

2011-05-06 Thread Mykyta Yevstifeyev

07.05.2011 0:29, John R. Levine wrote:

This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.

I'm not sure whether I'm serious or not.


Whether you are or not.., the only way to do this is to stop calling
them RFCs.  Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.


Well, you know, the Not a Standard But Might Be One Later really are 
requesting comments.
Why invent something new?  The Experimental category covers what you 
want to name Not a Standard But Might Be One Later; Experimental docs. 
are fine for permanent record of some protocol to encourage its 
experimental implementations to produce the Standards Track document of 
really high level (since it's based on received experience with this 
protocol).  Some recent RFCs are good examples; see eg. 
http://tools.ietf.org/html/rfc6137#section-1.5


The other problem (if it is) is that implementators really don't care 
whether the Standards Track document is Proposed, Draft or Full; as 
mentioned before in this thread, everything named RFC is considered to 
be stable and OK for implementation (maybe, except Historic documents 
:-).  And this can't be changed; this is established; this is 
implementator's mentality.  Considering it, many WGs/folks who once 
wrote Proposed Standard see no sense to move it forward to Draft and 
Full.  Considering this, even though it was planned by RFC 2026 in the 
other way, Proposed Standards are actually worth that scrutiny they are 
currently given (even though I personally can hardly agree with this 
statement).


Mykyta Yevstifeyev


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for 
Dummies,

Please consider the environment before reading this e-mail. http://jl.ly
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-06 Thread Mykyta Yevstifeyev

Hello again,

Now as for the document itself.  I really appreciate its purpose; 
encouraging Proposed-Standards-writers to advance their document 
replacing 3-tier system to 2-tier one is a good idea.  However, in fact, 
this proposal in its current view really can't work effectively because of:



Any protocol or service that is currently at the abandoned Draft
Standard maturity level will retain that classification, absent
explicit actions.
In this case, as Brian Carpenter said during discussions of previous 
versions of this document, unless we have a firm sunset date, the job 
will never be finished and in fifty years there will still be DS 
documents. 
(http://www.ietf.org/mail-archive/web/ietf/current/msg65870.html)  
Considered this, removal of the sunset period is probably harmful; as 
nobody cared about progressing their DSs (see my previous message), they 
will continue to do this.

Two possible actions are available:

(1) A Draft Standard may be reclassified as an Internet Standard as
soon as the criteria inSection 2.2  
http://tools.ietf.org/html/draft-housley-two-maturity-levels-06#section-2.2  
are satisfied.  This
[ . . . ]

(2) At any time after two years from the approval of this document as
a BCP, the IESG may choose to reclassify any Draft Standard
document as Proposed Standard.
A reasonable question: whether such action won't be available after 2 
years?  Anyway, leaving the situation with DSs as is won't result in 
something useful.  As proposed before, 2-year sunset period is OK; if 
nobody undertakes any steps to advance their DS to FS during these 2 
years, such DS is reclassified to PS.


Another issue is removing the requirement for implementation reports.  
This must really result in low quality of FSs.  As Bernold Adoba 
mentioned before,


Today it is quite common within WGs to see conflicting claims about 
protocol implementations and
interoperability.   IMHO one of the critical purposes served by 
implementation reports is to require proponents
to produce the evidence backing their claims.   The above paragraph 
left me wondering what the
burden of proof would be in practice.   For example, I would not 
want to see the IESG put in the
position of adjudicating he said, she said arguments made during 
Last Call.
I fully agree with the last sentence; implementation reports serve as 
some documentary justification of existing of implementations that suit 
all requirements of the spec.


The following requirement for FSs seems unclear:


* If patented or otherwise controlled technology is required for
 implementation, the separate implementations must also have
 resulted from separate exercise of the licensing process.
Maybe I'm misunderstanding smth., but this is not a requirement but 
rather just statement.  This introduces new difficulties to advancing 
PSs to FSs; this hard-to-understand demand will mislead almost 
everybody, I think.


Also, the minimum period for existing on Standards Track of 6 month is 
not really sufficient to fulfill the following requirement:



* There are a significant number of implementations with
 successful operational experience.
Some words on STD numbers as well.  Their initial purpose was to provide 
clear reference point to FSs; RFC 1796 encouraged their use to 
distinguish Standards from other RFCs.  However, the experience showed 
that they doesn't work (or work partly).  The well-known problem is what 
to do with STD number when FSs is recycled to PS.  Some recent 
proposals, such as written by John Klensin 
(http://tools.ietf.org/html/draft-klensin-std-numbers-01) proposed 
assignment of STD numbers to all Standards Track RFCs, including PSs.  
This, even solving aforementioned problem, decreases the usefulness of 
STD numbers; but now we are not speaking about that proposal.  Russ' 
document leaves this question open; I think it shouldn't.  I really 
think STD numbers should be abandoned; they just make a mess into the 
Standards Track.  Another proposal should be to put some identifier of 
maturity level in the STD number, assigning one for all documents moving 
through the Standards Track system, ie. STD P-xx, STD D-xx and STD xx 
(for FSs), where xx is assigned to PSs only while all its successors 
retain it; but I don't think such proposal will ever be adopted.


Removal of requirement for annual reviews of PSs is a good deed, since 
nobody really suited to it after NEWTRK WG effort, except rare cases.


There are also some minor defects in this draft, concerning Section 4 
mostly; I don't want to mention them now.


So, taking everything into account, I wouldn't like to see this document 
approved as BCP.  Having a good idea, its realization isn't as good.


Mykyta Yevstifeyev

05.05.2011 19:13, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Reducing the Standards Track to Two Maturity Levels'
   

Document Action: 'A Survey of Lower-than-Best-Effort Transport Protocols' to Informational RFC (draft-ietf-ledbat-survey-07.txt)

2011-05-06 Thread The IESG
The IESG has approved the following document:
- 'A Survey of Lower-than-Best-Effort Transport Protocols'
  (draft-ietf-ledbat-survey-07.txt) as an Informational RFC

This document is the product of the Low Extra Delay Background Transport
Working Group.

The IESG contact person is Wesley Eddy.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ledbat-survey/




Technical Summary

This document provides a survey of transport protocols which are
designed to have a smaller bandwidth and/or delay impact on standard
TCP than standard TCP itself when they share a bottleneck with it.
Such protocols could be used for delay-insensitive background
traffic, as they provide what is sometimes called a less than (or
lower than) best-effort service.

Working Group Summary

This document is a product of the LEDBAT WG. It has received reviews from
various WG participants. There were no controversies in the Last Call of
the document and the WG feels the document is ready for publication.

Document Quality

The algorithm that triggered this survey, which is still being worked on but
nears completion, is implemented by BitTorrent Inc. Special thanks to
Mirja Kühlewind, Wesley Eddy and Mayutan Arumaithurai for their thorough
reviews of the document.

Personnel

Rolf Winter (rolf.win...@neclab.eu) is the Document Shepherd. Lars
Eggert (lars.egg...@nokia.com) reviewed the document for the IESG.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Last Call: draft-ietf-pwe3-fat-pw-06.txt (Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network) to Proposed Standard

2011-05-06 Thread The IESG

The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched
   Network'
  draft-ietf-pwe3-fat-pw-06.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2011-05-20. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/


No IPR declarations have been submitted directly on this I-D.


Abstract

   Where the payload of a pseudowire comprises a number of distinct
   flows, it can be desirable to carry those flows over the equal cost
   multiple paths (ECMPs) that exist in the packet switched network.
   Most forwarding engines are able to hash based on MPLS label stacks
   and use this mechanism to balance MPLS flows over ECMPs.

   This document describes a method of identifying the flows, or flow
   groups, within pseudowires such that Label Switching Routers can
   balance flows at a finer granularity than individual pseudowires.
   The mechanism uses an additional label in the MPLS label stack. 
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Draft Secretariat SOW for Community Comment: Deadline 20 May

2011-05-06 Thread IETF Administrative Director
The IETF Administrative Oversight Committee (IAOC) plans to issue a
Request for Proposal (RFP) in late May for a vendor to perform the
Secretariat functions when the current contract ends on 31 January 2012. 
To that end the IAOC invites community comments on the draft Statement of
Work (SOW) that is located at http://iaoc.ietf.org/rfpsrfis.html.

The community comment period will run from 6 to 20 May 2011.  The IAOC
will consider all comments it receives during that period. 

The Secretariat provides various meeting, IT, clerical, finance and other
services to Supporting Organizations, including Working Groups, Internet
Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF
Administrative Oversight Committee (IAOC), and the Internet Research
Steering Group (IRSG). 

Changes in this proposed SOW from the current Secretariat SOW include,
but aren't limited to:

1.  Provision of IAB Administrative Services (IAB Executive Assistant)
2.  Provision of NomCom Administrative Services (NomCom Executive
Assistant)
3.  Provision of RFC Publisher Services, which will replace the current
separate contract,
4.  Adding the RFC Series Editor (RSE), Independent Submissions Editor
(ISE) and Nominating Committee (NomCom) to the list of Supported
Organizations for which services may be provided in the future.
5.  Production of minutes of the IETF Meeting Plenaries
6.  Requirement to book meeting venues three years in advance, instead 
of
two years, and
7.  Requirement to cryptography sign Internet-Drafts

Community comment is due no later than 20 May 2011 to
secretariat-2...@ietf.org.  One may subscribe to that list here:
https://www.ietf.org/mailman/listinfo/secretariat-2012.

All information submitted in response to this announcement is voluntary
and may be used in the development of the SOW and a subsequent RFP.

Thanks for your continuing advice and support.

Ray Pelletier
IETF Administrative Director
Internet Society 
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6190 on RTP Payload Format for Scalable Video Coding

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6190

Title:  RTP Payload Format for Scalable 
Video Coding 
Author: S. Wenger, Y.-K. Wang,
T. Schierl, A. Eleftheriadis
Status: Standards Track
Stream: IETF
Date:   May 2011
Mailbox:st...@stewe.org, 
yekui.w...@huawei.com, 
t...@thomas-schierl.de,  a...@vidyo.com
Pages:  100
Characters: 250504
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-avt-rtp-svc-27.txt

URL:http://www.rfc-editor.org/rfc/rfc6190.txt

This memo describes an RTP payload format for Scalable Video Coding
(SVC) as defined in Annex G of ITU-T Recommendation H.264, which is
technically identical to Amendment 3 of ISO/IEC International Standard
14496-10.  The RTP payload format allows for packetization of one or
more Network Abstraction Layer (NAL) units in each RTP packet payload,
as well as fragmentation of a NAL unit in multiple RTP packets.
Furthermore, it supports transmission of an SVC stream over a single
as well as multiple RTP sessions.  The payload format defines a new
media subtype name H264-SVC, but is still backward compatible to RFC
6184 since the base layer, when encapsulated in its own RTP stream,
must use the H.264 media subtype name (H264) and the packetization
method specified in RFC 6184.  The payload format has wide
applicability in videoconferencing, Internet video streaming, and
high-bitrate entertainment-quality video, among others.  [STANDARDS-TRACK]

This document is a product of the Audio/Video Transport Payloads Working Group 
of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6226 on PIM Group-to-Rendezvous-Point Mapping

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6226

Title:  PIM Group-to-Rendezvous-Point Mapping 
Author: B. Joshi, A. Kessler,
D. McWalter
Status: Standards Track
Stream: IETF
Date:   May 2011
Mailbox:bharat_jo...@infosys.com, 
kess...@cisco.com, 
da...@mcwalter.eu
Pages:  11
Characters: 24092
Updates:RFC4601

I-D Tag:draft-ietf-pim-group-rp-mapping-10.txt

URL:http://www.rfc-editor.org/rfc/rfc6226.txt

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in
a PIM domain that supports Any Source Multicast (ASM) maintains
Group-to-RP mappings that are used to identify a Rendezvous Point
(RP) for a specific multicast group.  PIM-SM has defined an algorithm
to choose a RP from the Group-to-RP mappings learned using various
mechanisms.  This algorithm does not consider the PIM mode and the
mechanism through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically
choose between several Group-to-RP mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.  
[STANDARDS-TRACK]

This document is a product of the Protocol Independent Multicast Working Group 
of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6227 on Design Goals for Scalable Internet Routing

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6227

Title:  Design Goals for Scalable Internet 
Routing 
Author: T. Li, Ed.
Status: Informational
Stream: IRTF
Date:   May 2011
Mailbox:t...@cisco.com
Pages:  8
Characters: 18418
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-irtf-rrg-design-goals-06.txt

URL:http://www.rfc-editor.org/rfc/rfc6227.txt

It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, mobility,
multi-homing, and inter-domain traffic engineering.  The Routing Research
Group is investigating an alternate architecture to meet these
challenges.  This document consists of a prioritized list of design
goals for the target architecture.  This document is not an Internet 
Standards Track specification; it is published for informational purposes.

This document is a product of the IRTF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6228 on Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6228

Title:  Session Initiation Protocol (SIP) Response 
Code for Indication of Terminated Dialog 
Author: C. Holmberg
Status: Standards Track
Stream: IETF
Date:   May 2011
Mailbox:christer.holmb...@ericsson.com
Pages:  14
Characters: 34311
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-sipcore-199-06.txt

URL:http://www.rfc-editor.org/rfc/rfc6228.txt

This specification defines a new Session Initiation Protocol (SIP)
response code, 199 Early Dialog Terminated, that a SIP forking proxy
and a User Agent Server (UAS) can use to indicate to upstream SIP
entities (including the User Agent Client (UAC)) that an early dialog
has been terminated, before a final response is sent towards the SIP
entities.  [STANDARDS-TRACK]

This document is a product of the Session Initiation Protocol Core Working 
Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6234 on US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6234

Title:  US Secure Hash Algorithms (SHA 
and SHA-based HMAC and HKDF) 
Author: D. Eastlake 3rd, T. Hansen
Status: Informational
Stream: IETF
Date:   May 2011
Mailbox:d3e...@gmail.com, 
tony+...@maillennium.att.com
Pages:  127
Characters: 236573
Obsoletes:  RFC4634
Updates:RFC3174

I-D Tag:draft-eastlake-sha2b-07.txt

URL:http://www.rfc-editor.org/rfc/rfc6234.txt

Federal Information Processing Standard, FIPS


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 6237 on IMAP4 Multimailbox SEARCH Extension

2011-05-06 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 6237

Title:  IMAP4 Multimailbox SEARCH Extension 
Author: B. Leiba, A. Melnikov
Status: Experimental
Stream: IETF
Date:   May 2011
Mailbox:barryle...@computer.org, 
alexey.melni...@isode.com
Pages:  10
Characters: 21234
Updates:RFC4466

I-D Tag:draft-ietf-morg-multimailbox-search-07.txt

URL:http://www.rfc-editor.org/rfc/rfc6237.txt

The IMAP4 specification allows the searching of only the selected
mailbox.  A user often wants to search multiple mailboxes, and a
client that wishes to support this must issue a series of SELECT and
SEARCH commands, waiting for each to complete before moving on to the
next.  This extension allows a client to search multiple mailboxes
with one command, limiting the round trips and waiting for various
searches to complete, and not requiring disruption of the currently
selected mailbox.  This extension also uses MAILBOX and TAG fields in
ESEARCH responses, allowing a client to pipeline the searches if it
chooses.  This document updates RFC 4466.  This document defines an 
Experimental Protocol for the Internet community.

This document is a product of the Message Organization Working Group of the 
IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce