Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard

2008-04-07 Thread Pekka Savola
On Thu, 3 Apr 2008, The IESG wrote: The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'Multicast Negative-Acknowledgment (NACK) Building Blocks ' draft-ietf-rmt-bb-norm-revised-04.txt as a Proposed Standard The IESG plans

RE: Blue Sheet Change Proposal

2008-04-07 Thread Richard Shockey
Exactly .. I don't see the problem. I've not seen any evidence of abuse. IMHO if the procedure is not broken why are we trying to fix it? Why is the IETF so continuingly dragged about in these, frankly trivial, process issues? I won't repeat what others have said about the presence or

Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard

2008-04-07 Thread Pete Resnick
Coming to consensus on this is going to be messy, as it was in DRUMS, which is what landed us with no comment in the document. To wit: On 4/4/08 at 5:47 PM -0400, John C Klensin wrote: There are two ways to interpret the X- and I think they yield different answers about what should be done.

Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard

2008-04-07 Thread Dave Crocker
Pete Resnick wrote: (1) Partially restore the 822 text, stressing private use, rather than experiental. I don't think we'll be able to do this; see (3) below. ... (3) Encourage X-headers for strictly private use, i.e., they SHOULD NOT be used in any context in which interchange or

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread Leslie Daigle
+1 from me. The role of the Trust Chair used to be pretty lightweight: either it still is, and Harald's advice is sound (get clerical help), or it no longer is, and a more detailed explanation of the experienced change would be helpful to the community being asked for comment. Leslie. --On

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread Russ Housley
The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread Fred Baker
On Apr 3, 2008, at 1:54 PM, John C Klensin wrote: Probably the Trust and/or IAOC procedures or charter should be modified so that, in the event of the demise of the IAOC, the Trust falls firmly under direct IETF control (unless the IETF itself ceases to exist). The concept makes sense

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread Ray Pelletier
Fred Baker wrote: On Apr 3, 2008, at 1:54 PM, John C Klensin wrote: Probably the Trust and/or IAOC procedures or charter should be modified so that, in the event of the demise of the IAOC, the Trust falls firmly under direct IETF control (unless the IETF itself ceases to exist).

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread John C Klensin
--On Monday, 07 April, 2008 16:55 -0400 Ray Pelletier [EMAIL PROTECTED] wrote: Fred Baker wrote: On Apr 3, 2008, at 1:54 PM, John C Klensin wrote: Probably the Trust and/or IAOC procedures or charter should be modified so that, in the event of the demise of the IAOC, the Trust

Re: Proposed Revisions to IETF Trust Administrative Procedures

2008-04-07 Thread Ray Pelletier
John C Klensin wrote: --On Monday, 07 April, 2008 16:55 -0400 Ray Pelletier [EMAIL PROTECTED] wrote: Fred Baker wrote: On Apr 3, 2008, at 1:54 PM, John C Klensin wrote: Probably the Trust and/or IAOC procedures or charter should be modified so that, in the event of the

Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard

2008-04-07 Thread The IESG
The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'User-Defined Errors for RSVP ' draft-ietf-tsvwg-rsvp-user-error-spec-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits

Document Action: 'IPv6 Benchmarking Methodology for Network Interconnect Devices' to Informational RFC

2008-04-07 Thread The IESG
The IESG has approved the following document: - 'IPv6 Benchmarking Methodology for Network Interconnect Devices ' draft-ietf-bmwg-ipv6-meth-05.txt as an Informational RFC This document is the product of the Benchmarking Methodology Working Group. The IESG contact persons are Ron Bonica and

AMS Signs Secretariat Services Agreement

2008-04-07 Thread IETF Administrative Director
The IAOC is pleased to announce that the Internet Society has executed a Secretariat Services Agreement with Association Management Solutions LLC. AMS will provide meetings, clerical and IT services for the IETF. The two year contract began on 1 February 2008 and provides for two one-year