On Fri, 1 Jul 2005, Scott W Brim wrote:
You can add me to the "satisfied" column. The IESG is asked to take
positions and to lead (despite what a few think). That's risky -- no
matter what they do they get criticism from somewhere. Maybe they
didn't *phrase* the announcement perfectly, but the
And I apologize for having nothing whatsoever to say about spamops,
killfiles, or steering.
as well you should.
"we" will let it slide this time, Mr. Dawkins.
but don't let it happen again.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MO
unsubscriber
***This
e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use
of the information conta
Scott W Brim wrote:
On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote:
My view is that your impression of the reaction is incorrect. in
taking the position that respondents can be classified as either:
a) being satisfied with the IESG *decision*, b) dissatisfied or
uncomfortable with t
On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote:
> My view is that your impression of the reaction is incorrect. in
> taking the position that respondents can be classified as either:
> a) being satisfied with the IESG *decision*, b) dissatisfied or
> uncomfortable with the decision, or c)
Date:Wed, 29 Jun 2005 17:39:37 -0400
From:Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The arguments against what the IESG has done seem,
| mostly, to be that we should have gotten IETF consensus before
| making a decision.
That is
Date:Thu, 30 Jun 2005 17:21:10 -0400
From:Sam Hartman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The RFc 2780 procedures are a sparse. We'd all be happier if the
| community had given us more advice on what criteria to use when
| evaluating hop-by-ho
As a general statement, I think this document goes too far.
Several issues occur to me reading it. A sampling follow.
1) As written, the document seems to say that all small allocation spaces
should be "repaired". This does not always follow. Making the IP version
space bigger does not seem
> From: Brian E Carpenter
>
> I'm supposed to be on vacation so this will be brief, but I don't
> think that your assertion about what "the community" has said is
> backed up by postings from a sufficient number of people to be a
> community view. Most people in the community haven't posted on
If I may plead for a moment of silence ...
There is an Internet Draft that is intended to give the community a
chance to provide comments on what the IETF vision of option
registration might be - or, might not be.
If we could discuss this draft, and say things like "I agree", "I
disagree", "
Date:Fri, 01 Jul 2005 03:25:25 +0200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| As I said in the plenary in Minneapolis, my goal is for the IESG to be
| able to *steer*. Not to rule. Steering means finding the narrow line
| betwe
Dave,
I'm supposed to be on vacation so this will be brief, but I don't think
that your assertion about what "the community" has said is backed up
by postings from a sufficient number of people to be a community view.
Most people in the community haven't posted one way or the other. I
haven't cou
On Thursday, June 30, 2005 06:50:30 PM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
It seems to me that the key text in 3932 is
In March 2004, the IESG decided to make a major change
in this review model. The new review model will have
the
--On Thursday, 30 June, 2005 17:21 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:
>> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
>
> John> Hans, I think this formulation is consistent with
> what I, John> and others, have been trying to say. I
> would, however, add John>
On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage
<[EMAIL PROTECTED]> wrote:
Brian E Carpenter wrote:
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could
harm a device that does not want to deal with it.
If it interferes with congestion
Brian E Carpenter wrote:
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could
harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it
can potentially damage
every other packet stream. T
> The community believes that the IESG has management
responsibility for the timeliness ande appropriateness of the output
of the IETF.
Sam,
I think you have identified the crux of a very serious disconnect.
Wherever did you obtain the view that the community delegated this
responsibilit
> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> Hans, I think this formulation is consistent with what I,
John> and others, have been trying to say. I would, however, add
John> one element.
John> However, especially since the IETF maintains liaisons with
John>
On Wednesday, June 29, 2005 04:18:18 PM -0400 Margaret Wasserman
<[EMAIL PROTECTED]> wrote:
I don't think the fact that the IESG did not choose to exercise its
authority to allocate this IP option number precludes the proponents of
this allocation from attempting to gain IETF consensus (for w
On Thu, 30 Jun 2005, Dave Crocker wrote:
[...]
Are there any materials to use as input, either as exemplars or possibly even
as a beginning specification? This latter would be particularly helpful for
the success of the effort?
FWIW, when I read the BoF description, I started wondering about
Vlad,
Howdy.
[EMAIL PROTECTED] wrote:
> The attached is the description and agenda of Remote UI BOF (rui) for
IETF63. Those interested are encouraged to attend. Thanks!
I would like to help with your effort. My original professional focus was on
human factors and cognitive psychology. F
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it can
potentially damage
every other packet stream. This is a *very* complex discuss
Dean,
Please stop repeating assertions about alleged liars.
Sergeants-at-arms, please pay attention since I believe that we
may need to consider action if this continues.
Brian
Dean Anderson wrote:
On Mon, 27 Jun 2005, Dave Crocker wrote:
I thought we also had a mechanism for taking actio
On Thu, Jun 30, 2005 at 01:48:03AM -0400, Dean Anderson wrote:
> Since when are _true_ facts about liars on a subject (open relays)
> discussed in an IETF RFC, egregious? Is it against list policy to assert
> that the IETF should be honest, and not associate with liars? I missed
> that part. Pe
Hi,
The attached is the description and agenda of Remote UI BOF (rui) for IETF63.
Those interested are encouraged to attend. Thanks!
Regards,
Vlad
Remote UI BoF (rui)
---
CHAIRS
Vlad Stirbu <[EMAIL PROTECTED]>
TBA
DESCRIPTION:
The Remote UI is a mechanism that enables user
Dean,
You are wasting my time and personally yours.
Please take this somewhere else or at least take the ietf mailer
off your emials. Others have indicated a lack of desire to
hear your comments also.
Mike
On Thu, 30 Jun 2005, Dean Anderson wrote:
> These are generally good rules. Too bad yo
Dear John,
the subject is of importance and cannot be dealt with an individual's draft
in Franglish. "Qui va piano va sano", "doucment, doucement nous sommes
pressés" (Talleyrand).
As a liaison to ICANN BoD you know that the criteria I quote are those
(reviewed by a two years experiment) of t
Hans,
I think this formulation is consistent with what I, and others,
have been trying to say. I would, however, add one element.
The IESG was asked to approve a code point for work developed
elsewhere. There is no question that they could have approved
it and approved it on the basis of the re
Jefsey,
Many of us await, with great interest, the appearance of an
Internet Draft from you that explains how, with a field with a
finite (and fairly small) number of bits available, once can
carry out an arbitrary number of properly-identified
experiments. Even a discussion about how one might m
29 matches
Mail list logo
