From dns-dir-bounces@ietf.org Mon Feb 2 09:55:35 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF343A6A4B; Mon, 2 Feb 2009 09:55:35 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3E53A6929 for ; Mon, 2 Feb 2009 09:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5W-U+yI6ssp for ; Mon, 2 Feb 2009 09:55:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E744B28C22F for ; Mon, 2 Feb 2009 09:55:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231131600"; d="scan'208";a="136091695" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Feb 2009 12:55:06 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Feb 2009 12:55:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 18:54:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-hoffman-dac-vbr thread-index: AcmCRI8HzaQ0h6joQbiSq4uF1fnLMADGqxoQ From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: DISCUSS: draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org DNS-DIR folks, This is the answer from Paul on draft-hoffman-dac-vbr in case you did not see it. Dan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org] Sent: Thursday, January 29, 2009 9:05 PM To: Romascanu, Dan (Dan); iesg@ietf.org Cc: arvel.hathcock@altn.com; john.levine@domain-assurance.org Subject: RE: DISCUSS: draft-hoffman-dac-vbr At 7:50 PM +0100 1/29/09, Romascanu, Dan (Dan) wrote: >There has been quite a lot of traffic on this. Can you send again the >response that you consider being the 'official' answer (may be more >than >one) so that we make sure the DNS-DIR has seen it? > To: Russ Housley From: Paul Hoffman Subject: Re: FW: [dns-dir] Question about draft-hoffman-dac-vbr Cc: John Levine , Arvel Hathcock Bcc: X-Attachments: >Please generate a response to this review. Done. This is approved by both my co-authors as well. You may pass it to the IESG. I also spoke with Liman and we have agreed to disagree on the TXT record issue. He did not know why the DNS-DIR review was not requested earlier, nor why Peter Koch did not bring it to the DNS-DIR when we spoke with him probably a year ago about the document. ===================================================================== >I took myself through this document, and I must say that without fundamental knowledge in modern mailology, more specifically sender authentication, it seems like "dancing around the issue but never getting there". There is lots of talk of "certify the owner" and "valitdation of the identity" and stuff, but little explanation of the overall process going from A to B. I would like to see something that starts with "mail going out here" and ends with "and by validating that signature, the authenticity can be established. QED.". The document purposely doesn't do that because different mail systems will do the certification at different times. For example, some mail systems would do this between the time a message is received and when it is put in the user's mail store; others would do it when reading the file from the mail store but before displaying it to the user. The timing truly doesn't matter to the protocol: what matters is that it is done using the steps given in the document. We carefully designed VBR so it can be used in conjunction with any of the widely used domain authentication schemes, so it can be applied at or after the time the authentication scheme is evaluated. Note that VBR does not provide authentication; that is the job of the underlying authentication scheme. It provides certification, which is a different thing. >I saw two cases of "X MUST/SHOULD be Y; and if X _isn't_ Y, the result is undefined.". To me, that is a recipe for misunderstanding, incompatible implementations, and quarrel about interpretation of the spec. These are both good catches. The first says this: All of the VBR-Info header fields in a single message MUST have identical mc= values. The semantics of a message with non-identical mc= categories are undefined. We agree that this could lead to incompatible implementations. The last sentence can be dropped. The second says this: If more than one TXT record exists at a name from a VBR record, the results are unspecified. We agree that this could lead to incompatible implementations. The sentence can be changed to: The VBR record MUST have only one TXT record. >I also cannot wrap my brain around the concept that some third party >could "vouch" for e-mail coming out of someones laptop - if it's of a >certain type - and what if it isn't? It me took all through to the >"Changes" section before I fully realized that sender domain >authentication is a strict prerequisite for this, and I still don't >fully comprehend the value it would add (although I saw in the IETF >tools document tracker that Chris Newman really likes it, so it can't >be all bad ... ;-), but never mind, that's not the task at hand. ;-) Vouching services will have different business models for how they assure people that their vouching is worthwhile. That is definitely out of scope for this document. Some models are like the ones we see today with Return Path and Constant Contact; others will spring up, such as trade groups vouching for their members. Another example might be that the bank regulator in a country (such as the FDIC in the US) might choose to vouch for the banks that it oversees. We do not expect that every email user will want to use one or more vouching services, just that, if they do, there should be a single interoperable protocol. >Looking at the DNS parts of this, a few things caught my eye, and I would at least like to make sure they are lifted up for closer inspection. > >1) TXT record. Again! Needs to be fixed, unless they can provide a > _REALLY_ good explanation why TXT creates a better overall > architecture compared to defining a new record type. (Speed of > deployment has very little to do with good architecture in my > world, and usually means the opposite.) We have been through this many times. The use case here is exactly the same as for DKIM. The underscore used on the _vouch label prevents there from being any possibility of collision with TXT records for actual domain names. The paragraph near the end of section 5 ("Verifiers MUST then check...") deals with the issue of wildcards and TXT records. >2) It seems to make use of DNS "because it's there", rather than > because it's the optimal database mechanism for this, but that > said, it does fit ... for some not too negative value of "fit". We don't understand this objection at all. As stated throughout the document, VBR is for vouching for mail from a *domain name*. The lookups are based on a domain name, and the responses are small single replies. DNS seems like a perfect fit for that. >3) It combines 3 semantically different entities in the lookup domain > name. You seem to have > > a) The sender domain, > b) The separator "_vouch", and > c) The service locator. > > While that strikes me as kind of "not how DNS was originally > intended to be used", at least the service locator is "to the > right" (closer to the root), which means that the client can > actually make good use of DNS caching, and they avoid hitting the > higher DNS echelons (root, TLD, ...) with subsequent queries. The > servers that will be hammered, will be the servers of the "vouching > service", which is as it should be. Basically, it's not worse than > any DNS based RBL list alreay in use. We designed VBR the way we did because we knew that similar designs had acceptable DNS characteristics. There is no "service locator": there's just the domain name of the vouching service. >4) The DNS language is pretty sloppy, and needs to go through "boot > camp with a DNS sergeant". ;-) We asked for such input during the development of the document, and we heard no comments from the sergeants who said they would review it other than a disagreement about TXT records. >I note that there is no information > about how one goes from "the service locator" to the actual IP > address of the vouching service DNS server. It's "a list of domain > names of certification providers that the sender asserts will vouch > for this particular message." (sect 4.) Aha? And how do I use these > "domain names"? Is the service locator to be interpreted as a > lookup key for an A record? An AAAA record? An SRV record? (If the > latter, what are the other parameters?) Or, do I pass it through a > NAPTR to obtain ... what? I would like to see that process > described in a more formal way. The document says that the string queried is a domain name, and that the domain name is queried for a TXT record. If it would help, we can add "The recipient looks up the domain name in the DNS in the exact same manner it looks up all other domain names." The protocol is agnostic to whether A or AAAA records are returned. >From his comment, we think that Liman maybe supposed that there had to be some way to auto-discover vouching services. There is deliberately no intention that vouching services can be found automatically. VBR is about reputation, and the mail system's management has to decide for itself what vouching service(s) it wants to use. One uses a vouching service that one trusts, not just "one that is there". >5) I notice that the document doesn't mention DNSSEC at all, which may > be intentional. It could be that they don't want to force people > into using DNSSEC (I can fully respect that), of that this is > intended to be an alternative to using DNSSEC, but this really > seems like an application where DNSSEC could actually be of some > use, and I would at least like to see a discussion section on that. The protocol is agnostic to DNSSEC. There is no more reason to force a user to use DNSSEC for this protocol than for any other protocol. DNSSEC would indeed be of some use, just as it would be for any other protocol. >6) In sec 5, par 9, the authors assert that the choice of the > separator label "_vouch" leads to "There will never be any > accidental overlap with a valid domain name." That is not only > incorrect from a DNS perspective, it is bad terminology, and also a > questionable statement, even if you take the language aside. "will > never" are strong words, and however unlikely, it is _possible_ > that the underscore will be made koscher in host names (which is > what they mean) in a distant future. We can change "valid domain name" to "currently-valid domain name" or "host names". _vouch is indeed a valid domain name, which is why we use it in the DNS. >7) At the end of section 5. we have one of the two "unspeifieds" > mentioned above: "If more than one TXT record exists at a name from > a VBR record, the reults are unspecified." Why is that? Why not > specify "considered it to be an error - ignore it!" or "concatenate > them and treat them as one record", or at least something well > defined? Agree; see above. >On the non-DNS side, there are also questions in section 7: "Senders >SHOULD use DKIM (and MAY use DomainKeys, SPF, or SenderID)...". That >little "and" in the parenthesis - is that "DKIM _and_ any of the >following" or is it really "DKIM _or_ any of the following"? (It may be >obvious to a native English speaker, but it's not to me. ;-) We truly meant "and". >... and in 7.1, where it's required that the VBR header lines be put "immediately below the corresponding DKIM-Signature header field". What if you have competing such requirements from other mail sub-protocols? It is not required, it is recommended. The exact words are: o The VBR-Info header field SHOULD be added in the header immediately below the corresponding DKIM-Signature header field. >To be frank, since this is a Standards Track document, my view is that it needs some "shaping up". I don't necessarily disapprove of the basic idea, but I want more information to be able to judge better, and I want better DNS language. We hope the changes and explanations above cover all the issues. >... and a different record type than TXT. :-) We see no difference between the use in VBR and other standards-track documents. We looked at the objections to re-use of TXT carefully and found that none of them apply to VBR, given the way we purposely designed the protocol. >My assessment is that this exact document isn't ready for publication, but may become so in a future revision, given more and wider review. This document was informally reviewed by a WG (DKIM), by a group of vendors with a great deal of technical knowledge (the Domain Assurance Council), and went through a four-week IETF Last Call that generated review. We are not sure what more we could have asked. --Paul Hoffman, Director --Domain Assurance Council _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B65F3A6C71 for ; Wed, 4 Feb 2009 09:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4MWliqJnTlE for ; Wed, 4 Feb 2009 09:26:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 05C083A6B42 for ; Wed, 4 Feb 2009 09:26:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="32859531" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2009 17:24:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14HOAOw032635 for ; Wed, 4 Feb 2009 18:24:10 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14HOAE9028912 for ; Wed, 4 Feb 2009 17:24:10 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 18:24:10 +0100 Received: from ams-townsley-8711.cisco.com ([10.55.233.226]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 18:24:09 +0100 Message-ID: <4989CF39.6030301@cisco.com> Date: Wed, 04 Feb 2009 18:24:09 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: IETF DNS Directorate Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2009 17:24:09.0996 (UTC) FILETIME=[64017CC0:01C986ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=188; t=1233768250; x=1234632250; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20BIND=20config=20in=20an=20RFC |Sender:=20; bh=apiEBjZwCo2y6o3+ngLjDtDXOqpUsslpfQRIotvSAgY=; b=jQG76Zsk3E2yep0Uu0u37fRwXw8bswi/zMpDPM31ww2BqoH5MsRHONdZe1 0S3R5P9F/0/hsZOwX/LCOA2SMqps1NYQJ578WosdUaEmtg3ovtKGh50b1Fis 0n8KfO7MSv; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:26:02 -0000 Do we have any RFCs with example config, say, from BIND? Would it be kosher to include that or not, just as a non-normative illustrative example for something. Thanks, - Mark Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283173A6954 for ; Wed, 4 Feb 2009 10:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKE0XA+RY21a for ; Wed, 4 Feb 2009 10:26:13 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 156363A69E9 for ; Wed, 4 Feb 2009 10:26:12 -0800 (PST) Received: from 69-94-197-1.biltmorecomm.com (69-94-197-1.biltmorecomm.com [69.94.197.1] (may be forged)) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n14IPWZQ079469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2009 19:25:33 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Message-Id: <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> From: Olaf Kolkman To: Mark Townsley In-Reply-To: <4989CF39.6030301@cisco.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-33--85823330" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 13:25:30 -0500 References: <4989CF39.6030301@cisco.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 04 Feb 2009 19:25:33 +0100 (CET) Cc: IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:26:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-33--85823330 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 4, 2009, at 12:24 PM, Mark Townsley wrote: > Do we have any RFCs with example config, say, from BIND? Would it be > kosher to include that or not, just as a non-normative illustrative > example for something. I do not think that would be kosher. Speaking as an implementer it would almost feel like IETF endorsement of a product. A 'pseudo-config' would be different. --Olaf --Apple-Mail-33--85823330 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkmJ3ZoACgkQtN/ca3YJIoc35wCePJGFOoe1Rat60BcKwp2xAkss vzQAnAyZ1GiJxSWTsE5ftMiki1aGn01P =vX/M -----END PGP SIGNATURE----- --Apple-Mail-33--85823330-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571B43A69E2 for ; Wed, 4 Feb 2009 10:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdmDNkMGiC4j for ; Wed, 4 Feb 2009 10:40:17 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 718ED3A6954 for ; Wed, 4 Feb 2009 10:40:17 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LUmf7-0007D4-V5; Wed, 04 Feb 2009 19:39:49 +0100 Received: from localhost by x27.adm.denic.de with local id 1LUmcT-0007Of-69; Wed, 04 Feb 2009 19:37:05 +0100 Date: Wed, 4 Feb 2009 19:37:05 +0100 From: Peter Koch To: Mark Townsley Message-ID: <20090204183705.GA16834@x27.adm.denic.de> References: <4989CF39.6030301@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4989CF39.6030301@cisco.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:40:18 -0000 On Wed, Feb 04, 2009 at 06:24:09PM +0100, Mark Townsley wrote: > > Do we have any RFCs with example config, say, from BIND? Would it be > kosher to include that or not, just as a non-normative illustrative > example for something. not sure what you're after here. More often than not, people confuse snippets of a standard DNS zone file with "BINBD config". Zone file is perfectly OK -- BIND config was maybe years ago, but there's enough diversity today and not only, as Olaf said, should the IETF avoid the perception of andorsing a specific product, nor should it support the misconception that "DNS == BIND". Any more conrete pointers? -Peter Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06E63A67E4 for ; Wed, 4 Feb 2009 14:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=2.098, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OpgmAfxZlyW for ; Wed, 4 Feb 2009 14:39:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8A5673A687B for ; Wed, 4 Feb 2009 14:39:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="sig'?scan'208";a="32877256" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2009 22:38:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14MckL2025708; Wed, 4 Feb 2009 23:38:46 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14Mckuq024023; Wed, 4 Feb 2009 22:38:46 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 23:38:46 +0100 Received: from 94.191.157.171.bredband.tre.se ([10.61.94.63]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 23:38:42 +0100 Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Olaf Kolkman In-Reply-To: <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-190--70631596" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 23:38:42 +0100 References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 04 Feb 2009 22:38:43.0560 (UTC) FILETIME=[5586CE80:01C98719] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1229; t=1233787126; x=1234651126; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dns-dir]=20BIND=20config=20in=20an=20R FC |Sender:=20; bh=p8FLC5LnCL7BN5Us5dUuMhCbJaVC0bHbH1vQ+qe9PDE=; b=miulzSioqIUnSyxSwGfvtpxPJn0wI7vkOrFv0r74CvRyBdSgPI/htW/e6e xS6mZaA39XAfI9DbM3QrJgbRtrwdD0O3bBLg8ZtxQFrHYDKkoRMFHSo4lJIN tOT4LqrtvD; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:39:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-190--70631596 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 4 feb 2009, at 19.25, Olaf Kolkman wrote: > On Feb 4, 2009, at 12:24 PM, Mark Townsley wrote: > >> Do we have any RFCs with example config, say, from BIND? Would it >> be kosher to include that or not, just as a non-normative >> illustrative example for something. > > > > I do not think that would be kosher. Speaking as an implementer it > would almost feel like IETF endorsement of a product. > > A 'pseudo-config' would be different. Zone file format is defined (started in 1034, right(?)), but not the configuration of the software itself. Patrik --Apple-Mail-190--70631596 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJihjyvHlR2X0luNwRAlmIAKDdRjms0FY7hppi8M5arDsPIk6KGQCgzZJK eDbiBthSi3QIFDz6OHDuPf8= =Hs4c -----END PGP SIGNATURE----- --Apple-Mail-190--70631596-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4803A6A24; Thu, 5 Feb 2009 04:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYscaIaxE9CV; Thu, 5 Feb 2009 04:33:40 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 60F1D3A6927; Thu, 5 Feb 2009 04:33:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231131600"; d="scan'208";a="151236007" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Feb 2009 07:33:19 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2009 07:33:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Feb 2009 13:33:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BOF proposals for IETF-74 thread-index: AcmHjeLd2xfbkcdgR36IHhQC2eA5tg== From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] BOF proposals for IETF-74 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:33:41 -0000 I apologize for the late warning. The IAB and IESG will be meeting in a few hours to review the BOF requests for IETF-74. The information about the BOFs and links to the relevant documents can be found at http://trac.tools.ietf.org/bof/trac/wiki. If there are any comments or concerns please send them to Ron and me until today 11:30AM ET.=20 Thanks and Regards, Dan Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEF73A6909 for ; Thu, 5 Feb 2009 05:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNEsgKpz7awd for ; Thu, 5 Feb 2009 05:08:33 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id BA4673A681D for ; Thu, 5 Feb 2009 05:08:32 -0800 (PST) Received: from 176.174.125.209.transedge.com (176.174.125.209.transedge.com [209.125.174.176]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n15D71Nr088354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Feb 2009 14:08:02 +0100 (CET) (envelope-from olaf@nlnetlabs.nl) Message-Id: From: Olaf Kolkman To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-49--18473191" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 08:08:00 -0500 References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 05 Feb 2009 14:08:04 +0100 (CET) Cc: IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:08:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-49--18473191 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >> >> >> I do not think that would be kosher. Speaking as an implementer it >> would almost feel like IETF endorsement of a product. >> >> A 'pseudo-config' would be different. > > Zone file format is defined (started in 1034, right(?)), but not the > configuration of the software itself. Correct. Zonefile format is defined. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. --Apple-Mail-49--18473191 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkmK5LAACgkQtN/ca3YJIocNjQCgpIHGWsYApFIuxVnBr4wOmPir rcwAoNB9d+FOc8sCaekQJx2MlmyZVPT7 =5pUI -----END PGP SIGNATURE----- --Apple-Mail-49--18473191-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D6B3A6B97 for ; Thu, 5 Feb 2009 05:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7e1vXBkVK8W for ; Thu, 5 Feb 2009 05:13:52 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D6B6E3A681D for ; Thu, 5 Feb 2009 05:13:52 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 354A62FEA473 for ; Thu, 5 Feb 2009 13:13:32 +0000 (UTC) Date: Thu, 5 Feb 2009 08:13:30 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090205131330.GA61414@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] BOF proposals for IETF-74 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:13:53 -0000 On Thu, Feb 05, 2009 at 01:33:02PM +0100, Romascanu, Dan (Dan) wrote: > I apologize for the late warning. The IAB and IESG will be meeting in a > few hours to review the BOF requests for IETF-74. The information about > the BOFs and links to the relevant documents can be found at > http://trac.tools.ietf.org/bof/trac/wiki. If there are any comments or > concerns please send them to Ron and me until today 11:30AM ET. Note to DNS Mavens: the MIF proposal appears to encompass some tricky split-brain processing. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D44428C1CD for ; Thu, 5 Feb 2009 06:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrtzGzPBNqe4 for ; Thu, 5 Feb 2009 06:04:34 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id A2C0D3A6A93 for ; Thu, 5 Feb 2009 06:04:34 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n15E2isJ006308 for ; Thu, 5 Feb 2009 07:02:44 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n15E409u122946 for ; Thu, 5 Feb 2009 07:04:01 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n15E3xai005133 for ; Thu, 5 Feb 2009 07:03:59 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-154-206.mts.ibm.com [9.49.154.206]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n15E3snu004557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 07:03:56 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n15E3rFd017293; Thu, 5 Feb 2009 09:03:54 -0500 Message-Id: <200902051403.n15E3rFd017293@cichlid.raleigh.ibm.com> To: Andrew Sullivan In-reply-to: <20090205131330.GA61414@shinkuro.com> References: <20090205131330.GA61414@shinkuro.com> Comments: In-reply-to Andrew Sullivan message dated "Thu, 05 Feb 2009 08:13:30 -0500." Date: Thu, 05 Feb 2009 09:03:53 -0500 From: Thomas Narten Cc: dns-dir@ietf.org Subject: Re: [dns-dir] BOF proposals for IETF-74 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:04:35 -0000 > Note to DNS Mavens: the MIF proposal appears to encompass some tricky > split-brain processing. Yes. One of the key "problems" associated with multihoming is how to handle being multihomed into different administrative domains, where you have differing DNS servers and split DNS. I.e., so it matters which DNS server you query for a name (the one behind your VPN may know about private names). And then, if your corporate DNS server returns A records with private addresses, you want to force outgoing connections to use use the interface associated with the VPN. This is stuff that the current internet architecture just doesn't do, and can't easily. I.e., when doing address selection or routing packets, you don't always know about address realms and factor them in to the degree that is needed to solve the "problem". I am sympathetic to there being a real problem here. But I think most people don't fully understand how difficult (impossible? ugly?) a solution would be. Thomas Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAF43A6A93 for ; Thu, 5 Feb 2009 06:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSQL0GvLzomq for ; Thu, 5 Feb 2009 06:07:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 13D7D3A6927 for ; Thu, 5 Feb 2009 06:07:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231113600"; d="scan'208";a="32947875" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2009 14:07:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n15E7Dgx019785; Thu, 5 Feb 2009 15:07:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n15E7DtJ022784; Thu, 5 Feb 2009 14:07:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 15:07:13 +0100 Received: from ams-townsley-8711.cisco.com ([10.55.233.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 15:07:12 +0100 Message-ID: <498AF291.5030308@cisco.com> Date: Thu, 05 Feb 2009 15:07:13 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Olaf Kolkman References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2009 14:07:12.0736 (UTC) FILETIME=[0AC87600:01C9879B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1079; t=1233842833; x=1234706833; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[dns-dir]=20BIND=20config=20in=20an=20R FC |Sender:=20; bh=qNpv/FJOixu2XQBpweaDYlSDBp9/h3ZSsNBzEk03UNE=; b=lvM8lDCP8eWOUYJ/pVTUhdvI+HlcCuMpwXmyQ7whi/C5oMYa4FmpXuvrGX nxor1P/EhCha4xMncd8ovqPaQYawcHuSaGDiEpeDVbDNx5gUhlz4aL6orHAU NOY5k2sSoS; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:07:35 -0000 Thanks guys... On context, this was prompted by an upcoming ID on how Google did its Google over IPv6 stuff (I know some of you are already quite familiar with how that was done). - Mark PS. The -00 *might* indeed have some bind config just for illustrative example, with clear indication that it will be removed in a future rev. Olaf Kolkman wrote: >>> >>> >>> I do not think that would be kosher. Speaking as an implementer it >>> would almost feel like IETF endorsement of a product. >>> >>> A 'pseudo-config' would be different. >> >> Zone file format is defined (started in 1034, right(?)), but not the >> configuration of the software itself. > > > > Correct. Zonefile format is defined. > > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam > > NB: The street at which our offices are located has been > renamed to the above. > > > > Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FF428C1C2 for ; Thu, 5 Feb 2009 06:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF6CV5fhkEa3 for ; Thu, 5 Feb 2009 06:12:26 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id ED47828C1D7 for ; Thu, 5 Feb 2009 06:12:25 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n15E9rpl028829 for ; Thu, 5 Feb 2009 07:09:53 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n15EBvcA041162 for ; Thu, 5 Feb 2009 07:11:59 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n15EBuaL008256 for ; Thu, 5 Feb 2009 07:11:56 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-154-206.mts.ibm.com [9.49.154.206]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n15EBse2008207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 07:11:55 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n15EBrwj017504; Thu, 5 Feb 2009 09:11:53 -0500 Message-Id: <200902051411.n15EBrwj017504@cichlid.raleigh.ibm.com> To: Mark Townsley In-reply-to: <498AF291.5030308@cisco.com> References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> <498AF291.5030308@cisco.com> Comments: In-reply-to Mark Townsley message dated "Thu, 05 Feb 2009 15:07:13 +0100." Date: Thu, 05 Feb 2009 09:11:53 -0500 From: Thomas Narten Cc: Olaf Kolkman , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:12:26 -0000 > Thanks guys... On context, this was prompted by an upcoming ID on how > Google did its Google over IPv6 stuff (I know some of you are already > quite familiar with how that was done). This sounds like a non-IETF individual submission. BIND config would be fine there, IMO. I.e., forcing them to provide a config file in psuedo-code that they didn't use would seem a bit like make-work. Thomas Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E20F28C1C2 for ; Thu, 5 Feb 2009 06:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Ui1858yPQW for ; Thu, 5 Feb 2009 06:20:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 07DC528C17C for ; Thu, 5 Feb 2009 06:20:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231113600"; d="scan'208";a="32949810" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2009 14:19:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n15EJq9q024431; Thu, 5 Feb 2009 15:19:52 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n15EJpCm027814; Thu, 5 Feb 2009 14:19:52 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 15:19:51 +0100 Received: from ams-townsley-8711.cisco.com ([10.55.233.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 15:19:51 +0100 Message-ID: <498AF587.6010801@cisco.com> Date: Thu, 05 Feb 2009 15:19:51 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Thomas Narten References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> <498AF291.5030308@cisco.com> <200902051411.n15EBrwj017504@cichlid.raleigh.ibm.com> In-Reply-To: <200902051411.n15EBrwj017504@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2009 14:19:51.0243 (UTC) FILETIME=[CEE371B0:01C9879C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1105; t=1233843592; x=1234707592; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[dns-dir]=20BIND=20config=20in=20an=20R FC |Sender:=20; bh=vKg/2P34YUHNJhE/fU3HjSVo1XSJOUUPKV/MsU1StEE=; b=cEMZFbyLGd5fgIK4bGR6bNnzBs8+gzMgvFT4NqqQgTEwTqur2q4QsXYAqQ KRohpNMzPKJhLNpHktgtcA8poyxYUk0fslyWiFgjxvfQur+vx3lgLf/gkIoT LKx5EsVFMC; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Olaf Kolkman , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?=, =?ISO-8859-1?Q?m?= , IETF DNS Directorate Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:20:14 -0000 Thomas Narten wrote: >> Thanks guys... On context, this was prompted by an upcoming ID on how >> Google did its Google over IPv6 stuff (I know some of you are already >> quite familiar with how that was done). >> > > This sounds like a non-IETF individual submission. > Absolutely for the -00... who knows what happens to it in the future, but I don't think they have any sort of aspirations in any direction other than to provide the information to the community and get feedback. > BIND config would be fine there, IMO. > > I.e., forcing them to provide a config file in psuedo-code that they > didn't use would seem a bit like make-work. > This is why I told them it would be OK (IMHO) for the -00, so I agree with you here. Anyone object to Thomas' statement - that as long as the document remains within the "this is what Google did" space, then illustrative bind config is fine.... In any case, that question doesn't have to be answered right away, we can see what happens to the course of the document to decide. Thanks, - Mark > Thomas > > Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573E328C1DC for ; Thu, 5 Feb 2009 07:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYD9+HnKQzkv for ; Thu, 5 Feb 2009 07:01:14 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E935928C18F for ; Thu, 5 Feb 2009 07:01:13 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1DF872FEA472 for ; Thu, 5 Feb 2009 15:00:51 +0000 (UTC) Date: Thu, 5 Feb 2009 10:00:49 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090205150049.GJ61414@shinkuro.com> References: <20090205131330.GA61414@shinkuro.com> <200902051403.n15E3rFd017293@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902051403.n15E3rFd017293@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] BOF proposals for IETF-74 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 15:01:15 -0000 On Thu, Feb 05, 2009 at 09:03:53AM -0500, Thomas Narten wrote: > I am sympathetic to there being a real problem here. But I think most > people don't fully understand how difficult (impossible? ugly?) a > solution would be. Well, ugly anyway. Lately I keep running into areas where real problems are being solved by baling wire and spit. I am coming to think that the central problem is that we want to maintain the protocol's view of zones: they are an administrative conveience that are visible in the data-distribution parts of the protocol, but that are mostly invisible to the DNS client and in any case are not signifiers of any real administrative boundary other than, "This group of machines answers for this part of the namespace." The basic problem that I perceive is that people need either to know _that_ there is some important administrative boundary (and what it is); or they need to know that plus the status of certain propositions about things inside those boundaries. So, for instance, the publicsuffix.org people have a genuine problem they're trying to solve (although, IMO, in a completely braindead way), because they're trying to delineate between delegation-centric and non-delegation-centric name spaces. That's not a stupid problem: knowing that different sites inside sun.com (and, heck, mysql.com) are likely related to one another in a way that sun.com and ra.com are not is a useful piece of information. It is a natural extension of what people use names for, and insisting that the name of a location doesn't connote certain other things is probably a mistake. If there were some way to stake the DNS namespace to say, "here's what I'm a part of," I think it would help. I am aware, however, that the publicsuffix.org fanboys aren't that interested in this idea. The IDNAbis work has a different, but related problem. One of the things that seems to come out of the IDNAbis effort is that internationalization isn't enough: one needs _localization_. But to do that, one needs to know the relevant locales. That's all but impossible at the moment. However, if there were some easy way to state one's administrative boundaries and to include in that information a pointer to the policies of the domain, then the policy could include some rules about locale (which, in this case, just means which Unicode code-points are allowed in the zone, and maybe what the mapping rules are from one set of code points to another if such a mapping is needed). Finally, the example that got me started in this thread seems to be a namespace declaration problem: more than one DNS server will answer authoritatively for the namespace, and you want to know which of them you ought to prefer given other preferences you have about that namespace. Again, a policy could help. For instance, a split-brain system may answer queries for privatenames.example.com only to hosts on some RFC 1918 network. That policy information could be included such that a client could look it up, discover that it has an interface with an address in that range, and then send its queries for things in that namespace on the appropriate interface. What I've imagined is an SRV record in the zone for some underscore name, and that points off to the policy service. The policy thing is, I imagine, something like IRIS (maybe it is IRIS). The reason the above (well, something less hand-wavy) isn't in an I-D yet is that every time I float this idea in front of anyone, I hear unenthusiastic responses. Some complain that it'll take a long time to develop and deploy. Others observe that something similar will solve their own problem, so why would they bother with this elaborate framework? Finally, some wince because of the abuse of DNS, the underscore name, or even the fact that this opens the door to the publication of administrative boundaries (and that the DNS doesn't make such boundaries explicit is regarded as a good thing). Therefore, I havent' pursued it. But if anyone thinks this is worth attempting to write down in more detail, I suppose I'm willing. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444253A6AD4 for ; Thu, 5 Feb 2009 07:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEQQm9p9xRBm for ; Thu, 5 Feb 2009 07:25:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B552C3A6AA2 for ; Thu, 5 Feb 2009 07:25:13 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n15FOrwE027046 for ; Thu, 5 Feb 2009 10:24:53 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200902051524.n15FOrwE027046@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Feb 2009 10:24:26 -0500 To: IETF DNS Directorate From: Olafur Gudmundsson In-Reply-To: <498AF291.5030308@cisco.com> References: <4989CF39.6030301@cisco.com> <86A944CA-3C6C-4E11-9905-2F0BE7EB3392@NLnetLabs.nl> <498AF291.5030308@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_764666892==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] BIND config in an RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 15:25:19 -0000 --=====================_764666892==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mark, Having an illustration in an appendix of how X was done by product Y is fine by me as long as the same information is in the main body of the document. Olafur At 09:07 05/02/2009, Mark Townsley wrote: >Thanks guys... On context, this was prompted by an upcoming ID on >how Google did its Google over IPv6 stuff (I know some of you are >already quite familiar with how that was done). > >- Mark > >PS. The -00 *might* indeed have some bind config just for >illustrative example, with clear indication that it will be removed >in a future rev. > >Olaf Kolkman wrote: >>>> >>>> >>>>I do not think that would be kosher. Speaking as an implementer >>>>it would almost feel like IETF endorsement of a product. >>>> >>>>A 'pseudo-config' would be different. >>> >>>Zone file format is defined (started in 1034, right(?)), but not >>>the configuration of the software itself. >> >> >> >>Correct. Zonefile format is defined. >> >>--Olaf >> >>----------------------------------------------------------- >>Olaf M. Kolkman NLnet Labs >> Science Park 140, >>http://www.nlnetlabs.nl/ 1098 XG Amsterdam >> >>NB: The street at which our offices are located has been >>renamed to the above. >> >> >> > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir > --=====================_764666892==.ALT Content-Type: text/html; charset="us-ascii" Mark,
Having an illustration in an appendix of how X was done by product Y is fine by
me as long as the same information is in the main body of the document.

        Olafur

