On 26/10/2012 02:22, Richard Barnes wrote:
would be wrong. The idea here is that applying _punitive_ action (such
as removal from a position) retroactively is not fair,
Oh, for heaven's sake. This is nothing to do with punishment. This
is a straightforward administrative problem. Turning
On 25/10/2012 19:40, Doug Barton wrote:
On 10/25/2012 12:46 AM, Brian E Carpenter wrote:
On 24/10/2012 20:34, Doug Barton wrote:
...
... Nothing in the text suggests an
unfettered right of creating new definitions of vacant.
You mean, new compared to the first definition in
Brian, Richard, others,
Oh, for heaven's sake. This is nothing to do with punishment. This
is a straightforward administrative problem. Turning this into an
opportunity to exercise a heavyweight and in fact punitive process
would be an injustice. If the IETF has wound itself into such
On Thu, Oct 25, 2012 at 11:34:41AM -0700,
IESG Secretary iesg-secret...@ietf.org wrote
a message of 28 lines which said:
The IEEE Registration Authority (IEEE RA) assigns Ethertypes
I suggest it would be a good idea to have the stable URL of the
statement
At 15:51 25-10-2012, Sam Hartman wrote:
2) IETF process documents require approval by the ISOC BOT.
Not really. The ISOC Board of Trustees is not in the loop when it
comes to IETF document approval.
3) There is a variance procedure. I've always been puzzled by it because
it seems to
and IAOC is unable to change its own quorum requirement because . . .
it can't achieve the necessary quorum!!
Now that _is_ a serious administrative oversight.
--
On 26 October 2012 02:21, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Oct 25, 2012 at 01:19:26PM -0700, Tony Hain wrote:
Clearly
SM == SM s...@resistor.net writes:
So, I'm puzzled by this. my claim was that ISOC needed to approve
process related BCPs. If you take a look at RFC 2031, it supports that
claim. However, I'd kind of expect the other half of this to be in RFC
2026. I certainly recall us sending things like
On Oct 26, 2012, at 3:11 AM, Brian E Carpenter wrote:
On 26/10/2012 02:22, Richard Barnes wrote:
would be wrong. The idea here is that applying _punitive_ action (such
as removal from a position) retroactively is not fair,
Oh, for heaven's sake. This is nothing to do with punishment. This
Andrew,
On 10/25/12 9:52 PM, Andrew Sullivan wrote:
Oh, for heaven's sake. This is nothing to do with punishment. This is
a straightforward administrative problem. Turning this into an
opportunity to exercise a heavyweight and in fact punitive process
would be an injustice. If the IETF has
On 2012-10-05 17:12, Julian Reschke wrote:
Hi James,
see below for my (mostly editorial) feedback:
I note that there was no reply to this mail, and at least one problem is
still present in the latest draft...:
2.2. Examples
The following examples illustrate the use of various
Bob,
I've read through the draft, and would prefer a different approach.
Since we already have a recall procedure for contested removals, this
draft should focus itself on uncontested removals, and really just
*absense*. How do you test if something is uncontested? Easy enough:
ask the IETF
Hi Sam,
So, I'm puzzled by this. my claim was that ISOC needed to approve
process related BCPs. If you take a look at RFC 2031, it supports that
claim. However, I'd kind of expect the other half of this to be in RFC
2026. I certainly recall us sending things like BCP 101 before the ISOC
I've read the draft. I think its the wrong approach, mainly because its
focusing on the current problem rather than a new mechanism.
In general, I know of 5 ways an elected or appointed position may become
vacant: resignation, death, incapacity, recall or expulsion.
We currently have
On 10/26/12 4:29 PM, Michael StJohns wrote:
I'm using expulsion here the way its used in the US political system - a
legislative body may choose to expel one of its members for various reasons.
I propose that we define such a mechanism for the IETF bodies.
Why should bodies have this
At 11:02 AM 10/26/2012, Eliot Lear wrote:
On 10/26/12 4:29 PM, Michael StJohns wrote:
I'm using expulsion here the way its used in the US political system - a
legislative body may choose to expel one of its members for various reasons.
I propose that we define such a mechanism for the
The IAB is working on a document about Technical Considerations for Internet
Service Filtering,
http://tools.ietf.org/html/draft-iab-filtering-considerations-01. Feedback
and discussion are welcome on the architecture-discuss list,
https://www.ietf.org/mailman/listinfo/architecture-discuss.
--On Friday, October 26, 2012 11:11 -0400 Michael StJohns
mstjo...@comcast.net wrote:
...
On 10/26/12 4:29 PM, Michael StJohns wrote:
I'm using expulsion here the way its used in the US
political system - a legislative body may choose to expel
one of its members for various reasons. I
Thank you, Joel, for putting pen to paper (pixels to glass?) on this,
and thank you, Jari, Randy, and Warren for sharing your thoughts.
As was pointed out, we've had conversations about LIMs previously. It
might be worth asking Ray to provide a paragraph or two on history and
the motivations
On 10/26/12 9:00 AM, Spencer Dawkins wrote:
Thank you, Joel, for putting pen to paper (pixels to glass?) on this,
and thank you, Jari, Randy, and Warren for sharing your thoughts.
As was pointed out, we've had conversations about LIMs previously. It
might be worth asking Ray to provide a
At 11:39 AM 10/26/2012, John C Klensin wrote:
In principle, I have no problem with setting up a list of
repeated/ long-term non-feasance, non-appearance, or
non-responsiveness conditions that are treated as equivalent to
a more formal resignation unless the body of which that person
is a member
On 10/26/2012 12:20 AM, Brian E Carpenter wrote:
On 25/10/2012 19:40, Doug Barton wrote:
On 10/25/2012 12:46 AM, Brian E Carpenter wrote:
On 24/10/2012 20:34, Doug Barton wrote: ...
... Nothing in the text suggests an unfettered right of
creating new definitions of vacant.
You mean, new
On 26 Oct 2012, at 12:04 , The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops)
to consider the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
draft-ietf-v6ops-ra-guard-implementation-04.txt
as Best Current
--On Friday, October 26, 2012 12:25 -0400 Michael StJohns
mstjo...@comcast.net wrote:
...
I'm pretty much going to object to any condition based model
that anyone proposes, because we're really bad at a) figuring
out the complete list of all possible conditions that could
ever happen, b)
Ran,
I agree that the references to I-D.gont-6man-oversized-header-chain and
gont-6man-nd-extension-headers should both be NORMATIVE, and not INFORMATIVE.
Sorry for having missed this.
If Fernando were to post an updated version that makes this change, would it
address all of your issues? If
On 26 Oct 2012, at 14:01 , Ronald Bonica wrote:
I agree that the references to I-D.gont-6man-oversized-header-chain
and gont-6man-nd-extension-headers should both be NORMATIVE,
and not INFORMATIVE. Sorry for having missed this.
Thank you.
If Fernando were to post an updated version that
On Oct 26, 2012, at 8:16 AM, Eliot Lear l...@cisco.com wrote:
Andrew,
On 10/25/12 9:52 PM, Andrew Sullivan wrote:
Oh, for heaven's sake. This is nothing to do with punishment. This is
a straightforward administrative problem. Turning this into an
opportunity to exercise a heavyweight and
**Early Bird Registration Cutoff: TODAY Friday, 26 October 2012**
**Registration Cancellation: Monday, 29 October 2012**
85th IETF Meeting
Atlanta, GA, USA
November 4-9, 2012
Host: North American Cable Industry
**PLEASE NOTE: Daylight Saving Time (United States) ends Sunday, November 4,
2012 at
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
draft-ietf-v6ops-ra-guard-implementation-04.txt as Best Current
Practice
The IESG plans to make a decision in the
The Hilton Atlanta is currently sold out of guest rooms but we have recently
received some reservation cancellations. If you would like to stay at the
Hilton but have been unable to get a reservation, please let us know and we can
make substitutions.
We have around 7 cancellations in the date
We received quite a few responses to our message regarding canceled
reservations, at this time we cannot take any more substitutions since we have
received more responses than the number of canceled rooms! We will try to get
as many people in to the Hilton as possible.
If anyone else that
A new Request for Comments is now available in online RFC libraries.
RFC 6780
Title: RSVP ASSOCIATION Object Extensions
Author: L. Berger,
F. Le Faucheur,
A. Narayanan
Status: Standards Track
This is a call for nominations for the IAB appointment to the IETF
Administrative Oversight Committee (IAOC). The nomination period will close
on 2 November 2012.
IAOC membership is described in BCP 101 (RFC 4071) Section 4, with selection
guidelines and process documented in BCP 113 (RFC
32 matches
Mail list logo
