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

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 >>> IA

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 ex

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 sen

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 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 Apr

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 interc

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: 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 > abs

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 ' >as a Proposed Standard > > The IESG plans to make a decision in the next