At 09:07 05/02/2009, Mark Townsley wrote:

Thanks guys... On context, this was prompted by an upcoming ID on how Google did its Google over IPv6 stuff (I know some of you are already quite familiar with how that was done).

- Mark

PS. The -00 *might* indeed have some bind config just for illustrative example, with clear indication that it will be removed in a future rev.

Olaf Kolkman wrote:


I do not think that would be kosher. Speaking as an implementer it would almost feel like IETF endorsement of a product.

A 'pseudo-config' would be different.

Zone file format is defined (started in 1034, right(?)), but not the configuration of the software itself.



Correct. Zonefile format is defined.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140,
http://www.nlnetlabs.nl/              1098 XG Amsterdam

NB: The street at which our offices are located has been
renamed to the above.




_______________________________________________
dns-dir mailing list
dns-dir@ietf.org
https://www.ietf.org/mailman/listinfo/dns-dir

--=====================_764666892==.ALT-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A60C3A6BAC; Fri, 6 Feb 2009 01:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VjQoR20rGXL; Fri, 6 Feb 2009 01:52:19 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 912823A6BAB; Fri, 6 Feb 2009 01:52:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,390,1231131600"; d="scan'208";a="151353517" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 06 Feb 2009 04:51:57 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Feb 2009 04:51:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 10:51:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 12, 2009 Telechat Thread-Index: AcmH7cPB4IsyK/alQkWtMTXAzASRIAAUmhVg From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 12, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:52:20 -0000 Please find below the preliminary agenda of the 2/12 IESG telechat. Please review the relevant documents and send me your comments and concerns until 2/11 COB the latest.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-idr-flow-spec-05.txt Dissemination of flow specification rules (Proposed Standard) - 1 of 2 =20 Token: David Ward o draft-ietf-ippm-duplicate-07.txt A One-Way Packet Duplication Metric (Proposed Standard) - 2 of 2=20 Token: Lars Eggert 2.1.2 Returning Item o draft-ietf-forces-protocol-21.txt ForCES Protocol Specification (Proposed Standard) - 1 of 2=20 Token: Ross Callon o draft-ietf-pim-rpf-vector-08.txt The RPF Vector TLV (Proposed Standard) - 2 of 2=20 Token: David Ward 2.2 Individual Submissions 2.2.1 New Item o draft-arkko-arp-iana-rules-05.txt IANA Allocation Guidelines for the Address Resolution Protocol (ARP) (Proposed Standard) - 1 of 1=20 Token: Russ Housley 2.2.2 Returning Item NONE 2.2.3 For Action o draft-atlas-icmp-unnumbered-06.txt Extending ICMP for Interface and Next-hop Identification (Proposed=20 Standard) - 1 of 1=20 Note: Needs to go back to the WG due to the IPR declaration=20 Token: Jari Arkko 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-eai-downgrade-11.txt Downgrading mechanism for Email Address Internationalization (Experimental)=20 - 1 of 3=20 Note: Harald Alvestrand is document shepherd=20 Token: Chris Newman o draft-ietf-ccamp-pc-and-sc-reqs-06.txt Requirements for the Conversion Between Permanent Connections and Switched=20 Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network=20 (Informational) - 2 of 3=20 Token: Ross Callon o draft-ietf-ccamp-gr-description-04.txt Description of the RSVP-TE Graceful Restart Procedures (Informational) - 3=20 of 3=20 Token: Ross Callon 3.1.2 Returning Item o draft-ietf-l2vpn-vpls-mcast-reqts-07.txt Requirements for Multicast Support in Virtual Private LAN Services=20 (Informational) - 1 of 1=20 Note: Bringing back to telechat to get attention on remaining discusses.=20 Token: Mark Townsley 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-routing-history-09.txt Analysis of Inter-Domain Routing Requirements and History (Historic) - 1 of=20 2=20 Token: Ross Callon o draft-irtf-routing-reqs-10.txt A Set of Possible Requirements for a Future Routing Architecture (Historic)=20 - 2 of 2=20 Token: Ross Callon Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0BF3A691A for ; Sun, 15 Feb 2009 03:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+0EzXRolVEV for ; Sun, 15 Feb 2009 03:43:45 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E053B3A677E for ; Sun, 15 Feb 2009 03:43:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,211,1233550800"; d="scan'208";a="161559144" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Feb 2009 06:43:50 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Feb 2009 06:43:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Feb 2009 12:43:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt Thread-Index: AcmOALJ2G9o3pNtEQ++CAaN2JEYvXABX0j3Q References: From: "Romascanu, Dan (Dan)" To: "Paul Hoffman" Cc: Arvel Hathcock , Russ Housley , dns-dir@ietf.org, John Levine Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 11:43:45 -0000 Paul, I still did not see a resolution to the issue of the TXT records. I know that you and Lars-Johan Liman agreed to disagree on this, but other folks on dns-dir seem to agree this is still a problem even with the newly proposed text - see the messages from Patrik Falstrom and Andrew Sullivan. =20 http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html I did not see a response to these on DNS-DIR.=20 Beyond this, there are a number of issues that were agreed to be fixed by edits. I need to see either a revised I-D or RFC Editor notes that include these edits before I can clear my DISCUSS. DNS-DIR folks, Please state your remaining objections if any to the answers provided by Paul in the message I forwarded to the list http://www.ietf.org/mail-archive/web/dns-dir/current/msg00241.html Dan > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org]=20 > Sent: Friday, February 13, 2009 7:29 PM > To: Romascanu, Dan (Dan) > Cc: John Levine; Arvel Hathcock > Subject: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt >=20 > According to=20 > , you=20 > still have a discuss on draft-hoffman-dac-vbr-05.txt. >=20 > You said "The DNS-Directorate review issues need a complete=20 > answer.", we replied with what we thought was a complete=20 > answer, and have not heard anything since then. >=20 > Could you either remove your DISCUSS or let us know what else=20 > we need to do to resolve this? Thanks! >=20 > --Paul Hoffman, Director > --Domain Assurance Council >=20 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61D43A6925 for ; Sun, 15 Feb 2009 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a072KnbyKszR for ; Sun, 15 Feb 2009 10:06:01 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A40BF3A6867 for ; Sun, 15 Feb 2009 10:06:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,212,1233550800"; d="scan'208";a="137533034" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Feb 2009 13:06:07 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Feb 2009 13:06:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Feb 2009 19:05:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt Thread-Index: AcmPl1I6DXbFo6ijQ4ykDvAU/rWBPQAACH1w References: From: "Romascanu, Dan (Dan)" To: "Paul Hoffman" Cc: Arvel Hathcock , Russ Housley , dns-dir@ietf.org, John Levine Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:06:02 -0000 In-line.=20 Dan =20 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org]=20 > Sent: Sunday, February 15, 2009 8:00 PM > To: Romascanu, Dan (Dan) > Cc: John Levine; Arvel Hathcock; dns-dir@ietf.org; Russ Housley > Subject: RE: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt >=20 > At 12:43 PM +0100 2/15/09, Romascanu, Dan (Dan) wrote: > >Paul, > > > >I still did not see a resolution to the issue of the TXT records. I=20 > >know that you and Lars-Johan Liman agreed to disagree on this, but=20 > >other folks on dns-dir seem to agree this is still a problem=20 > even with=20 > >the newly proposed text - see the messages from Patrik Falstrom and=20 > >Andrew Sullivan. > > > >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html > >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html > > > >I did not see a response to these on DNS-DIR. >=20 > That's because we were not made aware that we were supposed=20 > to be following DNS-DIR. If you told us that and I lost the=20 > message, I apologize. I will start reading it now and will=20 > respond there. I apologize, it's my fault I guess. I assumed that you are following the DNS-DIR discussions. =20 >=20 > >Beyond this, there are a number of issues that were agreed=20 > to be fixed=20 > >by edits. I need to see either a revised I-D or RFC Editor=20 > notes that=20 > >include these edits before I can clear my DISCUSS. >=20 > That works for me. Some ADs want us *not* to revise drafts,=20 > others insist on it. FWIW, I prefer your way (make edits so=20 > the AD in question can see them). I will also wind in the=20 > changes we agreed to for Lisa and Chris. Just to be clear, the change control is with the shepherding AD - Russ in this case. So please get his advice about whether and when to publish a new I-D.=20 >=20 > --Paul Hoffman, Director > --Domain Assurance Council >=20 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BC43A6AED for ; Sun, 15 Feb 2009 11:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdkmOZpeLt1F for ; Sun, 15 Feb 2009 11:26:15 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 199D83A67D4 for ; Sun, 15 Feb 2009 11:26:15 -0800 (PST) Received: from crankycanuck.ca (unknown [208.251.244.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 74CBE2FE9B14; Sun, 15 Feb 2009 19:26:22 +0000 (UTC) Date: Sun, 15 Feb 2009 14:26:18 -0500 From: Andrew Sullivan To: "Romascanu, Dan (Dan)" Message-ID: <20090215192617.GB29518@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Arvel Hathcock , John Levine , Russ Housley , dns-dir@ietf.org, Paul Hoffman Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 19:26:15 -0000 On Sun, Feb 15, 2009 at 12:43:09PM +0100, Romascanu, Dan (Dan) wrote: > folks on dns-dir seem to agree this is still a problem even with the > newly proposed text - see the messages from Patrik Falstrom and Andrew > Sullivan. I think perhaps I wasn't as clear as I might have been in that discussion. The point of the bit, > we've already given in on the brain-dead approach of using TXT records > for DKIM. So I guess we're stuck with it here. was supposed to be that I think TXT records are an awful approach, but now that it's all over DKIM anyway, this additional bit of horror doesn't make things any worse. So I'm not going to object out loud. My apologies for being imprecise. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4AB3A67B5 for ; Sun, 15 Feb 2009 10:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQQIFSDBkHuu for ; Sun, 15 Feb 2009 10:00:38 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E39DD3A676A for ; Sun, 15 Feb 2009 10:00:37 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1FI0OfT079798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 11:00:25 -0700 (MST) (envelope-from paul.hoffman@domain-assurance.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 15 Feb 2009 10:00:22 -0800 To: "Romascanu, Dan (Dan)" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Mon, 16 Feb 2009 01:19:15 -0800 Cc: Arvel Hathcock , Russ Housley , dns-dir@ietf.org, John Levine Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:00:39 -0000 At 12:43 PM +0100 2/15/09, Romascanu, Dan (Dan) wrote: >Paul, > >I still did not see a resolution to the issue of the TXT records. I know >that you and Lars-Johan Liman agreed to disagree on this, but other >folks on dns-dir seem to agree this is still a problem even with the >newly proposed text - see the messages from Patrik Falstrom and Andrew >Sullivan. > >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00240.html >http://www.ietf.org/mail-archive/web/dns-dir/current/msg00239.html > >I did not see a response to these on DNS-DIR. That's because we were not made aware that we were supposed to be following DNS-DIR. If you told us that and I lost the message, I apologize. I will start reading it now and will respond there. >Beyond this, there are a number of issues that were agreed to be fixed >by edits. I need to see either a revised I-D or RFC Editor notes that >include these edits before I can clear my DISCUSS. That works for me. Some ADs want us *not* to revise drafts, others insist on it. FWIW, I prefer your way (make edits so the AD in question can see them). I will also wind in the changes we agreed to for Lisa and Chris. --Paul Hoffman, Director --Domain Assurance Council Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96013A6A8F for ; Mon, 16 Feb 2009 03:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wrm6M5Y9rDo for ; Mon, 16 Feb 2009 03:26:57 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D39613A68D2 for ; Mon, 16 Feb 2009 03:26:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233550800"; d="scan'208";a="152400344" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Feb 2009 06:27:05 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Feb 2009 06:27:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 12:26:49 +0100 Message-ID: In-Reply-To: <20090215192617.GB29518@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt Thread-Index: AcmPo0t1OYBK3+2aQqawZDthsXPYYQAheE6w References: <20090215192617.GB29518@shinkuro.com> From: "Romascanu, Dan (Dan)" To: "Andrew Sullivan" Cc: Arvel Hathcock , John Levine , Russ Housley , dns-dir@ietf.org, Paul Hoffman Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 11:26:57 -0000 My question is whether there is any change in text that would improve or better document the current status.=20 Dan =20 > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com]=20 > Sent: Sunday, February 15, 2009 9:26 PM > To: Romascanu, Dan (Dan) > Cc: Paul Hoffman; Arvel Hathcock; Russ Housley;=20 > dns-dir@ietf.org; John Levine > Subject: Re: [dns-dir] Removing your DISCUSS on=20 > draft-hoffman-dac-vbr-05.txt >=20 > On Sun, Feb 15, 2009 at 12:43:09PM +0100, Romascanu, Dan (Dan) wrote: >=20 > > folks on dns-dir seem to agree this is still a problem even=20 > with the=20 > > newly proposed text - see the messages from Patrik Falstrom=20 > and Andrew > > Sullivan. =20 >=20 > I think perhaps I wasn't as clear as I might have been in=20 > that discussion. The point of the bit, >=20 > > we've already given in on the brain-dead approach of using=20 > TXT records=20 > > for DKIM. So I guess we're stuck with it here. >=20 > was supposed to be that I think TXT records are an awful=20 > approach, but now that it's all over DKIM anyway, this=20 > additional bit of horror doesn't make things any worse. So=20 > I'm not going to object out loud. > My apologies for being imprecise. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. >=20 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C5A3A6BCF for ; Mon, 16 Feb 2009 07:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk1Lv3TPJnur for ; Mon, 16 Feb 2009 07:40:02 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 708853A6A2D for ; Mon, 16 Feb 2009 07:40:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,216,1233550800"; d="scan'208";a="137599070" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Feb 2009 10:40:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Feb 2009 10:40:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 16:39:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt Thread-Index: AcmQTF74vWH9pdj4TN+Jutduk/ozcwAAD8fA From: "Romascanu, Dan (Dan)" To: Cc: Arvel Hathcock , Russ Housley , John Levine , Paul Hoffman Subject: [dns-dir] FW: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 15:40:02 -0000 DNS-DIR, Please see the relevant parts of Paul Hoffman's response to the latest = comments from Andrew and Patrik.=20 Dan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org]=20 Sent: Monday, February 16, 2009 5:36 PM To: Romascanu, Dan (Dan) Cc: Russ Housley; John Levine; Arvel Hathcock Subject: RE: Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt At 10:28 AM +0100 2/16/09, Romascanu, Dan (Dan) wrote: >DNS-DIR is a directorate list, and the access is restricted to members = >of the directorate. Are you interested to become part of this=20 >directorate? No. You said "I did not see a response to these on DNS-DIR." I tried to = join the mailing list because I could not read the messages that you = said I had to respond to unless I was a list member. >If you are not interested I will just relay the relevant messages.=20 >Sorry for not catching this situation earlier. OK. FWIW, you may want to review your other DISCUSSes and see if any of = them are blocked by a similar deadly embrace. >In the meantime, I am attaching the two relevant mails and will relay=20 >any other relevant messages. Sounds good. Please let us know if these meet your needs. We fully = understand that many people in the DNS Directorate have a strong style = preference for using new RRTYPEs. However, based on well-established = operational reasons, we chose to use the same technical methods that are = used in the DKIM standard. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andrew Sullivan said: >we've already given in on the brain-dead approach of using TXT records = for DKIM. So I guess we're stuck with it here. We fully agree. We use the exact same semantics that DKIM used so that = we have the same DNS properties that the DKIM standard uses. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Patrik F=E4ltst=F6m said: >One day you have a TXT record that by definition MUST have the same = owner as another RR. And if that RR is also of type TXT, then you have a = problem. Two TXT with same owner. The only way for this to happen is for a future standard to define a = different semantic for domain names that have _domainkey or _vouch = labels in them. If the IETF allows such re-use of namespaces, then of = course there can be problems in the future. We assume that will not = happen for things on standards track, just as we assume that the IETF = will issue a future standard to define a different semantic for an = existing RRTYPE. --Paul Hoffman, Director --Domain Assurance Council Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA03D3A6D18 for ; Mon, 16 Feb 2009 13:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+676AolYPuj for ; Mon, 16 Feb 2009 13:13:39 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id AF14E3A6954 for ; Mon, 16 Feb 2009 13:13:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,218,1233550800"; d="scan'208";a="161690078" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Feb 2009 16:13:49 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Feb 2009 16:13:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 22:13:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-hoffman-dac-vbr-06.txt Thread-Index: AcmQewLorjt8oy+0Qouyip89fj8+QQAADBEg From: "Romascanu, Dan (Dan)" To: Cc: Paul Hoffman Subject: [dns-dir] FW: I-D Action:draft-hoffman-dac-vbr-06.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:13:40 -0000 Folks who reviewed the I-D, please let me now if there are still critical concerns left.=20 Thanks and Regards, Dan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org]=20 Sent: Monday, February 16, 2009 11:10 PM To: Cullen Jennings; Romascanu, Dan (Dan); Chris Newman Cc: John Levine; Arvel Hathcock; Russ Housley Subject: Fwd: I-D Action:draft-hoffman-dac-vbr-06.txt Greetings again. We have just updated the VBR draft with the changes we have sent to the IESG to date. We think this clears all of your DISCUSS desires (other than maybe Dan needing to hear back from the DNS Directorate). Please let us know if you still have open issues; if not, please feel free to update your votes. --Paul Hoffman >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Vouch By Reference > Author(s) : P. Hoffman, et al. > Filename : draft-hoffman-dac-vbr-06.txt > Pages : 14 > Date : 2009-02-16 > >This document describes the Vouch By Reference (VBR) protocol. VBR is=20 >a protocol for adding third-party certification to email. It permits=20 >independent third parties to certify the owner of a domain name that is >associated with received mail. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-06.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader=20 >implementation to automatically retrieve the ASCII version of the=20 >Internet-Draft. > > >[The following attachment must be fetched by ftp. Command-click the=20 >URL below to ask your ftp client to fetch it.]=20 > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAEC3A6BBC for ; Tue, 17 Feb 2009 06:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6az8S8U941R7 for ; Tue, 17 Feb 2009 06:52:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 23EDA3A6B7A for ; Tue, 17 Feb 2009 06:52:18 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9938D2FE9B14; Tue, 17 Feb 2009 14:52:27 +0000 (UTC) Date: Tue, 17 Feb 2009 09:52:25 -0500 From: Andrew Sullivan To: "Romascanu, Dan (Dan)" Message-ID: <20090217145225.GC32591@shinkuro.com> References: <20090215192617.GB29518@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Arvel Hathcock , John Levine , Russ Housley , dns-dir@ietf.org, Paul Hoffman Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 14:52:18 -0000 On Mon, Feb 16, 2009 at 12:26:49PM +0100, Romascanu, Dan (Dan) wrote: > My question is whether there is any change in text that would improve or > better document the current status. I doubt it. I'm unhappy to say that we passed, some time ago, the point where it's even possible to discuss whether TXT records are a good idea for this use-case. I preduct any attempt even to address the topic will result in unresolvable differences of opinion. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD8E3A687F; Thu, 19 Feb 2009 23:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrOx6oEdljs6; Thu, 19 Feb 2009 23:05:37 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 369173A6802; Thu, 19 Feb 2009 23:05:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,239,1233550800"; d="scan'208,217";a="162191735" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Feb 2009 02:05:50 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Feb 2009 02:05:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99329.A0F9D755" Date: Fri, 20 Feb 2009 08:04:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 26, 2009 Telechat Thread-Index: AcmS9B7gt+U8FohGRR6ye+lyv9nagAANUsfC References: <20090220004213.A3F773A68B4@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: , , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 26, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 07:05:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99329.A0F9D755 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find below the preliminary agenda of the 2/26 telechat. Please = send me your comments and concerns until 2/25 COB.=20 Thanks and Regards, Dan 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-mediactrl-vxml-04.txt SIP Interface to VoiceXML Media Services (Proposed Standard) - 1 of = 2 Token: Jon Peterson o draft-ietf-dime-qos-parameters-09.txt Quality of Service Parameters for Usage with Diameter (Proposed Standard) -=20 2 of 2=20 Token: Dan Romascanu 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-rserpool-mib-11.txt Reliable Server Pooling MIB Module Definition (Experimental) - 1 of = 3 Token: Magnus Westerlund o draft-ietf-mediactrl-architecture-04.txt An Architectural Framework for Media Server Control (Informational) = - 2 of=20 3=20 Token: Jon Peterson o draft-ietf-pcn-architecture-09.txt Pre-Congestion Notification (PCN) Architecture (Informational) - 3 = of 3=20 Note: Scott Bradner (sob@harvard.edu) is the Document Shepherd.=20 Token: Lars Eggert ------_=_NextPart_001_01C99329.A0F9D755 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: PRELIMINARY Agenda and Package for February 26, 2009 Telechat =

Please find below the preliminary agenda of the 2/26 = telechat. Please send me your comments and concerns until 2/25 COB.

Thanks and Regards,

Dan


2. Protocol Actions
        Reviews should focus on these = questions: "Is this document a
        reasonable basis on which to = build the salient part of the Internet
        infrastructure? If not, what = changes would make it so?"


2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-mediactrl-vxml-04.txt
    SIP Interface to VoiceXML Media Services (Proposed = Standard) - 1 of 2

    Token: Jon Peterson
  o draft-ietf-dime-qos-parameters-09.txt
    Quality of Service Parameters for Usage with Diameter = (Proposed
Standard) -
    2 of 2
    Token: Dan Romascanu

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
        Reviews should focus on these = questions: "Is this document a reasonable
        contribution to the area of = Internet engineering which it covers? If
        not, what changes would make = it so?"

3.1.1 New Item
  o draft-ietf-rserpool-mib-11.txt
    Reliable Server Pooling MIB Module Definition = (Experimental) - 1 of 3

    Token: Magnus Westerlund
  o draft-ietf-mediactrl-architecture-04.txt
    An Architectural Framework for Media Server Control = (Informational) -
2 of
    3
    Token: Jon Peterson
  o draft-ietf-pcn-architecture-09.txt
    Pre-Congestion Notification (PCN) Architecture = (Informational) - 3 of
3
    Note: Scott Bradner (sob@harvard.edu) is the Document = Shepherd.
    Token: Lars Eggert

------_=_NextPart_001_01C99329.A0F9D755-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E593A68B5 for ; Fri, 20 Feb 2009 06:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuhQJ3o0I47J for ; Fri, 20 Feb 2009 06:20:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 333B93A6837 for ; Fri, 20 Feb 2009 06:20:03 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n1KEKCSp061172; Fri, 20 Feb 2009 09:20:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200902201420.n1KEKCSp061172@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Feb 2009 09:19:50 -0500 To: "Romascanu, Dan (Dan)" , From: Olafur Gudmundsson In-Reply-To: References: <20090220004213.A3F773A68B4@core3.amsl.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_763581171==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for February 26, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 14:20:05 -0000 --=====================_763581171==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed No documents in the DNS-early-warning data base. Olafur At 02:04 20/02/2009, Romascanu, Dan (Dan) wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C99329.A0F9D755" > >Please find below the preliminary agenda of the 2/26 telechat. >Please send me your comments and concerns until 2/25 COB. > >Thanks and Regards, > >Dan > > >2. Protocol Actions > Reviews should focus on these questions: "Is this document a > reasonable basis on which to build the salient part of the Internet > infrastructure? If not, what changes would make it so?" > > >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-mediactrl-vxml-04.txt > SIP Interface to VoiceXML Media Services (Proposed Standard) - 1 of 2 > > Token: Jon Peterson > o draft-ietf-dime-qos-parameters-09.txt > Quality of Service Parameters for Usage with Diameter (Proposed >Standard) - > 2 of 2 > Token: Dan Romascanu > >2.1.2 Returning Item >NONE > >2.2 Individual Submissions >2.2.1 New Item >NONE >2.2.2 Returning Item >NONE > >3. Document Actions > >3.1 WG Submissions > Reviews should focus on these questions: "Is this document > a reasonable > contribution to the area of Internet engineering which it covers? If > not, what changes would make it so?" > >3.1.1 New Item > o draft-ietf-rserpool-mib-11.txt > Reliable Server Pooling MIB Module Definition (Experimental) - 1 of 3 > > Token: Magnus Westerlund > o draft-ietf-mediactrl-architecture-04.txt > An Architectural Framework for Media Server Control (Informational) - >2 of > 3 > Token: Jon Peterson > o draft-ietf-pcn-architecture-09.txt > Pre-Congestion Notification (PCN) Architecture (Informational) - 3 of >3 > Note: Scott Bradner (sob@harvard.edu) is the Document Shepherd. > Token: Lars Eggert > > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir --=====================_763581171==.ALT Content-Type: text/html; charset="us-ascii"
No documents in the DNS-early-warning data base.
        
Olafur

At 02:04 20/02/2009, Romascanu, Dan (Dan) wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C99329.A0F9D755"

Please find below the preliminary agenda of the 2/26 telechat. Please send me your comments and concerns until 2/25 COB.

Thanks and Regards,

Dan


2. Protocol Actions
        Reviews should focus on these questions: "Is this document a
        reasonable basis on which to build the salient part of the Internet
        infrastructure? If not, what changes would make it so?"


2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-mediactrl-vxml-04.txt
    SIP Interface to VoiceXML Media Services (Proposed Standard) - 1 of 2

    Token: Jon Peterson
  o draft-ietf-dime-qos-parameters-09.txt
    Quality of Service Parameters for Usage with Diameter (Proposed
Standard) -
    2 of 2
    Token: Dan Romascanu

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
        Reviews should focus on these questions: "Is this document a reasonable
        contribution to the area of Internet engineering which it covers? If
        not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-rserpool-mib-11.txt
    Reliable Server Pooling MIB Module Definition (Experimental) - 1 of 3

    Token: Magnus Westerlund
  o draft-ietf-mediactrl-architecture-04.txt
    An Architectural Framework for Media Server Control (Informational) -
2 of
    3
    Token: Jon Peterson
  o draft-ietf-pcn-architecture-09.txt
    Pre-Congestion Notification (PCN) Architecture (Informational) - 3 of
3
    Note: Scott Bradner (sob@harvard.edu) is the Document Shepherd.
    Token: Lars Eggert



_______________________________________________
dns-dir mailing list
dns-dir@ietf.org
https://www.ietf.org/mailman/listinfo/dns-dir
--=====================_763581171==.ALT-- Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4C53A6830; Sun, 22 Feb 2009 06:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80f9Y86Ud0AR; Sun, 22 Feb 2009 06:53:23 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EE7CD3A67F6; Sun, 22 Feb 2009 06:53:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,250,1233550800"; d="scan'208";a="162370034" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Feb 2009 09:53:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2009 09:53:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Feb 2009 15:53:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: AcmTqq3gDziyaqMCTLqqorYpfGZyZABUl7Mg From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: Internal WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 14:53:24 -0000 If there are any questions, comments or concerns please let me or Ron know before COB 2/25.=20 Thanks and Regards, Dan=20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Saturday, February 21, 2009 12:29 AM To: iesg@ietf.org; iab@iab.org; jpv@cisco.com; culler@eecs.berkeley.edu Subject: Internal WG Review: Recharter of Routing Over Low power and Lossy networks (roll)=20 A new charter for the Routing Over Low power and Lossy networks working group (roll) in the Routing Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat Routing Over Low power and Lossy networks (roll) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Current Status: Active Working Group Last Modified: 2009-02-04 Additional information is available at tools.ietf.org/wg/roll=20 Chair(s): JP Vasseur [jpv@cisco.com] David Culler [culler@eecs.berkeley.edu]=20 Routing Area Director(s): Ross Callon [rcallon@juniper.net] David Ward [dward@cisco.com]=20 Routing Area Advisor: David Ward [dward@cisco.com]=20 Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks ?interconnected by protocol translation gateways and proxies.=20 Generally speaking, LLNs have at least five distinguishing characteristics:=20 - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers.=20 - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements.=20 As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial =20 monitoring, building automation (HVAC, lighting, access ?control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban? sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with =20 very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes.=20 The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. =20 Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F65E3A6AC3; Sun, 22 Feb 2009 07:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYvvSKS2rEi1; Sun, 22 Feb 2009 07:08:39 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1A91E3A6A4F; Sun, 22 Feb 2009 07:08:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,250,1233550800"; d="scan'208";a="162370637" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Feb 2009 10:08:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2009 10:08:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Feb 2009 16:08:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) Thread-Index: AcmTiXyymYQ202UcSQuWAIYkTJyCKgBdcWMg From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: Internal WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 15:08:40 -0000 If there are any questions, comments or concerns please let me or Ron know before COB 2/25.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, February 20, 2009 8:31 PM To: iesg@ietf.org; iab@iab.org; ryuji.wakikawa@gmail.com; T.Clausen@computer.org Subject: Internal WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf)=20 A new charter for the Ad-Hoc Network Autoconfiguration working group (autoconf) in the Internet Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------------------------- Last Modified: 2009-02-18=20 =20 Cuurent Status: Active Working Group=20 =20 Additional information is available at tools.ietf.org/wg/autoconf=20 =20 Chair(s):=20 Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen [T.Clausen@computer.org]=20 =20 Internet Area Director(s):=20 Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com]=20 =20 Internet Area Advisor:=20 Jari Arkko [jari.arkko@piuha.net]=20 =20 Mailing Lists:=20 General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive:=20 http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=20 =20 Description of Working Group:=20 =20 In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links.=20 =20 The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks.=20 =20 Once this sole work item is completed, the group can be rechartered to work on additional issues.=20 =20 Goals and Milestones:=20 =20 Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG