On 01/12/2012 20:12, Stephen Farrell wrote:
Hi all,
I've just posted an idea [1] for a small process improvement.
If it doesn't seem crazy I'll try pursue it with the IESG as
an RFC 3933 process experiment. If its universally hated then
that's fine, it can die.
The IESG have seen
On 29 Nov 2012, at 18:51, SM s...@resistor.net wrote:
Hi Ed,
At 06:54 29-11-2012, Edward Lewis wrote:
Earlier in the thread I saw that someone expressed dismay that BOFs seem to
be WG's that have already been meeting in secret. I agree with that. At
the last meeting in Atlanta, I filled
Hi Stewart,
On 12/03/2012 08:06 AM, Stewart Bryant wrote:
On 01/12/2012 20:12, Stephen Farrell wrote:
Hi all,
I've just posted an idea [1] for a small process improvement.
If it doesn't seem crazy I'll try pursue it with the IESG as
an RFC 3933 process experiment. If its universally hated
On 03/12/2012 06:01, Martin J. Dürst wrote:
One of the advantages of a standards organization such as the IETF is
cross-concern review. For the IETF, one very strong cross-concern is
security. Another one (also for my personally) is internationalization.
Another, more vague one, is general
On 03/12/2012 00:24, Arturo Servin wrote:
Perhaps I did, but I am talking about Working Group Drafts
1.1. What is a Working Group Draft?
Documents under development in the IETF community are distributed as
Internet Drafts (I-D).
Melinda and/or Randy have said what I want to
On 12/03/2012 11:02 AM, Brian E Carpenter wrote:
On 03/12/2012 06:01, Martin J. Dürst wrote:
One of the advantages of a standards organization such as the IETF is
cross-concern review. For the IETF, one very strong cross-concern is
security. Another one (also for my personally) is
--On Monday, December 03, 2012 11:28 + Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
Encouraging running code is a Good Thing. Publishing sloppy
specifications is a Bad Thing.
Sure. I guess I'd hope that we push back on sloppy specs as
usual, but that the running code might make
Hi John,
On 12/03/2012 12:29 PM, John C Klensin wrote:
--On Monday, December 03, 2012 11:28 + Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
Encouraging running code is a Good Thing. Publishing sloppy
specifications is a Bad Thing.
Sure. I guess I'd hope that we push back on
Perhaps I did, but I am talking about Working Group Drafts
1.1. What is a Working Group Draft?
Documents under development in the IETF community are distributed as
Internet Drafts (I-D).
Melinda and/or Randy have said what I want to say, but as a factual
clarification to
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Melinda Shore
it's kind of weird that we cut off discussion so that we can proceed to the
next presentation. It's done all the time (I've done it, myself) and
while there's definitely a sense that we need to cover the
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Keith Moore
A different toolset, (e.g. pens and paper
and overhead cameras coupled to projectors), would likely produce better
results if that toolset did not encourage laziness in preparing
materials to facilitate
We could certainly say this. It is a true statement.
However, the document is trying to talk about WG I-Ds, not to provide a general
description of everything the IETF and RFC Editor ever does.
Is it false to say:
Documents under development in the IETF community are distributed as
On 12/3/2012 5:58 AM, Adrian Farrel wrote:
We could certainly say this. It is a true statement.
However, the document is trying to talk about WG I-Ds, not to provide a general
description of everything the IETF and RFC Editor ever does.
...
My answers are No and No.
+1
The existing text
But this doesn't do that for IETF LC at all! Everyone
not involved in the WG gets just the same notice as now.
This is true.
What I hope is different is that drafts taking this optional
approach are higher quality, being based on running code.
This is a stretch, and that *unprovable*
On 12/03/2012 08:57 AM, George, Wes wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Keith Moore
A different toolset, (e.g. pens and paper
and overhead cameras coupled to projectors), would likely produce better
results if that toolset did not encourage
On 12/03/2012 02:25 PM, Barry Leiba wrote:
Running code, when it's an organic part of the document development,
is undoubtedly a good thing -- it doesn't make everything right, but,
yes, it does do *some* spec validation and probably does help spec
quality.
Fully agree. And this kind of
Running code, when it's an organic part of the document development,
is undoubtedly a good thing -- it doesn't make everything right, but,
yes, it does do *some* spec validation and probably does help spec
quality.
Fully agree. And this kind of experiment may encourage that
good thing some
Hi.
On Mon, 2012-12-03 at 11:02 +, Brian E Carpenter wrote:
On 03/12/2012 06:01, Martin J. Dürst wrote:
One of the advantages of a standards organization such as the IETF is
cross-concern review. For the IETF, one very strong cross-concern is
security. Another one (also for my
On Dec 3, 2012, at 15:25, Barry Leiba barryle...@computer.org wrote:
But code that's written as part of a rote process, just to achieve
another check-box on the shepherd writeup and justify special handling
is not likely to provide any of those benefits.
+1.
As somebody who tends to think
On Mon, 2012-12-03 at 14:28 +, Stephen Farrell wrote:
On 12/03/2012 02:25 PM, Barry Leiba wrote:
Running code, when it's an organic part of the document development,
is undoubtedly a good thing -- it doesn't make everything right, but,
yes, it does do *some* spec validation and
On 12/3/2012 6:36 AM, Barry Leiba wrote:
Or we'll just waste time sticking in some side-process that isn't
necessary (all of this can already been done under current process,
with no experiment).
...
That's a better promise than saying we'll cut out three or four weeks
of review time for a
Elwyn says...
However, I don't think that a short last call cycle need necessarily
compromise cross-area review. There has always been the possibility for
authors or wg chairs to request a early gen-art review with a view to
checking out whether something is in good shape cross-area and for
On 12/03/2012 02:50 PM, Barry Leiba wrote:
I'd really prefer if we'd talk about open source being desirable, but
not having it be necessary.
Yep. I got another comment to that effect as well.
I'll try address that (but that's not done yet).
FWIW, a working copy is available [1] that has a
Barry responded...
On Mon, 2012-12-03 at 09:50 -0500, Barry Leiba wrote:
Elwyn says...
However, I don't think that a short last call cycle need necessarily
compromise cross-area review. There has always been the possibility for
authors or wg chairs to request a early gen-art review with
Do you really think it's likely that a chair who's trying to
fast-track a document will likely go out asking for early GenART,
SecDir, AppDir, and OpsDir reviews?
A few do already. But seriously, if the wg chair(s) actually have an
interest in the technology and feel there is a valid reason
Dave and Adrian,
I looked at section 1.1 of What is a Working Group Draft?
I find that the draft does not really answers that question. The draft
demonstrates how to recognize a wg draft in the IETF repository and it
also talks about the very common practice to keep the author/editor team
Hi all,
seeing all these discussions related to process improvements I just noticed one
annoying thing related to working group conference calls.
It turns out that the IESG guidelines on that topic (see
http://www.ietf.org/iesg/statement/interim-meetings.html) say the following:
*
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd or AD before posting a
new version of the draft.
Document:
On Nov 29, 2012, at 6:09 PM, Peter Yee pe...@akayla.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd or AD before
Ben,
See inline. If you are ok with these changes, I will go ahead and submit an
updated version of the draft.
On Nov 25, 2012, at 5:56 PM, Mahesh Jethanandani wrote:
Further trimming it to sections that require a response.
On Nov 21, 2012, at 3:12 PM, Ben Campbell wrote:
*** Minor
On 12/2/12 11:25 AM, Arturo Servin wrote:
So it is ok to have bad ideas as I+D, possibly harmful for the Internet
just to have a structured discussion?
Who said that?
Melinda
On 03/12/2012 15:41, Hannes Tschofenig wrote:
Hi all,
seeing all these discussions related to process improvements I just noticed
one annoying thing related to working group conference calls.
It turns out that the IESG guidelines on that topic (see
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie writes:
Stephen On 12/03/2012 02:50 PM, Barry Leiba wrote:
I'd really prefer if we'd talk about open source being desirable,
but not having it be necessary.
Stephen Yep. I got another comment to that effect as well. I'll
On 12/03/2012 04:21 PM, Sam Hartman wrote:
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie writes:
Stephen On 12/03/2012 02:50 PM, Barry Leiba wrote:
I'd really prefer if we'd talk about open source being desirable,
but not having it be necessary.
Stephen Yep. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/01/2012 12:12 PM, Stephen Farrell wrote:
Hi all,
I've just posted an idea [1] for a small process improvement. If it doesn't
seem crazy I'll try pursue it with the IESG as an RFC 3933 process
experiment. If its universally hated then
On 12/03/2012 04:41 PM, Marc Petit-Huguenin wrote:
I support this idea, but I think that free software should also be considered
as part of this experiment (free software and open source are not synonymous).
Using the acronym FOSS and defining it as Free or Open Source Software in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/03/2012 08:54 AM, Stephen Farrell wrote:
On 12/03/2012 04:41 PM, Marc Petit-Huguenin wrote:
I support this idea, but I think that free software should also be
considered as part of this experiment (free software and open source are
not
From: Keith Moore [mailto:mo...@network-heretics.com]
Years ago, my impression was that that Sunday training sessions were
pretty much ignored by anyone experienced in the organization. Is this
still the case?
[WEG] Depends on the subject matter. If they're all targeted at new attendees,
On Dec 2, 2012, at 10:46 AM, joel jaeggli wrote:
We have non-native english speakers and remote participants both working at a
disadvantage to follow the discussion in the room. We should make it harder
for them by removing the pretext that the discussion is structured around
material
On Nov 29, 2012, at 12:03 PM, SM wrote:
According to some RFC:
All relevant documents to be discussed at a session should be published
and available as Internet-Drafts at least two weeks before
a session starts.
If the above was followed there shouldn't be any draft submissions
Hi Hannes,
At 07:41 03-12-2012, Hannes Tschofenig wrote:
Why do we need to announce conference calls (or Jabber chats) on the
IETF announce mailing list? How likely is it that someone cares
about a working group effort, does not subscribe to the WG mailing
list, has not seen a poll about the
On Dec 3, 2012, at 8:01 PM, SM wrote:
There are people contributing to a working group who are not subscribed to
the mailing list. There are probably people who are not actively following a
working group who might attend a conference call.
Any data that supports your argument? Are there
Hannes,
On Dec 3, 2012, at 11:37 AM, Hannes Tschofenig wrote:
On Dec 3, 2012, at 8:01 PM, SM wrote:
There are people contributing to a working group who are not subscribed to
the mailing list. There are probably people who are not actively following
a working group who might attend a
Brian, Martin,
On 03/12/2012 06:01, Martin J. Dürst wrote:
One of the advantages of a standards organization such as the IETF is
cross-concern review. For the IETF, one very strong cross-concern is
security. Another one (also for my personally) is internationalization.
Another, more vague one,
Barry,
As I've said on the IESG list, I think this can
be far better done with an IESG statement that says that
implementation, testing, and deployment should be considered as we
(the community and the IESG) evaluate documents. Then we just make
sure we facilitate the process instead of
And I will strongly oppose any IETF policy that treats commercial or
proprietary code differently from Open Source code.
Out mantra is running code. We try to stay out of people's business
models.
The presence of a implementation is a useful measure. The presence of
interoperability
Hi Hannes,
At 11:37 03-12-2012, Hannes Tschofenig wrote:
Any data that supports your argument? Are there people subscribed to
the IETF announce list who just wait for conference calls they can join.
Please do not read this as data. There are about five messages daily
about webfinger from
Stephen,
Thanks for proposing this. You know that I agree with you that improving IETF's ability
to publish specifications relating to real code out there is important. It is important
to come up with ideas in this space. I think there has been situations where IETF has
strayed from the rough
Geoff, Randy,
Having reflected on your comments, I think that the two of you may be
approaching the same problem from two directions. I will try my best to
articulate the problem. When we agree that we have a common understanding of
the problem, we can decide whether to fix draft-bonica or
Hi Jari,
I agree with almost all of what you say. I think we only disagree
in two places, and perhaps more about tactics than anything else.
The first is whether or not its worthwhile addressing the specific
bit of process my draft tackles. I obviously do think it is, even
though you correctly
On Mon, 3 Dec 2012, Marc Petit-Huguenin wrote:
I support this idea, but I think that free software should also be considered
as part of this experiment (free software and open source are not synonymous).
Using the acronym FOSS and defining it as Free or Open Source Software in the
On 12/03/2012 10:50 PM, David Morris wrote:
On Mon, 3 Dec 2012, Marc Petit-Huguenin wrote:
I support this idea, but I think that free software should also be considered
as part of this experiment (free software and open source are not
synonymous).
Using the acronym FOSS and
On 04/12/2012, at 9:30 AM, Ronald Bonica rbon...@juniper.net wrote:
Geoff, Randy,
Having reflected on your comments, I think that the two of you may be
approaching the same problem from two directions. I will try my best to
articulate the problem. When we agree that we have a common
Stephen,
Your goal is laudatory, but the devil will be in the details. For example,
you wrote:
Note also that this experiment just needs an implementation that
makes it possible for the WG chairs and responsible AD to verify (to
the extent they chose) that the implementation matches the
Whoops, I meant that the draft and implementation match, sorry about that.
Cheers,
Andy
On Tue, Dec 4, 2012 at 10:59 AM, Andrew G. Malis agma...@gmail.com wrote:
Stephen,
Your goal is laudatory, but the devil will be in the details. For example,
you wrote:
Note also that this
On 2012/12/03 23:38, Elwyn Davies wrote:
Given that there is also open source code, reviewers have the chance to
take a look at that and see the degree of hackiness involved.
Well, yes. It's easy enough to evaluate stuff such as non-descriptive
variable names, messy indenting, and weird
Speaking of the devil in the details…
On Dec 4, 2012, at 3:59 AM, Andrew G. Malis agma...@gmail.com
wrote:
Stephen,
Your goal is laudatory, but the devil will be in the details. For example,
you wrote:
Note also that this experiment just needs an implementation that
makes it
On 2012-11-30 20:16, Richard Barnes wrote:
On Nov 30, 2012, at 2:10 PM, Wes Hardaker wjh...@hardakers.net wrote:
John C Klensin john-i...@jck.com writes:
I think changing the default is fine. I'd also be reluctant to
see the normal HTML version go away immediately but would be
especially
The IESG has approved the following document:
- 'OSPF Hybrid Broadcast and P2MP Interface Type'
(draft-ietf-ospf-hybrid-bcast-and-p2mp-06.txt) as Proposed Standard
This document is the product of the Open Shortest Path First IGP Working
Group.
The IESG contact persons are Stewart Bryant and
The IESG has approved the following document:
- 'Label Switched Path (LSP) Ping for Pseudowire FECs Advertised over
IPv6'
(draft-ietf-mpls-ipv6-pw-lsp-ping-04.txt) as Proposed Standard
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons
The RTCWEB working group would like to announce an upcoming interim
meeting.
The meeting will be held in the Boston, Massachusetts area on February
5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working
group. Full details, including meeting site, nearby hotels, and other
The IESG has received a request from the SIP Common Log Format WG
(sipclf) to consider the following document:
- 'Format for the Session Initiation Protocol (SIP) Common Log Format
(CLF)'
draft-ietf-sipclf-format-09.txt as Proposed Standard
The IESG plans to make a decision in the next few
The IESG has received a request from the Basic Level of Interoperability
for SIP Services WG (bliss) to consider the following document:
- 'Call Completion for Session Initiation Protocol (SIP)'
draft-ietf-bliss-call-completion-18.txt as Proposed Standard
The IESG plans to make a decision in
The IESG has received a request from the SIP Common Log Format WG
(sipclf) to consider the following document:
- 'The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
Framework and Data Model'
draft-ietf-sipclf-problem-statement-11.txt as Proposed Standard
A previous
The IESG has approved the following document:
- 'Internet Message Access Protocol (IMAP) - MOVE Extension'
(draft-ietf-imapmove-command-05.txt) as Proposed Standard
This document is the product of the IMAP MOVE extension Working Group.
The IESG contact persons are Barry Leiba and Pete Resnick.
65 matches
Mail list logo
