Steve writes:
> Actually, 3683 specifically requires community discussion of motions to
> block someone's posting rights. It is, in so many words, done by a
> Last Call.
>
Steve, I thought that RFC3683 is intended to apply "drastic measures"
(see intro, page 4).
RFC2418 allows a WG chair and
Bert,
David asked the IESG to consider a PR-action ("posting rights" action)
against Dean. Posting rights actions are governed by RFC 3683.
I agree that 3683 is used to apply drastic measures, but unfortunately those
are the measures the AD saw as appropriate for Dean's supposed infractions.
Eve
Wijnen, Bert (Bert) <[EMAIL PROTECTED]> wrote:
>
> I certainly hope that we do not have to have the equivalent of an
> "IETF Last Call" everytime that a WG chair or AD finds that an individual
> is disrupting normal WG process.
RFC 3683 (BCP 83) is concise enough to quote the applicable part i
>
> Wijnen, Bert (Bert) <[EMAIL PROTECTED]> wrote:
> >
> > I certainly hope that we do not have to have the equivalent of an
> > "IETF Last Call" everytime that a WG chair or AD finds that an
> > individual is disrupting normal WG process.
>
>RFC 3683 (BCP 83) is concise enough to quote th
Could we pick one of the six mailing lists to discuss this BOF? :-)
I'm guessing int-area would be appropriate - any counterexamples?
Thanks,
Spencer
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of ext Soohong Daniel Park
Sent: 27 September, 2005 02
The first goal might be to run IPv6 basic operation over 802.16/(e).
Additionally, based on that, the interaction betwwen 802.16e and IPv6 for the
seamless IPv6 mobility could fall in the scope as written in the charter. :)
-from a part of the charter -
As for fast mobility, the characteristics o
That's the reason the process model delegates handling such problems to
specific individuals, rather than having all of us, together, participate in
the review and assessment.
Actually, 3683 specifically requires community discussion of motions to
block someone's posting rights. It is, in
The procedures for management of the IETF list are detailed in RFC 3005
(the IETF list charter).
Note that there are presently selected IETF sergeants-at-arms.
Harald
--On 27. september 2005 03:58 -0700 Nick Staff <[EMAIL PROTECTED]>
wrote:
Could you please specify the RFC
On Tue, 27 Sep 2005, Nick Staff wrote:
> John-
>
> Could you please specify the RFC that details the procedure for when an AD
> requests that the IESG remove someone's posting privileges from the IETF
> list (the RFC other 3683 of course). If there isn't one then I'd have to
> ask that you refrai
If we want to get some clarity in this debate it would be appropriate
to quote the relevant RFCs. RFC 2418 has been updated by RFC 3934
(BCP 94). The change is that posting rights on a WG mailing list is
not removed anymore by the IESG on AD proposition. But by the WG
Chair, for a maximum perio
Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
From:Dean Anderson <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| It is not DNSSEC that is broken.
I have not been following dnsop discussions, but from this summary, there
is nothing broken beyond your understanding
In message <[EMAIL PROTECTED]>, "Nick Staff" writes:
>
>> ]
>> ] 7.2 Approval to block participant on a WG list (Bert
>> Wijnen) ] ] This management issue was discussed. The IESG
>> agrees that Bert ] Wijnen may block posting rights for Dean
>> Anderson on the dnsops ] mailing list if he refuse
> Behalf Of Dave Crocker
> For another, individual pique is best pursued either by
> private exchange or
> through formal complaint. Neither requires burdening the
> full IETF list.
I disagree, hard cases make bad law, good cases make bad procedure. It
is easy to see why process is unnecessar
> From: Dean Anderson [mailto:[EMAIL PROTECTED]
> It is not DNSSEC that is broken.
Anycast has been deployed for four years. Any change to the DNS
infrastructure that is incompatible with use of anycast is not
acceptable and will not be deployed.
Anycast significantly improves the response tim
I'm interested to know whether people would see arguments for
either or both of
1. An IETF Ombudsman (or Ombudscommittee), to act as a dispute
mediator.
2. An IETF "netiquette" committee, to offload list banning procedures
from the IESG.
Brian
Dave Crocker wrote:
That's the reason the pr
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> In message <[EMAIL PROTECTED]>, "Nick Staff" writes:
> >
> >> ]
> >> ] 7.2 Approval to block participant on a WG list (Bert
> >> Wijnen) ] ] This management issue was discussed. The IESG agrees
> >> that Ber
Dear Brian;
On Tue, 27 Sep 2005 17:15:05 +0200
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> I'm interested to know whether people would see arguments for
> either or both of
>
> 1. An IETF Ombudsman (or Ombudscommittee), to act as a dispute
> mediator.
>
> 2. An IETF "netiquette" committee, t
In <[EMAIL PROTECTED]> Robert Elz <[EMAIL PROTECTED]> writes:
> | Without getting into to much detail, Anycast doesn't work with TCP,
> | but it also doesn't work with large UDP packets and fragments.
>
> Anycast does not work (or perhaps more correctly, in some circumstances
> when there is
On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
> Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
> From:Dean Anderson <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | It is not DNSSEC that is broken.
>
> I have not been following dnsop discussions, but from th
Brian,
This is a fine document. Perhaps appropriately, it doesn't say
much of anything.
Is the actual trust agreement a secret, or does the IETF and
IASA intend to make it public before the IESG approves it? Will
there be an IETF Last Call that includes an opportunity to
review the docume
All -
As I outlined in my presentation at IETF 63*, the IAOC is pursuing the
notion of a dedicated IPR Trust. We have been through several revisions of
the Trust document and have developed a formula that we believe will work
for all parties. Below you'll find a summary of the current framework fo
On Tue, 27 Sep 2005, John C Klensin wrote:
> Brian,
>
> This is a fine document. Perhaps appropriately, it doesn't say
> much of anything.
>
> Is the actual trust agreement a secret, or does the IETF and
> IASA intend to make it public before the IESG approves it? Will
> there be an IETF Last Ca
--On Tuesday, September 27, 2005 15:41 -0700 "Lucy E. Lynch"
<[EMAIL PROTECTED]> wrote:
On Tue, 27 Sep 2005, John C Klensin wrote:
Brian,
This is a fine document. Perhaps appropriately, it doesn't
say much of anything.
Is the actual trust agreement a secret, or does the IETF and
IASA in
On Tue, 27 Sep 2005, John C Klensin wrote:
>
>
> --On Tuesday, September 27, 2005 15:41 -0700 "Lucy E. Lynch"
> <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 27 Sep 2005, John C Klensin wrote:
> >
> >> Brian,
> >>
> >> This is a fine document. Perhaps appropriately, it doesn't
> >> say much of anythin
--On Tuesday, September 27, 2005 16:29 -0700 "Lucy E. Lynch"
<[EMAIL PROTECTED]> wrote:
But any new BCP, or modification to a BCP is. And, whatever
the negotiations might be that you need to get there, this
isn't an "agreement with an outside organization", it is how
IETF IPR is managed by the
Thus spake "wayne" <[EMAIL PROTECTED]>
> In <[EMAIL PROTECTED]> Robert Elz <[EMAIL PROTECTED]> writes:
> > Anycast does not work (or perhaps more correctly, in some
> > circumstances when there is routing instability, will not work) with
> > fragmented UDP packets (the size of the packets is irrele
As a lurker, love him or hate him, Dean does evoke responses as varied
as any I've observed. Unfortunately all too often that's the only way
some truth will be allowed to leak out. Or people finally put pieces
together.
-Original Message-
From: Stephen Sprunk <[EMAIL PROTECTED]>
To
C.M. - One of us has horribly missed the point of John's email (I'm not
inferring it's you). Whichever one of us it is, the good news is I think we
actually agree with each other =)
The passage you quoted was indeed quoted by John but the way I read his post
was that he was quoting it to show ho
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>
> I'm interested to know whether people would see arguments for
> either or both of
>
> 1. An IETF Ombudsman (or Ombudscommittee), to act as a
> dispute mediator.
>
> 2. An IETF "netiquette" committee, to offload list banning
> procedu
On Tuesday, September 27, 2005 08:08:02 PM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
Again, that justifies keeping the agreement private while you are
negotiating. I don't question that. As I understand BCP 101, you are
even entitled to keep such agreements private from the IESG and
I'm rather reticent to add real technical discussion to the issue of list
mismangement.
On Tue, 27 Sep 2005, Bill Sommerfeld wrote:
> On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
> > Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
> > From:Dean Anderson <[EMAIL PROTECTED]>
On Tue, Sep 27, 2005 at 06:47:36PM -0700, Nick Staff wrote:
> > 2. An IETF "netiquette" committee, to offload list banning
> > procedures from the IESG.
>
> I'm a big fan of the netiquette committee. I'd like to suggest that
> volunteers be allowed to "throw their names into the hat" and that mem
Yaakov, if you can gather some people and write a draft and a
concrete BOF agenda, the existing ADs will look at it
seriously - but new work needs new hands and brains.
Brian
Yaakov Stein wrote:
Secondly, I don't think this area is an attempt to take the
IETF where no IETF has gone before
...
My proposition would be to create a "minority position" system. Where
such groups could be accepted as opposing without having to be fighting.
There is a perfectly civilised way of handling minority opinions already.
Please see RFC 3246 and RFC 3248 for an example I was personally
involve
On Tue, 27 Sep 2005, Stephen Sprunk wrote:
> Anycast in the face of PPLB has been accepted (by most of us, at least)
> specifically for the root servers because current queries to the roots do
> not need to be fragmented and do not use TCP.
Right. But all DNS in the past (and most in the present)
35 matches
Mail list logo
