Hi Stephen,
I think it is great idea, I hope it does not die, we need fast-tracks,
without delays, however, giving a fixed time limit for WG feedback and
WG discussion is important (suggested 6 months), because discussions
about running code should not be ignored. The draft seems to not give
Hiya,
This proposal only kicks in (as an option) after the WG have
done their job, however they choose to do that (within the
IETF process).
Later on, it might be a fine idea to try extend the fast-track
concept so that a WG has a structured way do similar things
but IMO that'd be better done
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 comments.
But there's a catch here: There
i think we're ratholing here. the point i get is that, if there is open
source code that suppliments the drafts sufficiently to lend confidence
in the implementability and implementation, then progress might be
accelerated.
But the point of running code in our nice, catchy slogan, is that
On Dec 4, 2012, at 9:46 AM, Barry Leiba wrote:
But the point of running code in our nice, catchy slogan, is that
running doesn't mean simply that it runs. It means that it's
actually *in use*, possibly for real, but at least in a test lab where
it's getting real use. *Real* running code
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
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 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
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 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
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
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
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
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 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
Another condition for a fast track must be the absence of
unresolved IPR disclosures. I can see a big risk here - that
someone will use the fast track procedure to game the IPR
disclosure rule. First, release your open source code, using
an open source licence that doesn't assert the absence of
Hiya,
On 12/01/2012 09:06 PM, SM wrote:
Could you ask an AD to sponsor this draft and generate the Last Call?
Bit early yet. I'd like to know what folks think and hopefully
improve the thing via others' good ideas.
Regards,
-sm
P.S. Make the draft experimental. Add a one-year timer.
Hi Hector,
On 12/02/2012 12:47 AM, Hector Santos wrote:
This proposal sounds interesting but couldn't it run into conflicts when
there are competition in running code? Who's running code do you fast
track? How does it apply in the protocol updates area, i.e. BIS work?
Good point. I
Hi Brian,
On 12/02/2012 08:41 AM, Brian E Carpenter wrote:
Another condition for a fast track must be the absence of
unresolved IPR disclosures. I can see a big risk here - that
someone will use the fast track procedure to game the IPR
disclosure rule. First, release your open source code,
Hiya,
On 12/02/2012 12:21 AM, Barry Leiba wrote:
I, and I believe lots of us, do want to encourage running code
more than now. This is one attempt to help with that. Why not
try it and see?
Because as a reward for claiming to have running code, I think it's
a terrible idea. As a way of
On 12/01/2012 11:51 PM, Melinda Shore wrote:
On 12/1/12 2:21 PM, Stephen Farrell wrote:
My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better.
I think that's actually a pretty terrible
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 architecture. Early running code is
very often
On 12/1/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
that's fine, it can die.
The IESG have seen
On 12/1/12 11:36 AM, Dave Crocker wrote:
What actual problem is this trying to solve? I see the reference to a
'reward', but wasn't aware that there is a perceived problem needing
incentive to solve.
I gather this is one of those everybody knows problems, where
everybody knows that it takes
Hi Stephen,
At 12:12 01-12-2012, Stephen Farrell wrote:
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.
In Section 1:
The idea
On Dec 1, 2012, at 10:36 PM, Dave Crocker d...@dcrocker.net wrote:
What actual problem is this trying to solve? I see the reference to a
'reward', but wasn't aware that there is a perceived problem needing
incentive to solve.
I think the problem is in the subject line. Documents go
On 12/1/2012 1:00 PM, Melinda Shore wrote:
On 12/1/12 11:36 AM, Dave Crocker wrote:
What actual problem is this trying to solve? I see the reference to a
'reward', but wasn't aware that there is a perceived problem needing
incentive to solve.
I gather this is one of those everybody knows
[1] http://tools.ietf.org/id/draft-farrell-ft
I have a serious problem with the premise of the proposal.
The short version is that if the process we're talking about is
useful, we should not shortcut it as a reward for anything. And if
it's not useful, we should not be doing it, regardless of
Hi Dave,
On 12/01/2012 10:13 PM, Dave Crocker wrote:
On 12/1/2012 1:00 PM, Melinda Shore wrote:
On 12/1/12 11:36 AM, Dave Crocker wrote:
What actual problem is this trying to solve? I see the reference to a
'reward', but wasn't aware that there is a perceived problem needing
incentive to
On 12/01/2012 10:22 PM, Barry Leiba wrote:
[1] http://tools.ietf.org/id/draft-farrell-ft
I have a serious problem with the premise of the proposal.
The short version is that if the process we're talking about is
useful, we should not shortcut it as a reward for anything.
I disagree.
Stephen,
On 12/1/2012 2:56 PM, Stephen Farrell wrote:
At a minimum, any proposal for change should be expected to justify the
specific problem it is claiming to solve --
Disagree. RFC 3933 says:
A statement of the problem expected to be resolved is
desirable but not required...
The
On 12/1/12 2:21 PM, Stephen Farrell wrote:
My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better.
I think that's actually a pretty terrible reason. The goal is
not to get the proposal
I have a serious problem with the premise of the proposal.
The short version is that if the process we're talking about is
useful, we should not shortcut it as a reward for anything.
I disagree. The process is neither useful nor just a PITA. Its both,
depending on what document and point of
I, and I believe lots of us, do want to encourage running code
more than now. This is one attempt to help with that. Why not
try it and see?
Because as a reward for claiming to have running code, I think it's
a terrible idea. As a way of handling the process for documents where
it makes
This proposal sounds interesting but couldn't it run into conflicts
when there are competition in running code? Who's running code do
you fast track? How does it apply in the protocol updates area, i.e.
BIS work?
This proposal and thread, similar to the recent others, all seem to be
Melinda Shore wrote:
On 12/1/12 2:21 PM, Stephen Farrell wrote:
My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better.
I think that's actually a pretty terrible reason. The goal is
not to
56 matches
Mail list logo
