Re: [spfbis] SPF TYPE support
Hector Santos <hsantos@isdg.net> Tue, 20 August 2013 13:34 UTC
Return-Path: <hsantos@isdg.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 B6BD511E821F for <ietf@ietfa.amsl.com>; Tue, 20 Aug 2013 06:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.181
X-Spam-Level:
X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 FxWELN8R5Hn9 for <ietf@ietfa.amsl.com>; Tue, 20 Aug 2013 06:34:11 -0700 (PDT)
Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B138411E81C9 for <ietf@ietf.org>; Tue, 20 Aug 2013 06:34:07 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6693; t=1377005645; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=WiPx4sB 0K5X2MSqtCoMDjVj5Pew=; b=aCcjSt1uf3UrWB0tYm+v6ZiaR+1tHOtC4D3rPXt PHuYSXpAyxVd2MtcQX4yqI/5ppuKIZZISJcuTWKyGNjOEwHlpxClOU/zimrsYMEO LM9cgzZxm/5+gtR3Y2igFeUU/vEIMIa5vzJbGAxkc0aksEPCj+yoep2lQ+rJrsWJ AwwY=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 20 Aug 2013 09:34:05 -0400
Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3468161282.3.2612; Tue, 20 Aug 2013 09:34:03 -0400
Message-ID: <52136F65.6020703@isdg.net>
Date: Tue, 20 Aug 2013 09:30:13 -0400
From: Hector Santos <hsantos@isdg.net>
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: [spfbis] SPF TYPE support
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net>
In-Reply-To: <6.2.5.6.2.20130819151912.0b861e98@resistor.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: spfbis@ietf.org, Pete Resnick <presnick@qti.qualcomm.com>, Måns Nilsson <mansaxel@besserwisser.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Tue, 20 Aug 2013 13:34:15 -0000
On 8/19/2013 7:42 PM, S Moonesamy wrote:> > At 14:10 19-08-2013, Hector Santos wrote: >> I'm having a hard time with both sides of the argument, especially >> the supposed existence of an "interop problem" which seems to only >> highlight how to "procedurally" stump the SPF type advocates with a >> "error correction" standpoint. What is that error by the way? > > In a message dated February 27, 2012, the SPFBIS Chairs commented > that the discussion about Issue #9 (SPF RRTYPE) has revealed an > interoperability concern in the existing RFC (4408). > > From RFC 6686: > > "RFC 4408 itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one -- it said: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least > one type. > > which means both can claim to be fully compliant while failing > utterly to interoperate." > > The consensus of the SPFBIS WG was that this is an interoperability > issue and it would have to be corrected. That is what was considered as > an error correction. I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious "error" in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. If this is no longer the expectation, then it would make sense to remove the SPF type but also be aware that in general, this will also nix (not help) any future idea for successfully adopting new RR types. It would be added statement that TXT based applications are acceptable. I think the DNS community continues to have a problem with this. >> I don't believe there was an adequate answer from the advocates of >> removing the SPF RR type and the repeated assertion that its been >> discussed at length has not been convincing it was appropriately >> addressed. It all seem to be a "Shut up" approach to the problem >> (always suggest that its been discussed already). This seems to be one >> of the reasons why the issue will not go away. > > I personally do not think that it is appropriate to ask any working > group participant to "shut up". I welcome hearing arguments and I > expect a working group to carefully consider them. > > Regards, > S. Moonesamy (as document shepherd) SM, Pete, thank you for the opportunity to clarify my point. For the record, there was no intent to imply it occurred but quite frankly when it is repeatedly stated, this deeply divided issue has not be resolved at any point, it does have an intimidation factor. As Mr. Crocker stated, the burden is on the those who oppose the removal. But my question was always why was the decision made to remove in the first place done when in fact it was quite obvious it would not have industry wide endorsement. The burden should of been to justify removal. Now it has become difficult to effectively add it back. This is why I posed the question in two forums to get community input over the last few years. It was quite obvious to me that the DNS community would be against this removal. So in this vain, it was prematurely removed in the WG without early IETF/IESG/DNS concerns adequately dealt with. Unfortunately, we were advise to raise the issue again in LC, but by that point, all the IETF procedural moves were made making it it a very high burden to add something that should not been removed in the first place. The only reason our own early adoption package did not support the SPF type was because we could not; the Microsoft DNS server (NT 4.0 at the time) had not directly support the SPF type but more importantly it did not support RFC 3597. Unfortunately, not even MS DNS 5.0 which did add direct support for other new RR types (SRV, DNSSEC, AAAA, etc). In my engineering opinion, the implications of the SPF type removal are wide spread as it implies a no confidence in the future of DNS servers to support safe, transparent passthru, recursive queries of unnamed types. If such is the case with the IETF DNS community, then it makes engineering sense to remove the SPF type but also keep in mind new RR types are also unrealistic as well. All future DNS DOMAIN policy based applications will be TXT only based which may be the acceptable reality today. It wasn't yester-years (during MARID). The endorsement of DKIM as an IS specification is testament of this TXT based solution acceptability in the market place. To me, that would be the reason for removal. Otherwise, if we still have confidence in the future of RFC 3597 support in DNS servers across the board out of the box, then we should correct and clarify the SPF/TXT query method migration path in RFC 4408-bis. As stated a number of times in the SPF WG, I would support SPF type in our implementation once Microsoft DNS server supported at the very least unnamed RR type processing. It can't be provisional software, i.e. custom, that would not cut it. It needs to be out of the box for wide network query support. Thanks -- HLS [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00586.html [2] http://tools.ietf.org/html/rfc3597
- 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