On 18 sep. 2013, at 01:54, John C Klensin john-i...@jck.com 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.
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
--On Wednesday, September 18, 2013 10:59 +0200 Olaf Kolkman
o...@nlnetlabs.nl 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
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
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:
draft Proposed rewrite
While commonly less mature specifications will be published as
Informational or Experimental RFCs, the IETF may, in
exceptional cases,
Based on the conversation below I converged to:
t
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
On 16 sep. 2013, at 17:31, John C Klensin john-i...@jck.com 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
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be published as
Informational or Experimental RFCs, the IETF may, in exceptional
cases, publish a
On 17/09/2013 11:32, Dave Cridland wrote:
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl
mailto:o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be published as
On Sep 17, 2013 6:33 AM, Dave Cridland d...@cridland.net wrote:
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be published as
Informational or
--On Tuesday, September 17, 2013 11:47 +0200 Olaf Kolkman
o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be
published as Informational or Experimental RFCs, the
IETF may, in exceptional
--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland
d...@cridland.net 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
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
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
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 presn...@qti.qualcomm.com
On 9/17/13 5:52 PM, Scott O. Bradner wrote:
On Sep 17, 2013, at 6:48 PM, Pete Resnickpresn...@qti.qualcomm.com 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
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
On 13 sep. 2013, at 21:02, Adrian Farrel adr...@olddog.co.uk 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.
[Barry added explicitly to the CC as this speaks to 'his' issue]
On 13 sep. 2013, at 20:57, John C Klensin klen...@jck.com wrote:
[… skip …]
* Added the Further Consideration section based on
discussion on themailinglist.
Unfortunately, IMO, it is misleading to the extent that you
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.
draft Proposed rewrite
While commonly less mature specifications will be published as
Informational or
--On Monday, September 16, 2013 15:58 +0200 Olaf Kolkman
o...@nlnetlabs.nl wrote:
[Barry added explicitly to the CC as this speaks to 'his'
issue]
On 13 sep. 2013, at 20:57, John C Klensin klen...@jck.com
wrote:
[… skip …]
* Added the Further Consideration section based on
--On Monday, September 16, 2013 10:43 -0400 Barry Leiba
barryle...@computer.org 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
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
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
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 think
On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com 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
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman o...@nlnetlabs.nl wrote:
On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com 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
On 13 sep. 2013, at 20:03, Carsten Bormann c...@tzi.org wrote:
On Sep 13, 2013, at 16:56, Olaf Kolkman o...@nlnetlabs.nl 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
On Sep 13, 2013, at 16:56, Olaf Kolkman o...@nlnetlabs.nl 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
On Sep 13, 2013, at 20:50, Olaf Kolkman o...@nlnetlabs.nl 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
--On Friday, September 13, 2013 16:56 +0200 Olaf Kolkman
o...@nlnetlabs.nl 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
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 we like
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
On 9/4/2013 11:14 AM, Scott Brim wrote:
On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba barryle...@computer.org 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
On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba barryle...@computer.org 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?
On 2 sep. 2013, at 22:14, John C Klensin john-i...@jck.com wrote:
--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner
s...@sobco.com 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
+1. Well said.
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 we
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 jari.ar...@piuha.net
wrote:
Olaf, John, Scott,
In fact, going back to the language of RFC2026 for Full (now Internet)
Standard. It confirms that
On Sep 3, 2013, at 4:40 PM, Barry Leiba barryle...@computer.org 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
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 barryle...@computer.org
wrote:
I mostly agree with this draft, but I have a
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
Barry,
Question, in-line.
On Sep 3, 2013, at 10:40 PM, Barry Leiba barryle...@computer.org 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
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
On Sep 2, 2013, at 10:23 AM, Jari Arkko jari.ar...@piuha.net 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
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,
--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner
s...@sobco.com 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
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
48 matches
Mail list logo
