Re: PS Characterization Clarified

Olaf, Scott, Apologies for a late reply on this (I was on vacation after the IETF). But thank you for writing this draft. My general comment is that the draft makes what in my mind is an accurate correction to our documents, aligning the documents to the current reality. I'd be happy to take th

Re: PS Characterization Clarified

On Sep 2, 2013, at 10:23 AM, Jari Arkko wrote: > Olaf, Scott, > > Apologies for a late reply on this (I was on vacation after the IETF). But > thank you for writing this draft. My general comment is that the draft makes > what in my mind is an accurate correction to our documents, aligning th

Re: PS Characterization Clarified

Hi Jari, On 03/09/2013 02:23, Jari Arkko wrote: ... > At the time of this writing, the IETF operates as if the > Proposed Standard was the last chance for the to ensure the > quality of the technology and the clarity of the standards > document. There's a point that I think should be made here

Re: PS Characterization Clarified

--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner wrote: >> There is at least one ongoing effort right now that has the >> potential to reclassify a large set of Proposed Standard RFCs >> that form the basis of widely used technology. These types of >> efforts can have a relatively bi

Re: PS Characterization Clarified

> There's a point that I think should be made here, something like: > > In practice, interoperable implementations are commonly based on > Proposed Standard documents, so whatever design defects those > documents have tend to become part of the interoperable network, > perhaps in the form of work

Re: PS Characterization Clarified

On 2 sep. 2013, at 22:14, John C Klensin wrote: > > > --On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner > wrote: > >>> There is at least one ongoing effort right now that has the >>> potential to reclassify a large set of Proposed Standard RFCs >>> that form the basis of widely use

Re: PS Characterization Clarified

+1. Well said.

Re: PS Characterization Clarified

Olaf, John, Scott, > In fact, going back to the language of RFC2026 for Full (now Internet) > Standard. It confirms that popularity (significant implementation) is one > necessary but not sufficient criterium. Sorry. I was careless when I wrote about the effort. I didn't mean to suggest that w

Re: PS Characterization Clarified

thank you - clarity does help but such an effort will not remove the need for this document imo Scott On Sep 3, 2013, at 9:20 AM, Jari Arkko wrote: > Olaf, John, Scott, > >> In fact, going back to the language of RFC2026 for Full (now Internet) >> Standard. It confirms that popularity (sign

Re: PS Characterization Clarified

On Sep 3, 2013, at 4:40 PM, Barry Leiba wrote: > The only concern I have is that once we do this -- declare that PS is > always more mature than that -- we can't go back. Do we *really* want > to say that we will never again approve a PS spec that's partially > baked? It seems as if we already

Re: PS Characterization Clarified

fwiw - I would love for the IESG to exercise flexibility here but I have not seen that in many years - so I think we are already there without a discernible path back Scott On Sep 3, 2013, at 4:40 PM, Barry Leiba wrote: > I mostly agree with this draft, but I have a concern. Let's anchor > t

Re: PS Characterization Clarified

I mostly agree with this draft, but I have a concern. Let's anchor that concern off of this bit that Jari said: > Secondly, the other obvious action we could take is to go back to the original > mode of operation, i.e., making PS RFCs truly early and somewhat untested > specifications. I am perso

Re: PS Characterization Clarified

Barry, Question, in-line. On Sep 3, 2013, at 10:40 PM, Barry Leiba wrote: > I mostly agree with this draft, but I have a concern. Let's anchor > that concern off of this bit that Jari said: > >> Secondly, the other obvious action we could take is to go back to the >> original >> mode of oper

Re: PS Characterization Clarified

>> The only concern I have is that once we do this -- declare that PS is >> always more mature than that -- we can't go back. Do we *really* want >> to say that we will never again approve a PS spec that's partially >> baked? This is painting us into the room where PS is mature and >> robust. If

Re: PS Characterization Clarified

> OK, somebody has to say it. Maybe we should have another state, > something like draft standard. [ sob alluded to a private message from me which said ] while i really like the idea of pushing well-tested interoperable documents to full standards, i think tested interop is key here. hence i li

Re: PS Characterization Clarified

On 9/4/2013 11:14 AM, Scott Brim wrote: On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba wrote: The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's parti

Re: PS Characterization Clarified

On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba wrote: >>> The only concern I have is that once we do this -- declare that PS is >>> always more mature than that -- we can't go back. Do we *really* want >>> to say that we will never again approve a PS spec that's partially >>> baked? This is painti

Re: PS Characterization Clarified

Colleagues [I have added a number of people who were active in the discussion previously to the CC, my apologies if that is bad etiquette but I wanted to make you explicitly aware of this.] Based on the discussion so far I've made a few modifications to the draft. I am trying to consciously

Re: PS Characterization Clarified

Hi Olaf, At 07:56 13-09-2013, Olaf Kolkman wrote: Based on the discussion so far I've made a few modifications to the draft. I am trying to consciously keep this document to the minimum that is needed to achieve 'less is more' and my feeling is that where we are now is close to the sweetspot

Re: PS Characterization Clarified

> Based on the discussion so far I've made a few modifications to the draft. > I am trying to consciously keep this document to the minimum that is needed > to achieve 'less is more' and my feeling is that where we are now is close > to the sweetspot of consensus. Section 4 makes me happy. I thi

Re: PS Characterization Clarified

On 13 sep. 2013, at 19:17, S Moonesamy wrote: > The intended status would have to be BCP instead of Informational. Correct…. fixed on trunk. > In Section 3.1: > "A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" >

Re: PS Characterization Clarified

On Sep 13, 2013, at 2:32 PM, Olaf Kolkman wrote: > > On 13 sep. 2013, at 19:17, S Moonesamy wrote: > > >> The intended status would have to be BCP instead of Informational. > > Correct…. fixed on trunk. > > >> In Section 3.1: > >> "A specific action by the IESG is required to move a

Re: PS Characterization Clarified

On 13 sep. 2013, at 20:03, Carsten Bormann wrote: > On Sep 13, 2013, at 16:56, Olaf Kolkman wrote: > >> * Added the Further Consideration section based on discussion on the >> mailinglist. > > I believe the current document is fine for a major part of the IETF standards > activities. >

Re: PS Characterization Clarified

On Sep 13, 2013, at 16:56, Olaf Kolkman wrote: > * Added the Further Consideration section based on discussion on the >mailinglist. I believe the current document is fine for a major part of the IETF standards activities. It is, however, important to keep in mind that the IETF is not a h

Re: PS Characterization Clarified

On Sep 13, 2013, at 20:50, Olaf Kolkman wrote: > I am trying to see what one gets if one translates the fallacies into > positive actions, or answer the question on how do you cope with the fallacy. > I notice that your draft observes but doesn't seem to recommend. Indeed, the 2011 document is

Re: PS Characterization Clarified

--On Friday, September 13, 2013 16:56 +0200 Olaf Kolkman wrote: >... > Based on the discussion so far I've made a few modifications > to the draft. I am trying to consciously keep this document > to the minimum that is needed to achieve 'less is more' and > my feeling is that where we are now

Re: PS Characterization Clarified

On 13 sep. 2013, at 21:02, Adrian Farrel wrote: > Hey Olaf, > > Thanks for stubbornly pushing on with this. > > Comments (sorry I haven't read the thread to see if others have already made > these comments)… This is to acknowledge I took the suggestions that I am not quoting. > --- >

Re: PS Characterization Clarified

[Barry added explicitly to the CC as this speaks to 'his' issue] On 13 sep. 2013, at 20:57, John C Klensin wrote: [… skip …] >> * Added the Further Consideration section based on >> discussion on themailinglist. > > Unfortunately, IMO, it is misleading to the extent that you are > capt

Re: PS Characterization Clarified

> Yeah it is a thin line. But the language was introduced to keep a > current practice possible (as argued by Barry I believe). Yes, that was my concern. > I see where you are going. > > > > While commonly less mature specifications will be published as > Informational or Experimental RFCs, the

Re: PS Characterization Clarified

--On Monday, September 16, 2013 15:58 +0200 Olaf Kolkman wrote: > [Barry added explicitly to the CC as this speaks to 'his' > issue] > > On 13 sep. 2013, at 20:57, John C Klensin > wrote: > > [… skip …] > >>> * Added the Further Consideration section based on >>> discussion on themail

Re: PS Characterization Clarified

--On Monday, September 16, 2013 10:43 -0400 Barry Leiba wrote: >... > I agree that we're normally requiring much more of PS > documents than we used to, and that it's good that we document > that and let external organizations know. At the same time, > we are sometimes proposing things that we

Re: PS Characterization Clarified

Based on the conversation below I converged to: While less mature specifications will usually be published as Informational or Experimental RFCs, the IETF may, in exceptional cases, publish a specification that still contains areas for improvement or certain uncertai

Re: PS Characterization Clarified

On 16 sep. 2013, at 17:31, John C Klensin wrote: >> >> As actionable for this draft I take that I explicitly mention >> that Section 4.1 2026 is exclusively updated. > > While I understand your desire to keep this short, the pragmatic > reality is that your non-IETF audience is likely to read

Re: PS Characterization Clarified

On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman wrote: > > > Based on the conversation below I converged to: > > > > While less mature specifications will usually be published as > Informational or Experimental RFCs, the IETF may, in exceptional > cases, publish a specificati

Re: PS Characterization Clarified

On 17/09/2013 11:32, Dave Cridland wrote: On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman > wrote: Based on the conversation below I converged to: While less mature specifications will usually be published as Informational or Experiment

Re: PS Characterization Clarified

On Sep 17, 2013 6:33 AM, "Dave Cridland" wrote: > > On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman wrote: >> >> >> >> Based on the conversation below I converged to: >> >> >> >> While less mature specifications will usually be published as >> Informational or Experimental RFCs, th

Re: PS Characterization Clarified

--On Tuesday, September 17, 2013 11:47 +0200 Olaf Kolkman wrote: > > > Based on the conversation below I converged to: > > > > While less mature specifications will usually be > published as Informational or Experimental RFCs, the > IETF may, in exceptional cases, publ

Re: PS Characterization Clarified

--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland wrote: > I read John's message as being against the use of the phrase > "in exceptional cases". I would also like to avoid that; it > suggests that some exceptional argument may have to be made, > and has the implication that it essenti

Re: PS Characterization Clarified

FYI. I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 Diff with the previous document: http://tools.ietf.org/rfcdiff?url2=draft-kolkman-proposed-standards-clarified-02.txt I will let Jari know that I believe we converged a

Re: PS Characterization Clarified

On 9/17/13 11:27 AM, Olaf Kolkman wrote: I just posted the third version of the draft at: http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02 I would like to change "IESG" to "IETF" in five places: Section 1: "the IESG has evolved its review processes" Section 2: "IESG

Re: PS Characterization Clarified

1/ I believe that change would be factually incorrect 2/ I do not see that being factually correct about what happened says anything about the community opinion about any future IESG decision to change processes. Scott On Sep 17, 2013, at 6:48 PM, Pete Resnick wrote: > On 9/17/13 11:27 AM

Re: PS Characterization Clarified

On 9/17/13 5:52 PM, Scott O. Bradner wrote: On Sep 17, 2013, at 6:48 PM, Pete Resnick wrote: I would like to change "IESG" to "IETF" in five places: Section 1: "the IESG has evolved its review processes" Section 2: "IESG Reveiew of Proposed Standards" "the IESG strengthened its review"

Re: PS Characterization Clarified

Pete, I generally agree with your changes and consider them important -- the IESG should be seen in our procedural documents as evaluating and reflecting the consensus of the IETF, not acting independently of it. Of the various places in the document in which "IESG" now appears, only one of them

Re: PS Characterization Clarified

On 18 sep. 2013, at 01:54, John C Klensin wrote: > Pete, > > I generally agree with your changes and consider them important > -- the IESG should be seen in our procedural documents as > evaluating and reflecting the consensus of the IETF, not acting > independently of it. > Agreed…. > Of th

Re: PS Characterization Clarified

John covered why I said that Pete's assertion is factually incorrect that said, I agree that being accurate here (that the IESG is the final decider and the body that changed the review from what was described in RFC 2026) may be counter productive when the document is reviewed outside of the

Re: PS Characterization Clarified

--On Wednesday, September 18, 2013 10:59 +0200 Olaf Kolkman wrote: >> However, because the document will be read externally, I >> prefer that it be "IETF" in all of the places you identify. >> If we have to hold our noses and claim that the community >> authorized the IESG actions by failing to

Re: PS Characterization Clarified

On 9/18/13 7:19 AM, John C Klensin wrote: In full context: In fact, the IETF review is more extensive than that done in other SDOs owing to the cross-area technical review performed by the IETF,exemplified by technical review by the full IESG at last stage of specification d

Re: PS Characterization Clarified

Olaf, John, Pete, I know I have more mail to process and that you've already converged. I just wanted to say something about this: > > > While commonly less mature specifications will be published as > Informational or Experimental RFCs, the IETF may, in > exceptional cases, publish a specific