The Last Call social contract (was - Re: Rude responses)
Dave Crocker <dhc@dcrocker.net> Fri, 23 August 2013 03:13 UTC
Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE9411E8196 for <ietf@ietfa.amsl.com>; Thu, 22 Aug 2013 20:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.542
X-Spam-Level:
X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbidmlSXvqxo for <ietf@ietfa.amsl.com>; Thu, 22 Aug 2013 20:13:22 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C111E8193 for <ietf@ietf.org>; Thu, 22 Aug 2013 20:13:22 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7N3DGlr027418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 20:13:19 -0700
Message-ID: <5216D331.8070502@dcrocker.net>
Date: Thu, 22 Aug 2013 20:12:49 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>
Subject: The Last Call social contract (was - Re: Rude responses)
References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <B443E973-858A-4958-964B-B0F0FBDF5A7A@virtualized.org> <CAMm+LwhcHOeUv0iqZmZ6wX-jOD1r-mRR0x8sbxaKrsU3k4CNBQ@mail.gmail.com> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <E3B3B6B0-F17F-44D0-ACD1-53BDBAC6F2CB@frobbit.se> <5214F97B.2080400@dcrocker.net> <6D6829DE-1242-4877-BB5E-8ECD08D88CB2@frobbit.se> <52150722.1070307@dcrocker.net> <52150DF0.6070800@qti.qualcomm.com> <5215123E.5080203@dcrocker.net> <52151903.4030402@qti.qualcomm.com> <521533DB.4040001@dcrocker.net> <52161EB1.6010506@qti.qualcomm.com>
In-Reply-To: <52161EB1.6010506@qti.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Aug 2013 20:13:22 -0700 (PDT)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2013 03:13:28 -0000
Pete, et al, On 8/22/2013 7:22 AM, Pete Resnick wrote: > So, now at the point of IETF LC, the correct thing to happen is to > let folks make their objections, point them to places in the prior > conversation where the WG, the chairs, the ADs, and assorted other > folks became convinced, and see if their arguments have some new > subtlety that was missed earlier. And try to explain. Remember, > these folks are already at a disadvantage; they've got an uphill > climb to convince anyone else (especially, me and the rest of the > IESG) that this long-considered conclusion is incorrect. IMO, that's > the time to cut them as much slack as possible, because if they do > have a serious objection hidden in among things that we've seen > before, we *all* should want to hear it. ... > So, now at the point of IETF LC, the correct thing to happen is to > let folks make their objections, point them to places in the prior > conversation where the WG, the chairs, the ADs, and assorted other > folks became convinced, and see if their arguments have some new > subtlety that was missed earlier. And try to explain. That's certainly a kind and gentle view of the obligations for handling LC comments. Kind and gentle on the folks making the comments. Not so kind or gentle or useful on the folks who have been spending months (or years) doing the work of developing the document. Therefore, I'm going to posit that your model is, in fact, critically flawed. (And on review I see there's an apt pun in that wording...) In pragmatic terms, the current operational model for a LC (and IESG) review tends to enforce no rules or limits to what can be challenged or suggested, while simultaneously expecting those who have been doing the work to then be responsible for educating the commenter and defending decisions in the document, at the level of re-arguing resolved issues. Your admonition that "these folks are already at a disadvantage" encourages this sense of obligation. However this is direct contradiction to our published rules for Last Call: RFC 2418, Working Group Guidelines and Procedures Section 8, Review of documents "It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review." Note that last sentence. It's the essential point, if we are to have any real /respect/ for the extended effort already put into developing the document. It contrasts completely from the burden that is regularly placed on such folk these days. In other words, those making comments have obligations too, but that is not being discussed here, except to make excuses for them. And it is the fundamental flaw with your line of thinking. In practical terms, that thinking suggests that rather than treat it as a joke, we take seriously and tolerate behavior matching the cliche "I haven't read the spec, but I have some criticisms of your work." Besides mostly being incredibly wasteful, to the point of abuse, your model serves as its own disincentive for bringing work to the IETF; the hassle factor is just too damn high and, worse, the outcome too damn unpredictable. For all that we tout the occasional bit of added insight -- and I'm entirely in favor of those rare moments -- they are drowned out by the more predictable and dominant demands to re-explore old topics or new silly ones or to argue religious technical preferences. > But that's not what's gone on. Some folks have simply dismissively > said, "Go read the archive", without pointers. Last Call is for catching oversights and errors. It is not for educating folk who chose not to track the working group. If someone cares enough to press for specific choices, they need to show up when the work is being done. If they don't care that much, then I'm sorry but "we discussed that" or "go read the archives" is in fact an entirely sufficient and complete response. That is, if the IETF has any real respect for the work that was done developing the document. [For completeness, I'll note that this is an issue where it makes sense to handle Individual Submissions quite differently. Here there is no archive of IETF group work, and so it is reasonable to demand of the authors a handling of Last Call comments that really does look more like education and marketing. But not for working group documents.] > The dismissiveness AFAICT simply encourages people to post more > comments without looking at the previous conversation. But your note > went above and beyond. The sarcasm was sharp and directed. It seemed > intent on ridiculing. That's quite a lot to lay onto my brief "very constructive" statement. Which isn't to say you are wrong; although the intensity of your reaction really goes considerably beyond the worth of such a single, brief comment, particularly one lacking an explicitly ad hominem component and especially given that it really was in response to a strikingly inappropriate and unconstructive demand. But let's look at the specifics of the current situation. Comments during last call can come from folk who either have or lack knowledge about the IETF and/or the document's topic. The comments can be exploratory, in the sense of seriously seeking improvement, or they can be pushing the speaker's agenda, with no concern other than for winning their point. That last is typically marked by a lack of responsiveness to points of substance, along with an effort to look for any line of attack that might win. In all cases, of course, starting with moderated and serious responses is appropriate. And, of course, one would always wish that that continues. However, by and large, all of the comments to the SPFbis effort have been either naive, or represented an agenda, or both. And in this case that prompted my sarcasm, we had a highly knowledgeable critic refraining from serious discussion and, instead, pressing a very old and sustained and counter-productive agenda about DNS RRs. And he did it through several iterations. In other words, it was a religious effort, not a technical exploration, jumping around to find any line of attack that would prevent deprecating a patently useless RR (and one, in fact, that has been deemed to create an interoperability problem.) My sarcasm was prompted by the degree of disrespect and silliness in that final suggestion. From a highly experienced IETF participant. > And coming from someone who is already on the side of the called > consensus (the side that "has already won", though I dislike that > formulation) You /should/ dislike it, because it entirely misses the style of attack against the work that is quite common during LC. And since it is by now easy to forget my earlier statement, I'll repeat that I am entirely in favor of LC and the constructive comments that do get made there. I am not criticizing the construct of LC but rather the unreasonable demands on document creators that result from LCs' current lack of limits on critics. LC should not be treated as a right of passage, to test the patience of folks who have developed a document. It should be exactly what RFC 2418 says it should be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- SPF TYPE support Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… HLS
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Murray S. Kucherawy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: SPF TYPE support Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: SPF TYPE support S Moonesamy
- Re: [spfbis] SPF TYPE support Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: SPF TYPE support Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Randy Bush
- Re: SPF TYPE support Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] SPF TYPE support Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] prefixed names, was Last Call: <draf… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dotzero
- Re: [spfbis] prefixed names, was Last Call: <draf… Mark Andrews
- Re: [spfbis] prefixed names, was Last Call: <draf… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] SPF TYPE support S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Phillip Hallam-Baker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Eliot Lear
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Eliot Lear
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… manning bill
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Alessandro Vesely
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] there is no transitiion, was Last Ca… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] there is no transitiion, was Last Ca… Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Olafur Gudmundsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Leslie
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Barry Leiba
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Stephen Farrell
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: Rude responses (Was: Last Call: <draft-ietf-s… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Olafur Gudmundsson
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Scott Brim
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Thomas Narten
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Murray S. Kucherawy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Barry Leiba
- RE: Rude responses (Was: Last Call: <draft-ietf-s… l.wood
- The Last Call social contract (was - Re: Rude res… Dave Crocker
- RE: The Last Call social contract (was - Re: Rude… l.wood
- RE: The Last Call social contract (was - Re: Rude… Dave Cridland
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Visibility of shepherd writeup Carsten Bormann
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: The Last Call social contract (was - Re: Rude… Scott Brim
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: The Last Call social contract (was - Re: Rude… Dave Crocker
- Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Se… Douglas Otis
- Re: The Last Call social contract (was - Re: Rude… Hector Santos
- Re: The Last Call social contract (was - Re: Rude… S Moonesamy
- Re: The Last Call social contract (was - Re: Rude… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Abdussalam Baryun
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Overloaded TXT harmful (was" Re: [spfbis] Last Ca… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Joe Abley
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Patrik Fältström
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Mark Andrews
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dan Schlitt
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John Levine
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… David Conrad
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Macro Expansion (was: Last Call: <draft-ietf-spfb… S Moonesamy
- Re: Macro Expansion (was: Last Call: <draft-ietf-… Douglas Otis
- Re: Macro Expansion Pete Resnick