On 2012-04-19 23:27, Ronald Bonica wrote:
...
> I think that this is a case-by-case judgment call. In some cases (e.g., RFC
> 1475), the experiment is clearly over. IMO, allowing RFC 1475 to retain
> EXPERIMENTAL status detracts from the credibility of current experiments that
> share the label.
Hi,
On Apr 19, 2012, at 22:31, Adrian Farrel wrote:
> The IESG has been discussing how to tidy up after Experimental RFCs.
>
> We have developed the following draft IESG statement. This does not
> represent a change in process, and continues to value Experimental RFCs
> as an important part of t
> On 2012-04-19 23:27, Ronald Bonica wrote:
> ...
> > I think that this is a case-by-case judgment call. In some cases (e.g., RFC
> > 1475), the experiment is clearly over. IMO, allowing RFC 1475 to retain
> > EXPERIMENTAL status detracts from the credibility of current experiments
> > that shar
Hi Lars,
At 00:31 20-04-2012, Eggert, Lars wrote:
any IESG statement would only cover Experimental RFCs on the IETF
Stream, right?
Yes.
The proposed statement comes out as dropping a canary in a coal mine.
Regards,
-sm
Hi Brian,
My personal observation is that some folks are just too afraid about
success of some 12 experimental RFCs to be published soon and are
already actively seeking a formal way to kill them in the not too
distant future.
If the goal here is really about clean-up of dead experiments - I
I have to admit to laughing out loud when I saw the IESG's announcement. Why?
What is more important: cycling out Experimental RFC's or promoting Proposed
Standards to Internet Standards?
Do I hear chirping in the audience? If we need to focus "spare cycles"
anywhere, I would offer progressing
Hi,
On Apr 19, 2012, at 22:38, Eliot Lear wrote:
> I do not support such a view, and it is not supported in a plain reading
> of RFC 2026. What's more, it's not how researchers work. Researchers
> naturally move on. If we are looking to further push researchers away
> from the IRTF, this is a g
Hi Lars,
I was just typing a similar response to Eliot and Scott.
Clearly the IESG does not have authority over the IRTF stream.
I had thought this context ant the limitation to the IETF stream was clear in
the initial blurb ("Experiments are an established and valuable part of the IETF
process.
Any reason why I cannot see the e-mail to which this is a reply?
It never arrived at my MUA, which could well be my MUA, but it is not in the
ietf archives either which suggests ? I seem to recall this happening
before from the same e-mail address on this same list.
What else am I, and I ass
Hi,
I sort of agree that no new legislation is needed, and I don't read the
statement as legislation.
But it is clear that, with the exception of promotion of Experimental RFCs onto
the Standards Track, this function has not been happening. It makes sense (I
think) to set expectations.
Adria
one aspect that may be missed is that there is a body of experimantal
documents which were not really experiments, but were classified as
such because of layer nine silliness.
randy
Adrian Farrel wrote:
> [Lars Eggert wrote:]
>> On Apr 19, 2012, at 22:31, Adrian Farrel wrote:
>>
>>> The IESG has been discussing how to tidy up after Experimental RFCs.
The IESG (IMHO) feels it has a responsibility to manage Experiments
it starts. This is evidenced by the care they take to
On 2012-04-20 08:55, Eric Burger wrote:
> I have to admit to laughing out loud when I saw the IESG's announcement. Why?
> What is more important: cycling out Experimental RFC's or promoting Proposed
> Standards to Internet Standards?
>
> Do I hear chirping in the audience? If we need to focus "
What about the idea of requiring new Experimental documents to include text
that indicates when the experiment is to be considered completed absent new
work on it? Essentially, the document declares a date by which the experiment
is considered concluded, and code points automatically deprecated
Hi -
> From: "Randy Bush"
> To: "Adrian Farrel"
> Cc: "IETF Disgust" ; "IESG"
> Sent: Friday, April 20, 2012 2:04 AM
> Subject: Re: Proposed IESG Statement on the Conclusion of Experiments
>
> one aspect that may be missed is that there is a body of experimantal
> documents which were not reall
On 20/04/2012 14:36, Murray S. Kucherawy wrote:
What about the idea of requiring new Experimental documents to include text
that indicates when the experiment is to be considered completed absent new
work on it? Essentially, the document declares a date by which the experiment
is considered c
On 2012-04-20 16:12, Stewart Bryant wrote:
> On 20/04/2012 14:36, Murray S. Kucherawy wrote:
>> What about the idea of requiring new Experimental documents to include
>> text that indicates when the experiment is to be considered completed
>> absent new work on it? Essentially, the document declar
On 4/20/2012 6:36 AM, Murray S. Kucherawy wrote:
What about the idea of requiring new Experimental documents to
include text that indicates when the experiment is to be considered
completed absent new work on it? Essentially, the document declares
a date by which the experiment is considered c
>So, the standard question: what's the problem that needs solving here?
I presume that the issue motivating this is RFCs 4405 through 4408,
which define two experimental mail validation schemes Sender-ID and
SPF that, for reasons that sort of made sense at the time, interpret
the same DNS TXT reco
I support the thoughts expressed by Eliot Lear, Scott Bradner,
Lars Eggert and several others that research often does not
have a crisp conclusion and that not all Experimental RFCs
describe a scientific experiment. For example, Transaction TCP
(T/TCP) research was active in at least two differ
encouraging a report is fine
retracting the code points seems to add more confusion than it is worth unless
the
code space is very tight
and I see no reason to obsolete the experimental rfc or move it to historic
status unless the report is
that some bad thing happens when you try it out - upda
I agree with everything Scott wrote. I don't see a good reason for removing
code points from a registry, unless very exceptional cases (range is almost
full need more space), which could be processed as one-off, not as a regular
process.
Marc.
Le 2012-04-19 à 16:48, Scott O Bradner a écrit :
On 4/20/12 7:23 AM, Brian E Carpenter wrote:
Exactly. This whole discussion seems to be about over-engineering a
small corner of the IETF process that isn't a particular source
of practical problems anyway, afaik.
Reading the back-and-forth on this I think at this point I feel pretty
strongly t
Hi John,
At 09:24 20-04-2012, John Levine wrote:
I presume that the issue motivating this is RFCs 4405 through 4408,
I read the message at
http://www.ietf.org/mail-archive/web/spfbis/current/msg01344.html
publishing, but that's different from inventing an entire process to
deal with a one-o
On Apr 20, 2012, at 5:40 AM, Andrew Sullivan wrote:
> On Fri, Apr 20, 2012 at 12:17:46AM +0300, Yoav Nir wrote:
>
>> The "Experimental" designation typically denotes a specification that
>> is part of some research or development effort.
>>
>> However, I do not believe that this is still ty
Folks,
I would like to clarify a few points regarding this statement. Specifically,
- It applies only to documents that were published on the IETF stream.
- It does not apply to documents that were published on the IAB, IRTF or
Independent streams.
- Reuse of deprecated code points is not a goa
Hi -
> From: "Ronald Bonica"
> To: ; ;
> Sent: Friday, April 20, 2012 1:56 PM
> Subject: RE: Proposed IESG Statement on the Conclusion of Experiments
> If this IESG statement is published, none of that changes.
It might be helpful to say what *would* change upon publication
of this stateme
On 4/20/12 4:28 PM, DRAGE, Keith (Keith) wrote:
Changing something from experimental to proposed standard in a
process that will probably take 12 months will be unlikely change the
number of people implementing and deploying an RFC.
I'm going to take the liberty of mentioning that I spoke with
I am a newbie. Could anyone clarify about the following issue?
I am aware that once a session for SMTP is established it could be used for
multiple transactions.
Let's say that there are two SMTP servers, A and B, and A initiates a
session (TCP connect to B). After A finished one transaction (tra
>Let's say that there are two SMTP servers, A and B, and A initiates a
>session (TCP connect to B). After A finished one transaction (transferring
>some email content from A to B), is it possible B starts transferring some
>email content to A using the same TCP connect?
The short answer is no.
Th
On 4/20/2012 9:51 PM, John Levine wrote:
The longer answer is that thirty years ago, in RFC 821 there was a
TURN command which does what you suggest, switches the roles of the
two ends of the SMTP session. But that turns out to be a giant
security hole, since a bad guy A' could steal mail by c
> there's a WG that is doing a standards track update
This is hardly a new situation. Normal procedure would be for
that WG to initiate relevant actions to obsolete the alternative.
I may be missing something, but I fail to see why this needs
an IESG statement.
Regards
Brian
On 2012-04-20 17:
32 matches
Mail list logo
