From owner-namedroppers@ops.ietf.org Wed Nov 1 10:13:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23000 for ; Wed, 1 Nov 2000 10:13:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qz1L-000CsU-00 for namedroppers-data@psg.com; Wed, 01 Nov 2000 06:37:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qz1L-000CsO-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 06:37:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qz1K-000Lmi-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 06:37:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Wed, 01 Nov 2000 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 1 10:13:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23039 for ; Wed, 1 Nov 2000 10:13:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qytM-000Cjd-00 for namedroppers-data@psg.com; Wed, 01 Nov 2000 06:29:28 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qytM-000CjX-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 06:29:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qytM-000Ljp-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 06:29:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: hardie@equinix.com cc: dnsop@cafax.se, aroot@ops.ietf.org Subject: Re: Anycast root metrics and analysis In-reply-to: Your message of "Tue, 31 Oct 2000 13:32:58 PST." <200010312132.NAA27371@nemo.corp.equinix.com> Date: Wed, 01 Nov 2000 15:54:02 +0700 Message-ID: <2988.973068842@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 31 Oct 2000 13:32:58 -0800 (PST) From: hardie@equinix.com Message-ID: <200010312132.NAA27371@nemo.corp.equinix.com> | on the number of requests coming in. The use of RTT and periodic | checks on server response time recognizes the importance of quick | responses for the DNS system; Yes, of course, faster is always better - but there is nothing in the DNS that requires a response from the quickest server, any one will do. | Without any additional tweaking, an individual network will get the | anycast server which is reachable via the shortest AS path-length. That's fine. Basically the point is to add additional servers and help spread the load. As much as that also results in increased performance to the end sites, that's great. | That may or may not map onto the server instance that would generate | the best performance. True - but nor does any algorithm, the one bind uses now bases expected response time upon past performance - which also may, or may not, map onto the server that would generate the best performance. Each additional anycast group of root servers (ideally there would be several of them, at different addresses, living in different ASs) will give you an extra choice of root server to use. Further, as the concept becomes proven, it may be that there will be many more root servers participating in each anycast group - it is entirely possible that each fairly major AS will have one local. That ought mean that a server qith very good response time could be found from just about anywhere. | The access lists in the route filter would need to be updated whenever | a different instance of the anycast server is notably better. I don't think doing manually operated performance based routing is a scheme that will ever work... | In the case | that an anycast system is so well distributed that every AS runs its | own copy of an anycast AS and root server, the parallel would indeed | be strong. In the current case, though, the very small number of | participants in the system seems to demonstrate that the BGP policy of | the adjacent and transit ASes is going to dominate the selection of | anycast root server instances. That produces a conflict of metrics | and suboptimal results. The current setup is intended as a proof of concept - that is, that it can be made to work at all. I don't think it was ever intended to be optimal. | What do others think of this analysis? I suspect that you're worrying too much over nothing. The spikes in reachability to the servers that your data collection shows could do with more analysis though - do you have any idea what is causing them? Is something dropping off the net? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 1 14:31:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05279 for ; Wed, 1 Nov 2000 14:31:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13r3CW-000HL4-00 for namedroppers-data@psg.com; Wed, 01 Nov 2000 11:05:32 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13r3CW-000HKy-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 11:05:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13r3CV-000Nti-00 for namedroppers@ops.ietf.org; Wed, 01 Nov 2000 11:05:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001101135817.00def510@localhost> Date: Wed, 01 Nov 2000 14:06:51 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNS server mib discussion mailing list: dnsext-mib@lists.tislabs.com Cc: bind9-users@isc.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have created a new mailing list to discuss proposals for DNS server MIB(s) for interested parties. Anyone can subscribe mailto://dnsext-mib-request@lists.tislabs.com The draft charter for the mailing list is ---------------- This is a mailing list charted by the IETF DNSEXT working group to allow interested parties to discuss in an un moderated forum the case for defining MIB or MIBs for DNS servers. The goal is to develop proposals for DNS MIB(s) to present to the DNSEXT working group. The current agenda is: 0. Revise the charter to reflect group consensus. 1. Develop a statement of "The case for SNMPv3 MIB support in DNS servers" 2. Define a set of MIBs to work define and specify what functionality will not be supported. 2.5. Define how vendor specific MIB's can extend the MIB framework. 3. Develop guidelines on how to use SNMPv3 USM and VACM to do access control in the MIB's. The restrictions on proposals are: 1. Implementation independent. 2. SNMPv3 is used for access control. 3. Simple and extensible. The list archive can be found at ftp://ftp.tislabs.com/pub/lists/dnsext-mib to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 3 02:48:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07638 for ; Fri, 3 Nov 2000 02:48:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13rasM-000HYm-00 for namedroppers-data@psg.com; Thu, 02 Nov 2000 23:02:58 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13rasM-000HYc-00 for namedroppers@ops.ietf.org; Thu, 02 Nov 2000 23:02:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rasM-000Czk-00 for namedroppers@ops.ietf.org; Thu, 02 Nov 2000 23:02:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001102220648.00d0beb0@localhost> Date: Thu, 02 Nov 2000 22:15:05 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Agenda items for San Diego meeting Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We have 1 2.5 hour slot on Wednesday. This is a call for items to be discussed. Just as a reminder the ID deadline for drafts is November 17 - Internet Draft Cut-off for inital document (-00) submissions November 24 - Internet-Draft final submission cutoff date at 17:00 ET Authors remember, I like to read the documents before they are posted! Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 3 11:34:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28953 for ; Fri, 3 Nov 2000 11:34:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13rj2F-0002MZ-00 for namedroppers-data@psg.com; Fri, 03 Nov 2000 07:45:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13rj2F-0002MT-00 for namedroppers@ops.ietf.org; Fri, 03 Nov 2000 07:45:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rj2F-000JyC-00 for namedroppers@ops.ietf.org; Fri, 03 Nov 2000 07:45:43 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Nov 2000 08:15:35 -0500 To: DNSEXT WG Mailing list From: Edward Lewis Subject: CERT records Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Refering to RFC 2538, is it worth proposing a new "certificate type value" for a PKIX X509 CRL? There is a value (1) for X509 PKIX certificates. It could be argued that this value should be used for CRLs. The reason I am floating this is because of a decidedly non-protocol issue. In Java there are classes for X509Certificate and X509CRL. Becuase of the language's inheritence model [1], the two cannot be treated as the other safely. Ergo, when I get bits from DNS, I have to know ahead of time whether the bits are a Certificate or a CRL[2]. Knowing ahead of time could be made easy through a new certificate type value. [1] X509Certificate extends Certificate, X509CRL extends CRL, and no multiple inheritence is allowed. The downside is that the two X509'ers share some common fields and semantics which cannot share the same code. [3] [2] Yeah, I could try casting as one, getting an exception/error/failure and then try the other. But this is an unelegant solution, and it would be nice idf the "protocol" didn't foster ugly programming tricks. [3] I don't want to turn this thread into a Java debate. I'm not a Java expert, I just write demo code, so perhaps I'm missing an obvious good solution. (Private email help is always welcome.) Please restrict responses to whether there should be a *proposal* to allocate another number. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 3 13:01:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22517 for ; Fri, 3 Nov 2000 13:01:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13rknY-0003gg-00 for namedroppers-data@psg.com; Fri, 03 Nov 2000 09:38:40 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13rknY-0003ga-00 for namedroppers@ops.ietf.org; Fri, 03 Nov 2000 09:38:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rknY-000KW0-00 for namedroppers@ops.ietf.org; Fri, 03 Nov 2000 09:38:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 3 Nov 2000 18:23:20 +0100 (CET) From: To: Edward Lewis cc: DNSEXT WG Mailing list Subject: Re: CERT records In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 3 Nov 2000, Edward Lewis wrote: > Refering to RFC 2538, is it worth proposing a new "certificate type value" > for a PKIX X509 CRL? > > There is a value (1) for X509 PKIX certificates. It could be argued that > this value should be used for CRLs. The certificate section of PKIX CERT records should start with a OID length byte and then a X.500 OID specifying the content of the CERT RR. Among others, section 2.3 of rfc 2538 mention two OIDs that look relevant: id-at-userCertificate = { joint-iso-ccitt(2) ds(5) at(4) 36 } == 0x 03 55 04 24 id-at-certificateRevocationList = { joint-iso-ccitt(2) ds(5) at(4) 39 } == 0x 03 55 04 27 > The reason I am floating this is because of a decidedly non-protocol issue. > In Java there are classes for X509Certificate and X509CRL. Becuase of the > language's inheritence model [1], the two cannot be treated as the other > safely. Ergo, when I get bits from DNS, I have to know ahead of time > whether the bits are a Certificate or a CRL[2]. Knowing ahead of time > could be made easy through a new certificate type value. To my understanding it would be possible to use the OIDs for this. Hope this helps. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Nov 4 09:41:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12275 for ; Sat, 4 Nov 2000 09:41:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13s3yD-000FMu-00 for namedroppers-data@psg.com; Sat, 04 Nov 2000 06:06:57 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13s3yD-000FMo-00 for namedroppers@ops.ietf.org; Sat, 04 Nov 2000 06:06:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13s3y9-0003M5-00 for namedroppers@ops.ietf.org; Sat, 04 Nov 2000 06:06:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from [216.6.89.98] by web2304.mail.yahoo.com; Sat, 04 Nov 2000 03:22:12 PST Date: Sat, 4 Nov 2000 03:22:12 -0800 (PST) From: Shishir Jain Subject: Info about DNS relay To: namedroppers@ops.ietf.org Cc: sjain@indiamail.com, nordmark@eng.sun.com, narten@raleigh.ibm.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hello: I'm interested in knowing what is "DNS Relay", as mentioned, in the specification sheets of some of the Customer Premises Equipment of xDSL. Is there any standards on what DNS relay is? What is the functionalities supported by DNS relay? Anything being looked at by DNS working group of IETF? Any information would be of help. Please reply to mailto:shishir_jain@yahoo.com Thanks & Regards Shishir to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 9 17:14:29 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27085 for ; Thu, 9 Nov 2000 17:14:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13tz9i-000FDR-00 for namedroppers-data@psg.com; Thu, 09 Nov 2000 13:22:46 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13tz9i-000FDJ-00 for namedroppers@ops.ietf.org; Thu, 09 Nov 2000 13:22:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13tz9i-000KBo-00 for namedroppers@ops.ietf.org; Thu, 09 Nov 2000 13:22:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0B1090.F9100C2B@quadritek.com> Date: Thu, 09 Nov 2000 16:01:04 -0500 From: rhall@quadritek.com (Randy Hall) To: namedroppers@ops.ietf.org Subject: TKEY query delete mode Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Section 4.2 of RFC 2930 (TKEY protocol) describes a query to request the server delete a key. It is unclear (to me) whether a) the server must respond to the query after deleting the key, and b) if so, whether the response must be signed (presumably using the deleted key, which seems like a bad idea). The RFC does not appear to be explicit. I assume the answer is NO to both questions. Can anyone clarify this for me? Thx in advance, Randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 10 08:12:49 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15683 for ; Fri, 10 Nov 2000 08:12:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13uDEm-0003wh-00 for namedroppers-data@psg.com; Fri, 10 Nov 2000 04:24:56 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13uDEl-0003wb-00 for namedroppers@ops.ietf.org; Fri, 10 Nov 2000 04:24:55 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13uDEl-0001LA-00 for namedroppers@ops.ietf.org; Fri, 10 Nov 2000 04:24:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Nov 2000 21:43:50 -0800 (PST) From: Brian Wellington To: Randy Hall Cc: namedroppers@ops.ietf.org Subject: Re: TKEY query delete mode In-Reply-To: <3A0B1090.F9100C2B@quadritek.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit On Thu, 9 Nov 2000, Randy Hall wrote: > Section 4.2 of RFC 2930 (TKEY protocol) describes a query > to request the server delete a key. > > It is unclear (to me) whether > > a) the server must respond to the query after deleting the > key, and I would think so. The text doesn't give any indication otherwise, and all normal queries must be responded to. > b) if so, whether the response must be signed (presumably > using the deleted key, which seems like a bad idea). Again, the text doesn't indicate anything out of the ordinary. If the request is signed (which it must be, according to section 3), the response must be signed with the same key (according to RFC 2845). Nothing says that it must be the same key as is being deleted, but I don't see anything saying it can't. For the record, bind 9 supports signing the response to a deletion with the deleted key. The key is no longer usable for any other purpose once the deletion is processed, and the key is actually deleted after the response is signed. > The RFC does not appear to be explicit. I assume the answer > is NO to both questions. Can anyone clarify this for me? I would assume the answers would both be YES, seeing no indication of the contrary. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Nov 11 23:49:37 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06364 for ; Sat, 11 Nov 2000 23:49:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13uoPy-0001IJ-00 for namedroppers-data@psg.com; Sat, 11 Nov 2000 20:06:58 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13uoPx-0001ID-00 for namedroppers@ops.ietf.org; Sat, 11 Nov 2000 20:06:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13uoPs-000LVM-00 for namedroppers@ops.ietf.org; Sat, 11 Nov 2000 20:06:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200011111700.SAA16187@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Thomas Narten Cc: IETF DNSEXT WG Subject: Re: draft-ietf-dnsext-apl-rr-01.txt In-reply-to: Your message of "Wed, 16 Aug 2000 11:54:44 EDT." <200008161554.LAA15783@ludwigia.raleigh.ibm.com> Date: Sat, 11 Nov 2000 17:59:59 +0100 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you, Thomas, for the comments and apologies for the late response. I must have missed the original posting. > > The specification of particular application scenarios is out of the > > scope of this document. > > I.e, this ID defines an RR for which no usage has been specified, and > for which in the future, multiple incompatable usages might be > specified. This ID defines an RR which is a syntactic framework for multiple uses, some of which are outlined in the document. Of course `incompatible usages' *might* be specified, but that is of course not intended and could as well happen to any other of the already existing RR types. The A and PTR RR types already bear different meanings in different contexts (RFC 1101) without leading to significant trouble. > It seems to me that the semantics of an RR should be well-defined and > uniformly interpreted by clients. If they are not, one runs the risk > that different clients will query for the same RR (but for different > reasons) and get unexpected results. This is particularly true if two I agree with you if 'client' in your statement means what is called 'application scenario' in the document, but I do not yet see this principle violated by the ID. > result. Thus, even in cases where the raw format of an RR might be > correct for multiple different uses, it might be better to define > multiple different RRs each having the same syntax, but (possibly) > different semantics and (possibly) different uses. Another example of a multi-usage RR type is the SRV RR. It has a fixed syntax but different meanings depending on the service name which is made part of the owner name queried for. > I note that semantics/usage of the Negation Flag is explicitely not > defined in this document, so the RR seems underspecified. Section 7, Applicability Statement, explicitly calls for a specification of the exact semantics of the "!" character, so this part of the specification is intentionally deferred. The in-zone and on-the-wire representation of this flag should be clear from the ID and I'd appreciate any hint should something still be wrong with that. > As an example, consider TXT records. You can put lots of things in > them, but many consider it bad form to do so precisely because the TXT > RR one gets back may have nothing to do with the usage the client is > expecting. No DNS zone file maintainer is expected to start using APL RRs based on this ID alone. Maybe the document should emphasize this, although the text you quoted should exactly do that. The TXT RR case is different, because the specification more or less said "do with it whatever you like", while the ID doesn't. > 1) This document should be published at all, without a specific usage > associated with it for the reasons discussed above. The intent was to decouple the RR application specification from the syntax specification (somehow similar to SRV), because different applications (e.g. AXFR control and CIDR block documentation, see section 8) may or may not evolve differently and I still think it eases the process if they are not tied together more than necessary. You cannot build any application with this ID alone, but support for the APL RR can be built into DNS software with this specification, which is a base requirement for those applications to work. > 2) Even if the document is published, making it a PS seems wrong, > without a specific usage documented along with it that clearly > defines the semantics and intended usage. The standards track was chosen to give any application scenario making use of the APL RR to be standards track itself - having the SRV experience in mind. Does the IESG prefer 'experimental'? > > The RDATA section consists of zero or more strings () of > > the form > > Is the "string" description correct? The RDATA actually consists if > fixed length fields such as a prefix, a bit, etc. The word "string" here originates from the textual representation, which consists of multiple strings of the form e.g. "1:127.0.0.1/32". It may not be the best choice in the RDATA context, but the I tried to avoid the word "record", which is probably more appropriate. Comments? > > ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers. > > The IANA requests that all references to numbers be via: > > http://www.iana.org/numbers.html Thanks for that URL. This particular part of the document already has some history, including IANA contact, so I'll again change this ``moving target''. -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Nov 12 00:09:39 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10628 for ; Sun, 12 Nov 2000 00:09:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13uou3-0006fs-00 for namedroppers-data@psg.com; Sat, 11 Nov 2000 20:38:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13uou3-0006fm-00 for namedroppers@ops.ietf.org; Sat, 11 Nov 2000 20:38:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13uou3-000Lmn-00 for namedroppers@ops.ietf.org; Sat, 11 Nov 2000 20:38:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200011111700.SAA16187@grimsvotn.TechFak.Uni-Bielefeld.DE> From: Paul Vixie Date: 11 Nov 2000 20:36:45 -0800 In-Reply-To: Peter Koch's message of "11 Nov 2000 20:29:19 -0800" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> The specification of particular application scenarios is out of the >>> scope of this document. >> >> I.e, this ID defines an RR for which no usage has been specified, and >> for which in the future, multiple incompatable usages might be >> specified. well, i'll say that i have a widely deployed application which depends on being able to enforce AXFR access control in slaves, using an access control list which can be dynamically changed by the zone owner. speaking as an implementor (bind8 isn't YET fully irrelevant, i think), i can say that i'll be adding this functionality in the near term, and i'd much rather do it using APL RR's than TXT RR's. (either way i'll try to get it to be an approved standard rather than a local hack, of course. but APL is cleaner.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Nov 12 18:52:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15726 for ; Sun, 12 Nov 2000 18:52:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13v6Ki-000810-00 for namedroppers-data@psg.com; Sun, 12 Nov 2000 15:14:44 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13v6Ki-00080u-00 for namedroppers@ops.ietf.org; Sun, 12 Nov 2000 15:14:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13v6Ki-0004sM-00 for namedroppers@ops.ietf.org; Sun, 12 Nov 2000 15:14:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001112225951.0203a0b8@127.0.0.1> Date: Sun, 12 Nov 2000 23:04:22 +0100 To: Peter Koch , Thomas Narten From: Harald Alvestrand Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: IETF DNSEXT WG In-Reply-To: <200011111700.SAA16187@grimsvotn.TechFak.Uni-Bielefeld.DE> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 17:59 11/11/2000 +0100, Peter Koch wrote: >The standards track was chosen to give any application scenario making use of >the APL RR to be standards track itself - having the SRV experience in mind. >Does the IESG prefer 'experimental'? I am not on the IESG now, so can't speak authoritatively, but the IESG of my day preferred to have experiments labelled "experimental". The SRV experience (apart from the problem of the delay) actually proved benefical in this case - the spec was changed based on experience. Of course, if there is an application ready to go standards track that depends on this spec, standards track is the only way to go. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 14 08:05:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08601 for ; Tue, 14 Nov 2000 08:05:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13vfEi-0008sP-00 for namedroppers-data@psg.com; Tue, 14 Nov 2000 04:30:52 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13vfEh-0008sI-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 04:30:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13vfEh-000N7j-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 04:30:51 -0800 Message-Id: <200011141143.GAA08925@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-01.txt Date: Tue, 14 Nov 2000 06:43:04 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-01.txt Pages : 6 Date : 13-Nov-00 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001113134533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134533.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 14 08:12:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11219 for ; Tue, 14 Nov 2000 08:12:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13vfEn-0008sd-00 for namedroppers-data@psg.com; Tue, 14 Nov 2000 04:30:57 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13vfEn-0008sW-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 04:30:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13vfEn-000N7t-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 04:30:57 -0800 Message-Id: <200011141143.GAA08980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-unknown-rrs-00.txt Date: Tue, 14 Nov 2000 06:43:08 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Handling of Unknown DNS RR Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-00.txt Pages : 6 Date : 13-Nov-00 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-unknown-rrs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001113134542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134542.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 14 15:31:17 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22024 for ; Tue, 14 Nov 2000 15:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13vllc-000G6R-00 for namedroppers-data@psg.com; Tue, 14 Nov 2000 11:29:16 -0800 Received: from adsl-63-206-97-82.dsl.snfc21.pacbell.net ([63.206.97.82] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13vllb-000G6L-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 11:29:16 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13vlla-0000Cg-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 11:29:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200011141517.HAA52352@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: as a matter of fact, i mostly agree Date: Tue, 14 Nov 2000 07:17:22 -0800 From: Paul A Vixie X-DCC-MAPS-Metrics: isrv3.isc.org 666; IP=0/40 env_From=0/38 From=0/35 Subject=0/1 Message-Id=0/1 Received=0/1 Body=0/1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://gsa.secret.org/i18n/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 14 15:49:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27827 for ; Tue, 14 Nov 2000 15:49:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13vmPs-000HGd-00 for namedroppers-data@psg.com; Tue, 14 Nov 2000 12:10:52 -0800 Received: from adsl-63-206-97-82.dsl.snfc21.pacbell.net ([63.206.97.82] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13vmPr-000HGW-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 12:10:51 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13vmPq-0000Ex-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 12:10:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200011141828.TAA25875@rom.antech.de> From: "Stefan Kelm" Organization: Secorvo Security Consulting GmbH To: lewis@tislabs.com, DNSEXT WG Mailing list Date: Tue, 14 Nov 2000 19:38:59 +0100 Subject: Re: CERT records In-reply-to: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed, > Refering to RFC 2538, is it worth proposing a new "certificate type value" > for a PKIX X509 CRL? > > There is a value (1) for X509 PKIX certificates. It could be argued that > this value should be used for CRLs. > > The reason I am floating this is because of a decidedly non-protocol issue. > In Java there are classes for X509Certificate and X509CRL. Becuase of the > language's inheritence model [1], the two cannot be treated as the other > safely. Ergo, when I get bits from DNS, I have to know ahead of time > whether the bits are a Certificate or a CRL[2]. Knowing ahead of time > could be made easy through a new certificate type value. this makes a lot of sense, esp. since CRLs tend to grow very large in real-life environments. However, we need to be careful to avoid ambiguities since RFC 2538 allows for both certificates and CRLs to be carried inside a CERT RR. So, someone who implements only RFC 2538 might not be able to check a new CRL RR. Maybe an OID could indeed be used. Cheers, Stefan. ------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm@secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 14 19:41:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22860 for ; Tue, 14 Nov 2000 19:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13vq70-000PFo-00 for namedroppers-data@psg.com; Tue, 14 Nov 2000 16:07:38 -0800 Received: from [12.22.55.88] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13vq70-000PFi-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 16:07:38 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13vq70-0000Ke-00 for namedroppers@ops.ietf.org; Tue, 14 Nov 2000 16:07:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001114232405.02fedef0@127.0.0.1> Date: Tue, 14 Nov 2000 23:27:04 +0100 To: Paul A Vixie , namedroppers@ops.ietf.org From: Harald Alvestrand Subject: Re: as a matter of fact, i mostly agree In-Reply-To: <200011141517.HAA52352@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 07:17 14/11/2000 -0800, Paul A Vixie wrote: >http://gsa.secret.org/i18n/ one note: the only root name server touched by NSI's experiment is A; the names go into .com .net .org (if they get that far). any suggestions for alleviating the pain are welcome at the IDN group. (I believe that the initial deployment using ACE will prove nondamaging to those entities that know nothing about them; the pain will only begin when devices start interpreting these strings....badly.) Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 20 10:58:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13811 for ; Mon, 20 Nov 2000 10:58:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13xsWG-000Nfv-00 for namedroppers-data@psg.com; Mon, 20 Nov 2000 07:06:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13xsWF-000Nfp-00 for namedroppers@ops.ietf.org; Mon, 20 Nov 2000 07:06:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13xsWF-0007lf-00 for namedroppers@ops.ietf.org; Mon, 20 Nov 2000 07:06:07 -0800 Message-Id: <200011201114.GAA04407@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-edns0dot5-02.txt Date: Mon, 20 Nov 2000 06:14:06 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A Proposed Enhancement to the EDNS0 Version Mechanism Author(s) : R. Austein, H. Alvestrand Filename : draft-ietf-dnsext-edns0dot5-02.txt Pages : 6 Date : 17-Nov-00 EDNS0 [EDNS0] specifies a general framework for extending the packet format used by the Domain Name System protocols. The framework includes a simple version numbering scheme to allow the parties in a DNS protocol exchange to determine which extension features the other party understands. While having the advantage of simplicity, the version numbering scheme as specified has drawbacks: - It provides no way to deprecate a protocol feature; - It provides no way to deploy experimental protocol features. This note proposes to replace the monolithic version numbering mechanism with a mechanism for listing an explicit set of protocol features that a particular implementation supports. We retain version numbering as a way of abbreviating the feature sets that we expect to see in common use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-edns0dot5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001117145012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns0dot5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145012.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 20 11:00:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14086 for ; Mon, 20 Nov 2000 11:00:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13xsWN-000NgA-00 for namedroppers-data@psg.com; Mon, 20 Nov 2000 07:06:15 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13xsWN-000Ng4-00 for namedroppers@ops.ietf.org; Mon, 20 Nov 2000 07:06:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13xsWN-0007ll-00 for namedroppers@ops.ietf.org; Mon, 20 Nov 2000 07:06:15 -0800 Message-Id: <200011201114.GAA04423@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-00.txt Date: Mon, 20 Nov 2000 06:14:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Multicast DNS Author(s) : L. Esibov, B. Aboba Filename : draft-ietf-dnsext-mdns-00.txt Pages : 9 Date : 17-Nov-00 Today, with the rise of home networking, there are an increasing number of small networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001117145033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145033.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 21 16:59:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12098 for ; Tue, 21 Nov 2000 16:59:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13yKpT-000LB3-00 for namedroppers-data@psg.com; Tue, 21 Nov 2000 13:19:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13yKpT-000LAw-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 13:19:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13yKpS-000KQp-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 13:19:50 -0800 Message-Id: <4.3.2.7.2.20001121144131.00c219a0@localhost> Date: Tue, 21 Nov 2000 14:41:48 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Fwd: I-D ACTION:draft-msawyer-dnsext-edns-attributes-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To: IETF-Announce:;;@tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-msawyer-dnsext-edns-attributes-00.txt Date: Tue, 21 Nov 2000 05:54:38 -0500 Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Handling of unknown EDNS0 attributes Author(s) : M. Sawyer, A. Gustafsson, M. Graff Filename : draft-msawyer-dnsext-edns-attributes-00.txt Pages : 5 Date : 20-Nov-00 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 21 16:59:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12109 for ; Tue, 21 Nov 2000 16:59:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13yKp5-000LAJ-00 for namedroppers-data@psg.com; Tue, 21 Nov 2000 13:19:27 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13yKp4-000LAD-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 13:19:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13yKp4-000KQS-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 13:19:26 -0800 Message-Id: <4.3.2.7.2.20001121144131.00dfed40@localhost> Date: Tue, 21 Nov 2000 14:41:44 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Fwd: I-D ACTION:draft-kosters-dnsext-dnssec-opt-in-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To: IETF-Announce:;;@tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kosters-dnsext-dnssec-opt-in-00.txt Date: Tue, 21 Nov 2000 05:54:01 -0500 Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNSSEC Opt-in for Large Zones Author(s) : M. Kosters Filename : draft-kosters-dnsext-dnssec-opt-in-00.txt Pages : 8 Date : 20-Nov-00 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 21 19:56:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05685 for ; Tue, 21 Nov 2000 19:56:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13yNo6-000Pvx-00 for namedroppers-data@psg.com; Tue, 21 Nov 2000 16:30:38 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13yNo5-000Pvr-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 16:30:37 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13yNo5-000Lov-00 for namedroppers@ops.ietf.org; Tue, 21 Nov 2000 16:30:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200011220022.eAM0Mrk16682@sh.lh.vix.com> To: namedroppers@ops.ietf.org Subject: DNSSEC Opt In Date: Tue, 21 Nov 2000 16:22:53 -0800 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I had a talk with Mark about the draft, and came to the following point that I wanted to bring to the group for discussion. Mark's premise is that the NS list for the secure and non-secure zones is the same and that "magic happens" in some way to separate the secure and non-secure queries (we discussed several implementation options for this.) I think that we could look at changing the NS list sets to be explicit. If there were separate NS lists for with opt DO and without, then there ther is no need for the "magic happens" part of the process. It would mean having some way of telling a resolver which opts are covered by this NS set when passing the glue back. There is nothing that requires running a zone as opt-in, so we can punt doing this for the root. It does bring up a problem. If this is a precedent for deploying other complex options to DNS, they you get into the combinatorial problem of NS sets. I believe this is a problem of either the implicit or explicit flavors of this solution, but it is more clear in the explicit case. Without having some answer for the combinatorial options problem, this becomes a one time bullet. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 22 09:40:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29767 for ; Wed, 22 Nov 2000 09:40:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13yaXZ-000HUA-00 for namedroppers-data@psg.com; Wed, 22 Nov 2000 06:06:25 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13yaXY-000HTw-01 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 06:06:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13yaNC-000Cs0-00 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 05:55:42 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 13yXgS-000EXr-00 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 03:03:24 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19482; Wed, 22 Nov 2000 06:03:20 -0500 (EST) Message-Id: <200011221103.GAA19482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2782bis-00.txt Date: Wed, 22 Nov 2000 06:03:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for specifying the location of services (DNS SRV) Author(s) : A. Gulbrandsen, P. Vixie, L. Esibov Filename : draft-ietf-dnsext-rfc2782bis-00.txt Pages : 12 Date : 21-Nov-00 This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2782bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2782bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121110730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2782bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2782bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121110730.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 22 09:41:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00183 for ; Wed, 22 Nov 2000 09:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13yaXc-000HUH-00 for namedroppers-data@psg.com; Wed, 22 Nov 2000 06:06:28 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13yaXY-000HTw-00 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 06:06:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13yaNG-000Ct5-00 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 05:55:46 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 13yXgX-000EY1-00 for namedroppers@ops.ietf.org; Wed, 22 Nov 2000 03:03:29 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19512; Wed, 22 Nov 2000 06:03:26 -0500 (EST) Message-Id: <200011221103.GAA19512@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ad-is-secure-00.txt Date: Wed, 22 Nov 2000 06:03:25 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-00.txt Pages : 4 Date : 21-Nov-00 Based on implementation experience, the current definition of the AD bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121110744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121110744.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 23 06:08:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08154 for ; Thu, 23 Nov 2000 06:08:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13ytas-000Fmh-00 for namedroppers-data@psg.com; Thu, 23 Nov 2000 02:27:06 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13ytar-000FmZ-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 02:27:06 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13ytak-0001Ih-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 02:26:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001122170920.00be99c0@localhost> Date: Wed, 22 Nov 2000 20:38:42 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Re: Fwd: draft-ietf-dnsext-apl-rr-01.txt In-Reply-To: <4.3.2.7.2.20001030221024.00bed530@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:23 PM 10/30/00, Olafur Gudmundsson wrote: >As there has been no reaction (one way or the other) to the message >below, is it safe to assume that the members of this working group >do not care if this document is withdrawn from consideration as it has >no practical use defined ? > > Olafur > >PS: if there is no reaction to this message, in the next 7 days. >Randy and I will interpret that as "YES Withdraw the document". Based on Working Group Feedback the appropriate disposition of this ID is to forward it as "Experimental". This allows the record type to be defined and uses invented, if this turns out to be a useful record type the WG has the option of moving this document back on the standards track. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 23 13:48:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00174 for ; Thu, 23 Nov 2000 13:48:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13z0tz-000MaJ-00 for namedroppers-data@psg.com; Thu, 23 Nov 2000 10:15:19 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13z0ty-000MaC-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 10:15:18 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13z0u5-0001P5-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 10:15:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Nov 2000 15:48:16 +0100 Message-Id: <200011231448.eANEmG003807@dolk.extundo.com> To: namedroppers@ops.ietf.org Subject: CERT records again References: From: Simon Josefsson In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to know if there are any interest in adding new CERT types for S/MIME, WAP TLS and/or other PKIX-derived certificate formats. One argument is that the "PKIX" certificate type is very general. Several certificate flavours are based on PKIX, and more are likely to be defined in the future. S/MIME and WAP TLS certificates are the two I've been working with. This suggest that the number of certificates attached to a specific domain name will grow once more flavours gain acceptance -- and clients will 1) waste bandwidth by retrieving all PKIX certificates for a domain, and 2) waste time to parse through all certificates to find a S/MIME, WAP TLS etc certificate. this would cause quite some complexity in a client. Another argument for this is that there are several MIME types defined for various PKIX derived certificates. `application/x-x509-user-cert' and `application/vnd.wap.wtls-user-cert' are two. Also, S/MIME certificates may be transfered under the `application/pkcs7-mime' type. I'm not sure how good this argument is, a comparison between MIME types and CERT types might be flawed. Thanks in advance to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 23 13:49:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00265 for ; Thu, 23 Nov 2000 13:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13z0yH-000Mep-00 for namedroppers-data@psg.com; Thu, 23 Nov 2000 10:19:45 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13z0yG-000Meh-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 10:19:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13z0yO-0001PW-00 for namedroppers@ops.ietf.org; Thu, 23 Nov 2000 10:19:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Nov 2000 15:56:40 +0100 Message-Id: <200011231456.eANEue003858@dolk.extundo.com> To: namedroppers@ops.ietf.org Subject: applications using CERT? From: Simon Josefsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As a personal interest, is anyone aware of a list of applications that use CERT RR's in some way? Especially, are there any S/MIME compliant mailers with support for fetching S/MIME certificates from DNS? Of course, I'd like to know if Gnus http://www.gnus.org/ is the first one, since I've been adding support for S/MIME and certificate lookups from DNS to it. Thanks again. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 24 09:41:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27403 for ; Fri, 24 Nov 2000 09:41:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13zJQt-000KkI-00 for namedroppers-data@psg.com; Fri, 24 Nov 2000 06:02:31 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13zJQs-000KkC-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 06:02:30 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13zJR9-0001md-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 06:02:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001124133619.059afcf0@127.0.0.1> Date: Fri, 24 Nov 2000 13:39:10 +0100 To: Simon Josefsson , namedroppers@ops.ietf.org From: Harald Alvestrand Subject: Re: CERT records again In-Reply-To: <200011231448.eANEmG003807@dolk.extundo.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 15:48 23/11/2000 +0100, Simon Josefsson wrote: >One argument is that the "PKIX" certificate type is very general. >Several certificate flavours are based on PKIX, and more are likely to >be defined in the future. S/MIME and WAP TLS certificates are the two >I've been working with. This suggest that the number of certificates >attached to a specific domain name will grow once more flavours gain >acceptance -- and clients will > > 1) waste bandwidth by retrieving all PKIX certificates for a >domain, and > > 2) waste time to parse through all certificates to find a >S/MIME, WAP TLS etc certificate. > >this would cause quite some complexity in a client. one answer is to define new RR types for each type of cert. This is highly inflexible. another answer is to define _ domains - find the S/MIME cert of harald@alvestrand.no under _smime.harald.alvestrand.no, for instance. this is doable, but will double the domaincount *again*. a third answer is to define the URL RR, and put a pointer to the relevant LDAP directory entry in it, where new types are a lot cheaper than in the DNS. no lack of answers. lack of clue about picking one (and lack of clue-by-4 to make the pick stick). -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 24 12:54:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11733 for ; Fri, 24 Nov 2000 12:54:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13zMag-000PDj-00 for namedroppers-data@psg.com; Fri, 24 Nov 2000 09:24:50 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13zMaf-000PDc-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 09:24:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13zMb2-0001ok-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 09:25:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.2.7.2.20001124133619.059afcf0@127.0.0.1> References: <4.3.2.7.2.20001124133619.059afcf0@127.0.0.1> Date: Fri, 24 Nov 2000 15:41:25 +0100 To: Harald Alvestrand , Simon Josefsson , namedroppers@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: CERT records again Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 13.39 +0100 00-11-24, Harald Alvestrand wrote: >a third answer is to define the URL RR, and put a pointer to the relevant >LDAP directory entry in it, where new types are a lot cheaper than in the DNS. Or (re-)use NAPTR for this, as NAPTR rewrites can result in URI's (one example is RFC 2916). paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 24 18:58:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01372 for ; Fri, 24 Nov 2000 18:58:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13zSAN-000CYZ-00 for namedroppers-data@psg.com; Fri, 24 Nov 2000 15:22:03 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13zSAL-000CYS-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 15:22:01 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13zSAl-0001sz-00 for namedroppers@ops.ietf.org; Fri, 24 Nov 2000 15:22:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200011231448.eANEmG003807@dolk.extundo.com> References: Date: Fri, 24 Nov 2000 13:31:09 -0500 To: Simon Josefsson From: Edward Lewis Subject: Re: CERT records again Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 9:48 AM -0500 11/23/00, Simon Josefsson wrote: > 1) waste bandwidth by retrieving all PKIX certificates for a >domain, and Not to dispute the desire for more CERT type-value definitions, but defining different values wouldn't reduce the bandwidth - all things being equal. E.g.: owner.domain.name CERT PKIX-1 <> ; yes, I omitted the key args CERT PKIX-1 <> CERT PKIX-2 <> Even if I just wanted PKIX-2 (e.g. WAP TLS) I would be getting all three. The different numbers fo make it easier to throw away the two unwanted (PKIX-1) CERTs though. To cut down on the bandwidth you could do this: pkix-1.owner.domainname CERT PKIX-1 <> ; again, omitting key args CERT PKIX-1 <> pkix-2.owner.domainname CERT PKIX-2 <> In the latter case you'd get just the one desired - saving bandwidth at the cost of more domain names (more an issuer for the client than the server). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 27 13:46:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24125 for ; Mon, 27 Nov 2000 13:46:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 140SJv-0009Cs-00 for namedroppers-data@psg.com; Mon, 27 Nov 2000 09:44:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 140SJu-0009Cl-00 for namedroppers@ops.ietf.org; Mon, 27 Nov 2000 09:44:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 140SJu-000Fmn-00 for namedroppers@ops.ietf.org; Mon, 27 Nov 2000 09:44:02 -0800 Message-Id: <4.3.2.7.2.20001127113123.00dfa790@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Nov 2000 11:32:39 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Agenda Items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would like to submit the agenda for the WG meeting on Wednesday so please send in requests if you have not done so yet. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 28 20:02:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20063 for ; Tue, 28 Nov 2000 20:02:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 140v4v-000EGU-00 for namedroppers-data@psg.com; Tue, 28 Nov 2000 16:26:29 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 140v4v-000EFK-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:26:29 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 140v5j-0003Dk-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:27:19 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.16 #1) id 140uKJ-000DPG-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 15:38:19 -0800 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07643; Tue, 28 Nov 2000 15:38:01 -0800 (PST) Message-Id: <200011282338.PAA07643@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3007 on Secure Dynamic Update Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Nov 2000 15:38:01 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3007 Title: Secure Domain Name System (DNS) Dynamic Update Author(s): B. Wellington Status: Standards Track Date: November 2000 Mailbox: Brian.Wellington@nominum.com Pages: 9 Characters: 18056 Updates: 2137 Obsoletes: 2535, 2136 I-D Tag: draft-ietf-dnsext-simple-secure-update-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3007.txt This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001128153554.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3007 --OtherAccess Content-Type: Message/External-body; name="rfc3007.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001128153554.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 28 20:02:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20207 for ; Tue, 28 Nov 2000 20:02:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 140v59-000EGj-00 for namedroppers-data@psg.com; Tue, 28 Nov 2000 16:26:43 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 140v58-000EG4-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:26:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 140v5v-0003Dm-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:27:31 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.16 #1) id 140uMD-000DRu-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 15:40:17 -0800 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA08045; Tue, 28 Nov 2000 15:40:16 -0800 (PST) Message-Id: <200011282340.PAA08045@boreas.isi.edu> To: rfc-dist@ISI.EDU Subject: RFC 3008 on DNSSEC Signing Authority Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Nov 2000 15:40:16 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3008 Title: Domain Name System Security (DNSSEC) Signing Authority Author(s): B. Wellington Status: Standards Track Date: November 2000 Mailbox: Brian.Wellington@nominum.com Pages: 7 Characters: 13484 Updates: 2535 I-D Tag: draft-ietf-dnsext-signing-auth-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3008.txt This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001128153821.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3008 --OtherAccess Content-Type: Message/External-body; name="rfc3008.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001128153821.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 28 20:05:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21044 for ; Tue, 28 Nov 2000 20:05:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 140v4n-000EGN-00 for namedroppers-data@psg.com; Tue, 28 Nov 2000 16:26:21 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 140v4m-000EER-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:26:20 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 140v5a-0003Di-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:27:10 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.16 #1) id 140uK1-000DO4-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 15:38:01 -0800 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07625; Tue, 28 Nov 2000 15:37:59 -0800 (PST) Message-Id: <200011282337.PAA07625@boreas.isi.edu> To: rfc-dist@ISI.EDU Subject: RFC 3007 on Secure Dynamic Update Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Nov 2000 15:37:59 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3007 Title: Secure Domain Name System (DNS) Dynamic Update Author(s): B. Wellington Status: Standards Track Date: November 2000 Mailbox: Brian.Wellington@nominum.com Pages: 9 Characters: 18056 Updates: 2137 Obsoletes: 2535, 2136 I-D Tag: draft-ietf-dnsext-simple-secure-update-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3007.txt This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001128153554.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3007 --OtherAccess Content-Type: Message/External-body; name="rfc3007.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001128153554.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 28 20:08:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22260 for ; Tue, 28 Nov 2000 20:08:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 140v5C-000EH2-00 for namedroppers-data@psg.com; Tue, 28 Nov 2000 16:26:46 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 140v5B-000EGA-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:26:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 140v5y-0003Do-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 16:27:34 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.16 #1) id 140uME-000DS0-00 for namedroppers@ops.ietf.org; Tue, 28 Nov 2000 15:40:18 -0800 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA08029; Tue, 28 Nov 2000 15:40:13 -0800 (PST) Message-Id: <200011282340.PAA08029@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3008 on DNSSEC Signing Authority Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Nov 2000 15:40:12 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3008 Title: Domain Name System Security (DNSSEC) Signing Authority Author(s): B. Wellington Status: Standards Track Date: November 2000 Mailbox: Brian.Wellington@nominum.com Pages: 7 Characters: 13484 Updates: 2535 I-D Tag: draft-ietf-dnsext-signing-auth-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3008.txt This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001128153821.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3008 --OtherAccess Content-Type: Message/External-body; name="rfc3008.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001128153821.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 09:59:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24448 for ; Wed, 29 Nov 2000 09:59:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1417xo-0000Dj-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 06:12:00 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1417xm-0000DA-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 06:11:59 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1417yb-0003Kz-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 06:12:49 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 1415OK-000OCV-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 03:27:13 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29503; Wed, 29 Nov 2000 06:27:11 -0500 (EST) Message-Id: <200011291127.GAA29503@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-okbit-01.txt Date: Wed, 29 Nov 2000 06:27:10 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Indicating Resolver Support of DNSSEC Author(s) : D. Conrad Filename : draft-ietf-dnsext-dnssec-okbit-01.txt Pages : 5 Date : 28-Nov-00 In order to deploy DNSSEC operationally, DNSSEC aware servers should only respond with DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and the necessary protocol changes to implement that notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-okbit-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128133523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-okbit-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133523.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 10:01:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25273 for ; Wed, 29 Nov 2000 10:01:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1417xd-0000DU-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 06:11:49 -0800 Received: from fwgw.boaw.cust.55cc.tor.boaw.net ([216.94.86.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1417xa-0000Ct-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 06:11:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1417yU-0003Kx-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 06:12:42 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 1415OH-000OCM-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 03:27:09 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29458; Wed, 29 Nov 2000 06:27:06 -0500 (EST) Message-Id: <200011291127.GAA29458@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-gss-tsig-01.txt Date: Wed, 29 Nov 2000 06:27:06 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : GSS Algorithm for TSIG (GSS-TSIG) Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov Filename : draft-ietf-dnsext-gss-tsig-01.txt Pages : 20 Date : 28-Nov-00 The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-gss-tsig-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128133514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-gss-tsig-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133514.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 16:58:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25458 for ; Wed, 29 Nov 2000 16:58:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Eif-0007pC-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:24:49 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Eie-0007oi-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:24:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Ejn-0003QD-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:25:59 -0800 Date: Wed, 29 Nov 2000 09:23:27 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Request to change Wednesday 15:30-17:30 from frnetmib to ipo To: Rob Coltun Cc: "Andrew G. Malis" , agenda@ietf.org, David Oran , Thomas Narten , Erik Nordmark , iesg-secretary@ietf.org, Daniel Awduche , "James V. Luciani" , new group In-Reply-To: "Your message with ID" <3A24DE7B.A69EC3B4@redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Need to check with the rest of the team (because the new new pseudo area). > Is everyone OK with the change? OK with me. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:03:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27714 for ; Wed, 29 Nov 2000 17:03:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Ex8-0008Ne-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:39:46 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Ex7-0008NU-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:39:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Eyb-0003Ql-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:41:17 -0800 Message-Id: <4.3.2.7.2.20001129113521.0338f460@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:29:15 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: EDNS0.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document proposes a more fine grain feature description mechanism than EDNS0 allows. Under this schema new features can be advertised in an standard way in regular ENDS0 message. There is need to be able to introduce new features and remove old ones and this protocol extension proposes a way to accomplish that. This WG last call ends December 17'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:07:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28938 for ; Wed, 29 Nov 2000 17:07:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Ex4-0008NS-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:39:42 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Ex2-0008NL-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:39:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141EyT-0003Qj-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:41:09 -0800 Message-Id: <4.3.2.7.2.20001129113611.00dcdf00@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:17:58 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: Message Size Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a DNSEXT WG last call on this document, please send your comments to mailto:namedroppers@ops.ietf.org This document updates RFC2535 and RFC2874 (A6) to demand larger UDP message size than 512 bytes. This document mandates that any entity supporting either DNSSEC or A6 records must support EDNS0 on queries and responses. The motivation(s) for this is the increase in size of DNS answers caused by DNSSEC, IPng, TSIG and large the desire for large answer sets. The document assumes that modern operating systems can do UDP reassembly, thus this the single UDP message requirement can be relaxed and this is less costly than falling back on TCP for all large answers. This WG last call ends December 17'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:07:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29237 for ; Wed, 29 Nov 2000 17:07:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141ExH-0008Nr-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:39:55 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141ExG-0008Nl-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:39:55 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Eyk-0003Qn-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:41:26 -0800 Message-Id: <4.3.2.7.2.20001129113254.033a0c60@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:30:37 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: Zone Status Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document clarifies/updates certain sections of RFC2535 and defines the security status of a zone and what factors affect the zone security status. This document declares that only zones signed with Mandatory to implement algorithms can be fully secure. The document eliminates the experimental status of certain zones. The document proposes terminology to use when describing zone security status. This document expresses rules for zones that want to be considered secure from the protocol perspective. This document references 2 ID's but both are now RFC's. This WG last call ends December 17'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-03.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:11:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00754 for ; Wed, 29 Nov 2000 17:11:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141F66-0008og-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:49:02 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141F65-0008oZ-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:49:01 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141F7X-0003R5-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:50:31 -0800 Message-Id: <4.3.2.7.2.20001129150924.00d3a7d0@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 15:09:32 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Re: WG Last Call: RFC2137 to Historic (SUMMARY) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:59 PM 8/9/00, you wrote: >As we have a new specification that obsoletes RFC2137 (Secure Dynamic Update). > >This last call is to solicit opinion of the WG if RFC2137 status >should be changed from "Obsoleted by RFC2xxx" to "Historic". > >The reason for doing this is to make it real clear to anyone that RFC2137 >is NOT to be implemented. > >This WG last call ends on August 25'th. There is no consensus that this is needed as the Obsoleted by RFC3007 clause is supposed to be sufficient. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:14:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01469 for ; Wed, 29 Nov 2000 17:14:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141EyB-0008Ps-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:40:51 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141EyA-0008Pj-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:40:50 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Eze-0003Qq-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:42:22 -0800 Message-Id: <4.3.2.7.2.20001129141118.00b65340@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:26:15 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG LAst Call: Dnssec OK bit. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document defines a EDNS flag for a resolver to signal to DNS server that it wants to receive DNSSEC records. In the absence of this flag servers should not send DNSSEC records unless the query for that type. This document updates RFC2535 and RFC2671. This WG last call ends December 17'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:19:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03040 for ; Wed, 29 Nov 2000 17:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141F60-0008oO-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:48:56 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141F5z-0008oC-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:48:56 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141F7R-0003R3-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:50:25 -0800 Message-Id: <4.3.2.7.2.20001129143708.00ca6d40@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 14:49:51 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WGLC summary: RSA-SHA1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This last call has completed. The working group consensus is to approve the document as is and forward it to the IESG. During the last call comment period no major issues where raised, one person objected to the Obsoleting of RSA/MD5. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 29 17:25:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04931 for ; Wed, 29 Nov 2000 17:25:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141F5m-0008o0-00 for namedroppers-data@psg.com; Wed, 29 Nov 2000 13:48:42 -0800 Received: from mg-20425422-107.ricochet.net ([204.254.22.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141F5l-0008nf-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:48:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141F7B-0003R1-00 for namedroppers@ops.ietf.org; Wed, 29 Nov 2000 13:50:09 -0800 Message-Id: <4.3.2.7.2.20001129145014.00d4ae20@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 15:02:58 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WGLC: RFC1611 and RFC1612 to historic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is DNSEXT working group last call. Implementation experience (and lack there of) has shown this specification to be not useful thus these documents are being retired. This WG last call ends December 31'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt If you object to this designation please say so. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 07:59:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20670 for ; Thu, 30 Nov 2000 07:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141SuE-000Oog-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 04:33:42 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Su6-000Oo7-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:33:38 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141SvT-0003cA-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:34:59 -0800 Received: (qmail 24189 invoked by uid 1001); 30 Nov 2000 08:30:36 -0000 Date: 30 Nov 2000 08:30:36 -0000 Message-ID: <20001130083036.24631.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: djb-boo@muncher.math.uic.edu Subject: Re: DNSEXT WG Last Call: Message Size References: <4.3.2.7.2.20001129113611.00dcdf00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I object to this document, for several reasons: * Sections 1.2 and 1.3 are silly. Normal A6 responses don't overflow a 512-byte UDP packet. Root servers don't need IPv6 addresses. The claimed 13-server limit for UDP packets can be shattered with no protocol changes. * It's a layering violation to say ``MUST use EDNS0'' when you mean ``MUST use a protocol that handles 1024-byte packets efficiently.'' Why shouldn't we use DNS over, for example, an improved version of T/TCP that can handle 1024-byte packets as efficiently as UDP? * The underlying efficiency argument is bogus. The document claims without justification that requiring TCP ``will cause significant overhead and delays.'' In fact, unless there are _frequent_ TCP packets, the extra load from those packets is a negligible portion of DNS load, not to mention total load. Does anyone have logs showing a noticeable number of TCP retries? What was the actual server load, and what difference did TCP make? What are some examples of the responses that forced TCP retries? ---Dan P.S. I would like to receive Cc's of all further messages on this topic, for reasons explained in http://cr.yp.to/djbdns/namedroppers.html. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 07:59:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20671 for ; Thu, 30 Nov 2000 07:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141SgZ-000Obg-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 04:19:35 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141SgX-000Oba-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:19:34 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Si8-0003aj-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:21:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Olafur Gudmundsson cc: DNSEXT WG Mailing list In-reply-to: ogud's message of Wed, 29 Nov 2000 14:17:58 EST. <4.3.2.7.2.20001129113611.00dcdf00@localhost> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DNSEXT WG Last Call: Message Size From: itojun@iijlab.net Date: Thu, 30 Nov 2000 10:42:12 +0900 Message-ID: <16207.975548532@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >This is a DNSEXT WG last call on this document, please send your comments >to mailto:namedroppers@ops.ietf.org > >This document updates RFC2535 and RFC2874 (A6) to demand larger >UDP message size than 512 bytes. This document mandates that any >entity supporting either DNSSEC or A6 records must support EDNS0 on queries >and responses. >The motivation(s) for this is the increase in size of DNS answers caused >by DNSSEC, IPng, TSIG and large the desire for large answer sets. >The document assumes that modern operating systems can do UDP reassembly, >thus this the single UDP message requirement can be relaxed and this is >less costly than falling back on TCP for all large answers. > >This WG last call ends December 17'th 2000. I have one comment to the draft. Isn't it necessary for us to document some recommendation on fragmentation? for example, addition of the following section would be better for readers... if it is out of scope of the document, i should come up with separate document (actually, this is not a DNS issue but IPv6 UDP issue). itojun Fragmentation and path MTU discovery Unlike IPv4, IPv6 mandates path MTU discovery. No packets will be fragmented en route. Therefore, for both servers and resolvers, large UDP queries/replies may not reach the peer. Intermediate routers will transmit ICMPv6 too big message in that case. There can be couple of implementation choices. (3) is the easiest but could be inefficient. (1) puts some assumption to operating system, can be slow on catch up to the new MTU (due to timeout), but is easy enough to implement. (2) should present the best behavior, but implementation could become too complex, specifically for server side. 1. Do nothing special, rely upon path MTU discovery. Send a large packet as is. If answer does not come back, retrnansmit the large packet again after retransmission timeout, assuming that the operating system has notified of smaller MTU and automatically fragment it. 2. Try to implement retransmission logic. When server/resolver receives ICMPv6 too big message, retransmit query/reply using the new path MTU. 3. Always fragment large UDP queries/replies to IPv6 minimum mtu (1280 octets according to RFC2460), to avoid path MTU discovery completely. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 08:00:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20919 for ; Thu, 30 Nov 2000 08:00:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Sj4-000Odz-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 04:22:10 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Sj2-000Ods-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:22:09 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Ske-0003b9-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:23:48 -0800 Message-ID: <3A25C330.2AEE3950@daimlerchrysler.com> Date: Wed, 29 Nov 2000 22:02:08 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: DNSEXT WG Mailing list Subject: Re: DNSEXT WG Last Call: EDNS0.5 References: <4.3.2.7.2.20001129113521.0338f460@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would prefer to see a more general mechanism in which both FEATURE codes and OPTION codes, for boolean OPTIONs, are included in the same sorted list: it seems a waste to have to specify such OPTIONs separately from FEATUREs when they are so similar in form and function. This would require the codes to be assigned in such a way as to preclude collisions between the two types of extension, and if it is deemed necessary to differentiate *unrecognized* FEATUREs from OPTIONs -- for example, if it is expected that implementations will log the receipt of an unrecognized code differently depending on whether it's a FEATURE or an OPTION code -- then the range could perhaps be segmented, e.g. 0-32767 FEATUREs, 32768-65535 OPTIONs, or _vice_versa_. Non-boolean OPTIONs (OPTION-LENGTH > 0) would have no place in this scheme and would continue to be specified separately. - Kevin Olafur Gudmundsson wrote: > This document proposes a more fine grain feature description mechanism > than EDNS0 allows. Under this schema new features can be advertised in > an standard way in regular ENDS0 message. > There is need to be able to introduce new features and remove old ones > and this protocol extension proposes a way to accomplish that. > > This WG last call ends December 17'th 2000. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt > > This draft is on standards track, if you disagree with that please state why > in your response. > > Olafur > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 08:02:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22133 for ; Thu, 30 Nov 2000 08:02:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Svz-000Oqm-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 04:35:31 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Svs-000Oq2-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:35:27 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141SxF-0003cH-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 04:36:49 -0800 Message-Id: <200011301051.FAA25231@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-not-existing-rr-01.txt Date: Thu, 30 Nov 2000 05:51:29 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-not-existing-rr-01.txt Pages : 17 Date : 29-Nov-00 This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by 'chaining' through a zone. It also remove delegation point concerns in NXT records. The document also describe hash truncation and record merging that reduces storage/network load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-not-existing-rr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129113937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-not-existing-rr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129113937.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 09:00:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13937 for ; Thu, 30 Nov 2000 09:00:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141TtV-00004E-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 05:37:01 -0800 Received: from [204.254.22.18] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141TtU-000047-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 05:37:00 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Tv2-0003fS-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 05:38:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org, djb-boo@muncher.math.uic.edu In-reply-to: djb's message of 30 Nov 2000 08:30:36 GMT. <20001130083036.24631.qmail@cr.yp.to> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DNSEXT WG Last Call: Message Size From: itojun@iijlab.net Date: Thu, 30 Nov 2000 22:25:10 +0900 Message-ID: <24977.975590710@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > * Sections 1.2 and 1.3 are silly. Normal A6 responses don't overflow > a 512-byte UDP packet. Root servers don't need IPv6 addresses. The > claimed 13-server limit for UDP packets can be shattered with no > protocol changes. While I agree that 512-byte UDP packet is good for normal A6 responses, I strongly disagree that root servers do not need IPv6 addresses. In the near future lots of IPv6-only networks will appear. How do you think they will contact root servers? itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 10:58:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04735 for ; Thu, 30 Nov 2000 10:58:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141VdF-00024E-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 07:28:21 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141VdE-000247-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 07:28:21 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Veb-0003iv-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 07:29:45 -0800 Message-Id: <4.3.2.7.2.20001130152756.05e90b98@127.0.0.1> Date: Thu, 30 Nov 2000 15:34:47 +0100 To: Kevin Darcy , DNSEXT WG Mailing list From: Harald Alvestrand Subject: Re: DNSEXT WG Last Call: EDNS0.5 In-Reply-To: <3A25C330.2AEE3950@daimlerchrysler.com> References: <4.3.2.7.2.20001129113521.0338f460@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 22:02 29/11/2000 -0500, Kevin Darcy wrote: >I would prefer to see a more general mechanism in which both FEATURE codes and >OPTION codes, for boolean OPTIONs, are included in the same sorted list: it >seems a waste to have to specify such OPTIONs separately from FEATUREs when >they are so similar in form and function. do we have examples of boolean OPTIONs? I would hesitate to jam them into the same mechanism if there is a chance that we might want to turn them off/on per query - the FEATURE mechanism was quite deliberately designed so that it was "relatively harmless" to signal a FEATURE you did not have any use for. This is a requirement in order to be able to subsume FEATURE lists into VERSIONs. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 11:04:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08111 for ; Thu, 30 Nov 2000 11:04:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141Vgh-00028a-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 07:31:55 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141Vgg-00028R-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 07:31:55 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141Vi9-0003jC-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 07:33:25 -0800 Date: Thu, 30 Nov 2000 09:41:27 -0500 From: Mark Kosters To: Olafur Gudmundsson Cc: DNSEXT WG Mailing list Subject: Re: DNSEXT WG LAst Call: Dnssec OK bit. Message-ID: <20001130094127.C4428@slam.admin.cto.netsol.com> References: <4.3.2.7.2.20001129141118.00b65340@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.2.20001129141118.00b65340@localhost>; from ogud@tislabs.com on Wed, Nov 29, 2000 at 02:26:15PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olafur On Wed, Nov 29, 2000 at 02:26:15PM -0500, Olafur Gudmundsson wrote: > This draft is on standards track, if you disagree with that please state why > in your response. I'm not sure I disagree but am curious for further rationale. In the latest version of this draft a part of section 3 was rewritten to say: # More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, # or NXT RRs to authenticate a response as specified in [RFC2535] # unless the DO bit was set on the request. Security records that match # an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data # for an AXFR or IXFR query, are included whether or not the DO bit was # set. Why is an ANY query listed along with SIG, KEY, and NXT? SIG, KEY, and NXT have explicit security context whereas ANY does not. To me, an ANY query is ambiguious at best should have the OK bit set for a RFC2535 response. Mark -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 30 12:46:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25563 for ; Thu, 30 Nov 2000 12:46:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141XG8-0004XS-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 09:12:36 -0800 Received: from mg-20425422-18.ricochet.net ([204.254.22.18] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141XG5-0004XM-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 09:12:34 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141XHR-0003pZ-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 09:13:57 -0800 Message-Id: <4.3.2.7.2.20001130120641.00d11c90@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Nov 2000 12:12:39 -0500 To: Mark Kosters From: Olafur Gudmundsson Subject: Re: DNSEXT WG LAst Call: Dnssec OK bit. Cc: DNSEXT WG Mailing list In-Reply-To: <20001130094127.C4428@slam.admin.cto.netsol.com> References: <4.3.2.7.2.20001129141118.00b65340@localhost> <4.3.2.7.2.20001129141118.00b65340@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:41 AM 11/30/00, Mark Kosters wrote: >Olafur > >On Wed, Nov 29, 2000 at 02:26:15PM -0500, Olafur Gudmundsson wrote: > > This draft is on standards track, if you disagree with that please > state why > > in your response. > >I'm not sure I disagree but am curious for further rationale. In the >latest version of this draft a part of section 3 was rewritten to say: Because draft updates RFC2535 it must be standards track unless there is a good reason other wise. ># More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, ># or NXT RRs to authenticate a response as specified in [RFC2535] ># unless the DO bit was set on the request. Security records that match ># an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data ># for an AXFR or IXFR query, are included whether or not the DO bit was ># set. > >Why is an ANY query listed along with SIG, KEY, and NXT? SIG, KEY, and NXT >have explicit security context whereas ANY does not. To me, an ANY query >is ambiguious at best should have the OK bit set for a RFC2535 response. Answering for David, (the editor without his permission) This is a clarification on what to do on an ANY query, sending S+N+K records back to an ANY query is the right thing to do as they are records stored at that name. The thrust of the draft is to say only do RFC2535 record additions when OK bit is set, but do not suppress the S+N+K records on explicit queries even if the OK bit is not there. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.