RE: IESG voting procedures

Hi Keith, Ø The only other formal level of review we have are the Last Call comments which, given the volume of documents that get Last Called, amounts to a fairly small and random chance that somebody outside the WG will happen to notice the proposed document action and give the document a

Re: IESG voting procedures

Thanks for that info. That does make me feel a bit better. Keith On Aug 15, 2011, at 5:50 AM, Romascanu, Dan (Dan) wrote: > Hi Keith, > > Ø The only other formal level of review we have are the Last Call comments > which, given the volume of documents that get Last Called, amounts to a > f

Re: IESG voting procedures

+1. One single AD should never be allowed to block a document for which there appears to be community support. If a document really has serious problems, it is the job of the AD to rally other ADs or other impacted community members to oppose the document. Yes, this can be more work for an AD, but

Re: IESG voting procedures

"Romascanu, Dan (Dan)" writes: > The only other formal level of review we have are the Last Call > comments which, given the volume of documents that get Last Called, > amounts to a fairly small and random chance that somebody outside > the WG will happen to notice the proposed document action an

RE: IESG voting procedures

Hi Thomas, The paragraph below does not belong to me. In my message I was actually answering it. Regards, Dan > -Original Message- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Monday, August 15, 2011 3:51 PM > To: Romascanu, Dan (Dan) > Cc: Keith Moore; Barry Leiba; adr..

Re: IESG voting procedures

> The paragraph below does not belong to me. In my message I was actually > answering it. Right. My mistake. It was Keith's comments I quoted. Sorry 'bout that. Thomas "Romascanu, Dan (Dan)" writes: > Hi Thomas, > The paragraph below does not belong to me. In my message I was actually > answ

Re: Last Call: (Message Submission

Hi Martin, At 12:02 12-08-2011, Martin Rex wrote: I'm wondering wheter there should be an informative reference to rfc6186. That suggestion came up during the working group discussion but it was not retained as there wasn't any implementation report for RFC 6186. The editors of draft-ietf-ya

Gen-ART LC Review of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-rsvp-te-no-php-oob-mapp

Re: Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard

Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for consistency with draft-ietf-karp-ospf-analysis. KARP is chartered to figure out what improvements we need in routing protocol authenticationq. While draft-ietf-karp-ospf-analysis has not been approved by the WG, I think it's fairly

Re: IESG voting procedures

>> And I think in that case, there is >> no way that one or two ADs should be able to block something >> because they don't like it, *unless* they can convince the rest >> of the IESG that the document is harmful. > > Convincing the entire IESG is a very high barrier, especially when typically,

Re: IESG voting procedures

Keith: >>> Convincing the entire IESG is a very high barrier, especially when >>> typically, most of the IESG just wants the issue to go away.It might >>> happen for a significant architectural issue, perhaps, but not for an >>> area-specific technical flaw. >> >> Here's the point: if an AD c

Re: IESG voting procedures

On Aug 15, 2011, at 2:28 PM, Russ Housley wrote: > My experience is that a technical flaw, even if it is a corner case, is acted > upon by the WG. There are rare cases where the WG has lost energy, but in > general the WG wants to produce a quality output. As a result, technical > flaws are n

Re: Last Call: (Considerationsfor Having a Successful "Bar BOF" Side Meeting) to Informational RFC

I have been looking at various revisions of this draft since -00. I'm glad Lars did the first version during IETF 77, and I'm glad that Lars and Gonzalo kept working on it. I think it's important guidance for the community. I think it's on the right track. I think it could reasonably be publis

Re: [Ietf-krb-wg] Last Call: (OTP Pre-authentication) to Proposed Standard

Hi. Just around the time that this document was sent to the IESG, a discussion started surrounding the nonce text in this draft in the Kerberos working group. All the participants seemed to agree that the discussion was non-blocking: if consensus on a change was not found before ietf last call en

Re: [Ietf-krb-wg] Last Call: (OTP Pre-authentication) to Proposed Standard

Hi Sam, No problem here. Seems sensible either way to me and a little better with the new text if that's what the WG prefer. I'd say make the change when processing any other IETF LC comments. S. On 16/08/11 00:46, Sam Hartman wrote: > Hi. > Just around the time that this document was sent to

Re: Gen-ART Review: Last Call

Someone might want to point this out to the IESG then, as that has not been my recent experience. Not even for structures or definition of elements - it was suggested that the use of the terms mandatory and optional (which I thought was quite precise when defining data elements) needed to be rewor