From owner-namedroppers@ops.ietf.org Sun Oct 1 10:56:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09119 for ; Sun, 1 Oct 2000 10:56:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13fk7V-0008mB-00 for namedroppers-data@psg.com; Sun, 01 Oct 2000 07:29:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13fk7V-0008m5-00 for namedroppers@ops.ietf.org; Sun, 01 Oct 2000 07:29:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13fk7V-0005IN-00 for namedroppers@ops.ietf.org; Sun, 01 Oct 2000 07:29:37 -0700 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: Sun, 01 Oct 2000 03:00:00 -0700 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 Oct 4 22:24:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07197 for ; Wed, 4 Oct 2000 22:24:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13gzxh-000Lh0-00 for namedroppers-data@psg.com; Wed, 04 Oct 2000 18:36:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13gzxg-000Lgu-00 for namedroppers@ops.ietf.org; Wed, 04 Oct 2000 18:36:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13gzxg-000IXU-00 for namedroppers@ops.ietf.org; Wed, 04 Oct 2000 18:36:40 -0700 Date: Wed, 4 Oct 2000 18:33:10 -0700 (PDT) From: Brian Wellington To: namedroppers@ops.ietf.org Subject: singing-auth & simple-secure-update drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In the process of trying to move these drafts to RFCs, a few minor changes have been made. The SSU one is my fault - I probably should have submitted a new draft a few months ago, but forgot. Sorry. The main change to signing auth is the following text: -- The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. The only exception that the signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed. -- which allows self signed key sets, which will be necessary for DNSSEC to be effective. In simple-secure-update, the "Interaction with DNSSEC section" was cleaned up, and the only major change is that the server is no longer required to verify signatures generated by zone keys. The text is below, since the draft will likely not show up for a few days (it was just submitted). -- 4 - Interaction with DNSSEC Although this protocol does not change the way updates to secure zones are processed, there are a number of issues that should be clarified. 4.1 - Adding SIGs An authorized update request MAY include SIG records with each RRset. Since SIG records (except SIG(0) records) MUST NOT be used for authentication of the update message, they are not required. 4.1 - Adding SIGs An authorized update request MAY include SIG records with each RRset. Since SIG records (except SIG(0) records) MUST NOT be used for authentication of the update message, they are not required. If a principal is authorized to update SIG records and there are SIG records in the update, the SIG records are added without verification. The server MAY examine SIG records and drop SIGs with a temporal validity period in the past. 4.2 - Deleting SIGs If a principal is authorized to update SIG records and the update specifies the deletion of SIG records, the server MAY choose to override the authority and refuse the update. For example, the server may allow all SIG records not generated by a zone key to be deleted. 4.3 - Non-explicit updates to SIGs If the updated zone is secured, the RRset affected by an update operation MUST, at the completion of the update, be signed in accordance with the zone's signing policy. This will usually require one or more SIG records to be generated by one or more zone keys whose private components MUST be online [signing-auth]. When the contents of an RRset are updated, the server MAY delete all associated SIG records, since they will no longer be valid. 4.4 - Effects on the zone If any changes are made, the server MUST, if necessary, generate a new SOA record and new NXT records, and sign these with the appropriate zone keys. Changes to NXT records by secure dynamic update are explicitly forbidden. SOA updates are allowed, since the maintenance of SOA parameters is outside of the scope of the DNS protocol. -- If no one objects to these changes, the drafts should be able to move forward very soon... 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 Fri Oct 6 11:46:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06791 for ; Fri, 6 Oct 2000 11:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13hYwk-000C0n-00 for namedroppers-data@psg.com; Fri, 06 Oct 2000 07:58:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13hYwk-000C0h-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 07:58:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13hYwj-0004s6-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 07:58:01 -0700 Message-Id: <200010061030.GAA27341@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-signing-auth-02.txt Date: Fri, 06 Oct 2000 06:30:16 -0400 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 : Domain Name System Security (DNSSEC) Signing Authority Author(s) : B. Wellington Filename : draft-ietf-dnsext-signing-auth-02.txt Pages : 7 Date : 05-Oct-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-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-signing-auth-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-signing-auth-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: <20001005145735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signing-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signing-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001005145735.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 Fri Oct 6 11:53:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06790 for ; Fri, 6 Oct 2000 11:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13hYwp-000C0v-00 for namedroppers-data@psg.com; Fri, 06 Oct 2000 07:58:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13hYwp-000C0p-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 07:58:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13hYwp-0004sA-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 07:58:07 -0700 Message-Id: <200010061030.GAA27355@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-simple-secure-update-02.txt Date: Fri, 06 Oct 2000 06:30:22 -0400 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 : Secure Domain Name System (DNS) Dynamic Update Author(s) : B. Wellington Filename : draft-ietf-dnsext-simple-secure-update-02.txt Pages : 9 Date : 05-Oct-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-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-simple-secure-update-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-simple-secure-update-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: <20001005145754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-simple-secure-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001005145754.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 Fri Oct 6 18:15:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13829 for ; Fri, 6 Oct 2000 18:15:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13hfE4-000HMW-00 for namedroppers-data@psg.com; Fri, 06 Oct 2000 14:40:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13hfE4-000HMQ-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 14:40:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13hfE4-0007D3-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 14:40:20 -0700 Date: Fri, 6 Oct 2000 14:38:26 -0700 (PDT) From: Michael Sawyer To: namedroppers@ops.ietf.org Subject: EDNS standard clarification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brian Wellington and myself are working on a personal draft which proposes two new EDNS option codes, and have encountered an issue with RFC2671 which we believe needs addressing. RFC2671 appears to be totally silent on the issue of how an EDNS-aware server should handle the situation where it gets a query with an EDNS OPT record containing one or more option codes which it doesn't know how to handle. Section 5.3 of 2671 doesn't appear to apply in this case, since I read that as talking about servers which don't speak EDNS at all, not ones which speak EDNS but not all of the options which it is sent. My first impression of what should be done (which is what Bind9 does, and appears to be what most people I've spoken to feel is correct) is to ignore the unrecognized option records. As the standard is written now, it is unclear whether servers should behave this way, reply with FORMERR, NOTIMPL, or take some other course of action. Is it the opinion of the rest of the working group that the correct behavior is to ignore the unknown options, leaving it up to the authors of the option standards to define what behavior is required if the server needs to indicate that it did understand and accept the passed option? Mike 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 Oct 6 20:39:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15684 for ; Fri, 6 Oct 2000 20:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13hhiI-000PMp-00 for namedroppers-data@psg.com; Fri, 06 Oct 2000 17:19:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13hhiH-000PMd-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 17:19:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13hhiG-000Duo-00 for namedroppers@ops.ietf.org; Fri, 06 Oct 2000 17:19:40 -0700 From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14814.20120.720819.343666@kitab.cisco.com> Date: Fri, 6 Oct 2000 15:13:44 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Status of RFC1611, RFC1612 X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On the DNSEXT working group web page it mentions documents under consideration for advancement as: DNS Server MIB Extensions RFC1611 Proposed DNS Resolver MIB Extensions RFC1612 Proposed However, it then mentions under working group items as: Retirement of DNS MIB's RFC's Since these RFCs are rather old, I'm guessing that the whole issue of a MIB for DNS is being dropped? Just trying to make sure. /raj 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 Oct 9 15:05:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08502 for ; Mon, 9 Oct 2000 15:05:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13ifJQ-0007mc-00 for namedroppers-data@psg.com; Mon, 09 Oct 2000 08:58:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13ifJQ-0007mW-00 for namedroppers@ops.ietf.org; Mon, 09 Oct 2000 08:58:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13ifJQ-000NRP-00 for namedroppers@ops.ietf.org; Mon, 09 Oct 2000 08:58:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001009091657.00e06330@localhost> Date: Mon, 09 Oct 2000 09:20:55 -0400 To: Richard Johnson , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Status of RFC1611, RFC1612 In-Reply-To: <14814.20120.720819.343666@kitab.cisco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 06:13 PM 10/6/00, Richard Johnson wrote: >On the DNSEXT working group web page it mentions documents under >consideration for advancement as: > > DNS Server MIB Extensions RFC1611 Proposed > > DNS Resolver MIB Extensions RFC1612 Proposed > >However, it then mentions under working group items as: > > Retirement of DNS MIB's RFC's > >Since these RFCs are rather old, I'm guessing that the whole issue of >a MIB for DNS is being dropped? Just trying to make sure. > >/raj The old RFC's have been demonstrated to be a bad fit for what is needed and one implementation specific. The working group has agreed to drop them from the standards process, the WG is willing to entertain replacement MIB proposals. Olafur (the WG co-chair). PS: my personal guess is that each vendor will create his own 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 Tue Oct 10 13:20:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08663 for ; Tue, 10 Oct 2000 13:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j2H0-0005hx-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 09:29:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j2Gz-0005hr-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 09:29:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j2Gz-0005gq-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 09:29:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 10 Oct 2000 15:59:08 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: DNSSEC and child sigs Message-ID: <20001010155908.A25346@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Should the parent keep the child's key in its zone file or should the child keep it in its zone file or both? The same can be asked about the parent's sig over the child's key. We can identify the following situations: A B C D parent has .. |key+sig |key+sig| - |key+sig | child has |key+sig |key |key+sig | - | ----------------------+---------+-------+----------+---------| 1 init. parent signing |notify? | ok | oob | ok | | | | | | 2 init. child signing | ok | ok | ok | ok | | | | | | 3 parent resign |notify? | ok | oob | ok | | | | | | 4 child resign | ok | ok | ok | ok | | | | | | 5 new parent key |notify? | ok | oob | ok | | | | | | 6 new child key |oob | oob | oob | oob | Explanation A) 1) parent signs its zone and notifies the child. But what if the child does not react on this notify? We then have a sig clash. 2) child sign its zone, no problem. 3) parent signature expires and resigns. The child must be informed of this update. This can be done by a DNS notify, B but see 1. 4) child sig expires. No problem. Child resigns zone. 5) new parent key. Child must be updated with the new SIG. See 1&3. 6) new child key. Out of band communication is needed here. B) 3) child doesn't have the sig, no communication needed 5) child doesn't have the sig, no communication needed 1+2+4+6) see A. C) 1) The problem here is that the sig does not exist and will not be put in the parent's zone, so an out of band notification is needed to update the child 3) the sig has expired. How does the parent know and out-of-band notification is needed to update the child? 5) see 3. 2+4+6) see A. D) see B. With an added advantage that there is no duplicate information DNS. The child will have the key for configuration purposes anyway. It seems that D is the most optimum and B also ranks high, but we see that bind9 uses either A or C. Why? Miek Gieben NLnet Labs 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 Oct 10 14:42:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10208 for ; Tue, 10 Oct 2000 14:42:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j40s-0007dP-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 11:20:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j40s-0007dJ-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:20:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j40s-0006OH-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:20:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200010101805.LAA01795@zed.isi.edu> Subject: Re: EDNS standard clarification To: Michael.Sawyer@nominum.com (Michael Sawyer) Date: Tue, 10 Oct 2000 11:05:17 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: from "Michael Sawyer" at Oct 06, 2000 02:38:26 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % My first impression of what should be done (which is what Bind9 does, and % appears to be what most people I've spoken to feel is correct) is to % ignore the unrecognized option records. As the standard is written now, % it is unclear whether servers should behave this way, reply with FORMERR, % NOTIMPL, or take some other course of action. I would expect the behaviour to be "NOTIMPL" instead of a "silent" ignore. Its not a FORMERR, is it? :) --bill 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 Oct 10 14:47:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10475 for ; Tue, 10 Oct 2000 14:47:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j41c-0007e9-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 11:21:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j41c-0007e3-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:21:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j41c-0006OT-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:21:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 10 Oct 2000 11:19:38 -0700 (PDT) From: Michael Sawyer To: Bill Manning Cc: Michael Sawyer , namedroppers@ops.ietf.org Subject: Re: EDNS standard clarification In-Reply-To: <200010101805.LAA01795@zed.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 10 Oct 2000, Bill Manning wrote: > I would expect the behaviour to be "NOTIMPL" instead of a > "silent" ignore. Its not a FORMERR, is it? :) The problem I forsaw with something like that was what to do on getting the NOTIMPL reply back, if you sent out a query with (for example) 10 OPT attributes. Unless you have something which indicates *which* of the 10 you didn't recognize, the client has no way of knowing which ones to turn off, and turning all off just because one isn't implimented seems like a bad idea. Also, as Brian pointed out when we were discussing this the other day, some of the OPTs may be just fine to ignore (key or encryption types we understand, etc...). I can think of arguments both ways, actually. It may work to extend the EDNS definition of the opt codes such that the upper bit means "you MUST understand me or fail," or something along those lines. I know that's kind of ugly, but it may one way to deal with this. Mike 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 Oct 10 14:52:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10592 for ; Tue, 10 Oct 2000 14:52:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j40G-0007cc-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 11:19:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j40F-0007cW-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:19:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j40F-0006Ny-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:19:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20001010155908.A25346@open.nlnetlabs.nl> Date: Tue, 10 Oct 2000 14:01:38 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSEC and child sigs Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My knee-jerk reaction is that this is a DNSOP issue, as far as determing the best practice. At 9:59 AM -0400 10/10/00, Miek Gieben wrote: >It seems that D is the most optimum and B also ranks high, but we see >that bind9 uses either A or C. Why? RFC2535 says that if the child is signed, the child must advertise its public key and signature that validates the key. (At least one sig, whether the sig is allowed to validate is an issue, see the Signing Auth proto-RFC.) The RFC also says that the parent MAY also publish the child's key and the sig. This is why BIND 9 does A or C. One problem with D is that the KEY set belongs in the child zone, not the parent. IMHO, many of us who have spent time developing DNSSEC have assumed A and C were the best/only ways to do this. I don't think B or C had been considered because we just hadn't thought of those possibilities. So, perhaps you have added a new wrinkle to this. But this wrinkle should be asked to DNSOP. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Oct 10 15:17:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11310 for ; Tue, 10 Oct 2000 15:17:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j4bo-0008HL-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 11:58:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j4bn-0008HF-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:58:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j4bn-0006cf-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 11:58:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200010101851.OAA10587@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Date: Tue, 10 Oct 2000 14:51:48 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the following Internet-Drafts as Proposed Standards: Simple Secure Domain Name System (DNS) Dynamic Update , obsoleting RFC2137. Domain Name System Security (DNSSEC) Signing Authority , updating RFC2535. These documents are the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The first document specifies a method for performing secure Domain Name System (DNS) dynamic updates. The method described 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. The second document specifies 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. Working Group Summary There was WG consensus to advance these documents. Protocol Quality The specifications have been reviewed for the IESG by Erik Nordmark. 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 Oct 10 17:04:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13280 for ; Tue, 10 Oct 2000 17:04:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j6GT-0009a8-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 13:44:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j6GS-0009a2-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 13:44:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j6GS-0007ER-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 13:44:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200010102001.NAA05062@zed.isi.edu> Subject: Re: EDNS standard clarification To: Michael.Sawyer@nominum.com (Michael Sawyer) Date: Tue, 10 Oct 2000 13:01:48 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), Michael.Sawyer@nominum.com (Michael Sawyer), namedroppers@ops.ietf.org In-Reply-To: from "Michael Sawyer" at Oct 10, 2000 11:19:38 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % On Tue, 10 Oct 2000, Bill Manning wrote: % % > I would expect the behaviour to be "NOTIMPL" instead of a % > "silent" ignore. Its not a FORMERR, is it? :) % % The problem I forsaw with something like that was what to do on getting % the NOTIMPL reply back, if you sent out a query with (for example) 10 OPT % attributes. Unless you have something which indicates *which* of the 10 % you didn't recognize, the client has no way of knowing which ones to turn % off, and turning all off just because one isn't implimented seems like a % bad idea. So... perhaps the "right" thing is to update NOTIMPL with a array-index... :) But for legecy code, the right thing is a "blanket" NOTIMPL. --bill 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 Oct 10 17:07:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13406 for ; Tue, 10 Oct 2000 17:07:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j6Bk-0009WB-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 13:39:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j6Bj-0009W5-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 13:39:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j6Bj-0007CZ-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 13:39:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200010101908.MAA96405@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: EDNS standard clarification In-reply-to: Your message of "Tue, 10 Oct 2000 11:05:17 PDT." <200010101805.LAA01795@zed.isi.edu> Date: Tue, 10 Oct 2000 12:08:00 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the original intent of EDNS was that the version number would have to be revved to introduce any REQUIRED opt codes, and that version negotiation would be used to level set. EDNS0.5 seems to change all of that, though. 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 Oct 10 18:27:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14596 for ; Tue, 10 Oct 2000 18:27:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j7QZ-000AaS-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 14:59:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j7QY-000AaM-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 14:59:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j7QY-0007g9-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 14:59:14 -0700 From: Bill Fenner Message-Id: <200010102158.OAA25347@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ogud@tislabs.com Subject: Re: Status of RFC1611, RFC1612 Cc: raj@cisco.com, namedroppers@ops.ietf.org Date: Tue, 10 Oct 2000 14:58:25 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > PS: my personal guess is that each vendor will create his own MIB. If you think that vendors are going to need to create MIBs, wouldn't it be better for the working group to define a standard one instead? Or do you think that the things that are worth creating a MIB for are so product-specific that there's nothing useful the WG can do? Bill 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 Oct 10 18:39:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14595 for ; Tue, 10 Oct 2000 18:27:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13j7X0-000Agn-00 for namedroppers-data@psg.com; Tue, 10 Oct 2000 15:05:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13j7X0-000Agh-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 15:05:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13j7X0-0007j1-00 for namedroppers@ops.ietf.org; Tue, 10 Oct 2000 15:05:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E391F1.D89CEFA6@daimlerchrysler.com> Date: Tue, 10 Oct 2000 18:02:25 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: EDNS standard clarification References: <200010102001.NAA05062@zed.isi.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Manning wrote: > % On Tue, 10 Oct 2000, Bill Manning wrote: > % > % > I would expect the behaviour to be "NOTIMPL" instead of a > % > "silent" ignore. Its not a FORMERR, is it? :) > % > % The problem I forsaw with something like that was what to do on getting > % the NOTIMPL reply back, if you sent out a query with (for example) 10 OPT > % attributes. Unless you have something which indicates *which* of the 10 > % you didn't recognize, the client has no way of knowing which ones to turn > % off, and turning all off just because one isn't implimented seems like a > % bad idea. > > So... perhaps the "right" thing is to update NOTIMPL with a > array-index... :) Or, following the lead of EDNS0.5, how about the server returns an option list in its reply including just those requested options it understands and honors? If it is ever necessary for the client to distinguish between a server's "don't understand" and "don't honor", then allocate another option code for the server to use as an explicit NAK -- "understand but don't honor". Unless, of course, we are running low on available option codes :-) - Kevin 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 Oct 11 09:38:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10468 for ; Wed, 11 Oct 2000 09:38:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13jLbK-0004EM-00 for namedroppers-data@psg.com; Wed, 11 Oct 2000 06:07:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13jLbK-0004EG-00 for namedroppers@ops.ietf.org; Wed, 11 Oct 2000 06:07:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13jLbK-000KwQ-00 for namedroppers@ops.ietf.org; Wed, 11 Oct 2000 06:07:18 -0700 Message-Id: <200010111031.GAA05591@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-sawyer-dnsext-edns0-zone-option-00.txt Date: Wed, 11 Oct 2000 06:31:08 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ZONE and VIEW option records in DNS messages Author(s) : M. Sawyer, B. Wellington, M. Graff Filename : draft-sawyer-dnsext-edns0-zone-option-00.txt Pages : 4 Date : 10-Oct-00 This document defines two new EDNS option codes used to specify what zone and view should be used in query messages to a remote DNS server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-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-sawyer-dnsext-edns0-zone-option-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-sawyer-dnsext-edns0-zone-option-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: <20001010123230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sawyer-dnsext-edns0-zone-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010123230.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 Oct 25 12:54:20 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09106 for ; Wed, 25 Oct 2000 12:54:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13oSsw-000LZe-00 for namedroppers-data@psg.com; Wed, 25 Oct 2000 08:54:38 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13oSsu-000LZW-00 for namedroppers@ops.ietf.org; Wed, 25 Oct 2000 08:54:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13oSss-0004Nj-00 for namedroppers@ops.ietf.org; Wed, 25 Oct 2000 08:54:34 -0700 Message-Id: <200010251015.GAA23051@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-rsvp-newidentity-01.txt Date: Wed, 25 Oct 2000 06:15:40 -0400 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 Resource Allocation Protocol Working Group of the IETF. Title : Identity Representation for RSVP Author(s) : S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog Filename : draft-ietf-rap-rsvp-newidentity-01.txt Pages : 17 Date : 24-Oct-00 This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-newidentity-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-rap-rsvp-newidentity-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-rap-rsvp-newidentity-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: <20001024130807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-newidentity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-newidentity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001024130807.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 Oct 31 01:06:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28198 for ; Tue, 31 Oct 2000 01:06:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qTpr-000Ic5-00 for namedroppers-data@psg.com; Mon, 30 Oct 2000 21:19:47 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qTpr-000Ibt-00 for namedroppers@ops.ietf.org; Mon, 30 Oct 2000 21:19:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qTpr-0000Ia-00 for namedroppers@ops.ietf.org; Mon, 30 Oct 2000 21:19:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001030221024.00bed530@localhost> Date: Mon, 30 Oct 2000 23:23:08 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Fwd: draft-ietf-dnsext-apl-rr-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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". >To: namedroppers >Subject: draft-ietf-dnsext-apl-rr-01.txt >Date: Wed, 16 Aug 2000 11:54:44 -0400 >From: Thomas Narten >Sender: owner-namedroppers@ops.ietf.org > >The IESG discussed this ID recently and a meta issue was discussed >that I think the WG should think about. In particular: > > > 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. > >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 >logically different uses make use of the same RR. An administrator >might define RRs with one usage in mind, but those RRs are then also >queried by other applications that interpret the meaning of that RR >differently than intended by the owner. Wrong things can happen as a >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. > >I note that semantics/usage of the Negation Flag is explicitely not >defined in this document, so the RR seems underspecified. > >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. > >To summarize, I wonder if: > >1) This document should be published at all, without a specific usage > associated with it for the reasons discussed above. > >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. > >What does the WG think about this? > >Minor comments: > > > 4. APL RDATA format > > > > 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. > > > 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 > >Thomas 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 Oct 31 10:50:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18822 for ; Tue, 31 Oct 2000 10:50:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qcqa-000Odh-00 for namedroppers-data@psg.com; Tue, 31 Oct 2000 06:57:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qcqa-000Odb-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 06:57:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qcqa-0003nX-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 06:57:08 -0800 Message-Id: <200010311215.HAA22924@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-dnsmib-historical-00.txt Date: Tue, 31 Oct 2000 07:15:34 -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 : Applicability Statement for DNS MIB Extensions Author(s) : R. Austein Filename : draft-ietf-dnsext-dnsmib-historical-00.txt Pages : 4 Date : 30-Oct-00 More than six years after the DNS Server and Resolver MIB extensions became proposed standards, there still has not been any significant deployment of these MIB extensions. This note examines the reasons why these MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-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-dnsmib-historical-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-dnsmib-historical-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: <20001030080821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnsmib-historical-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001030080821.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 Oct 31 12:20:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24133 for ; Tue, 31 Oct 2000 12:20:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qeR2-000PnZ-00 for namedroppers-data@psg.com; Tue, 31 Oct 2000 08:38:52 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qeR1-000PnT-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 08:38:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qeR1-0004QM-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 08:38:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001030231627.00be1220@localhost> Date: Tue, 31 Oct 2000 10:13:32 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: RFC1611 replacement effort Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I asked on a BIND related mailing list for people to step forward if they are interested in working on a replacement MIB for RFC1611. Anyone on this mailing list that is interested send me a note and I will get all the interested parties organized on discussing this issue. Defining a MIB proposal is an effort that will many of the people on this list may not care about and may involve SNMP issues as well as DNS, this discussion may to some extent take place on a different mailing list. Olafur PS: So far one person is willing to write a NULL MIB definition and two people willing to work on real MIB proposal. 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 Oct 31 12:43:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04103 for ; Tue, 31 Oct 2000 12:43:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qf2G-0000HD-00 for namedroppers-data@psg.com; Tue, 31 Oct 2000 09:17:20 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qf2G-0000H7-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 09:17:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qf2G-0004iz-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 09:17:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.0.20001031085039.00d247a0@204.29.28.145> Date: Tue, 31 Oct 2000 08:50:47 -0700 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson (by way of "Kevin J. Dunlap" ) Subject: RE: RFC 1611 support Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 08:09 PM 10/30/00, Dwayne Carter wrote: >Count me in! First step, someone needs to write draft of "The case for DNS server MIB" Second step "DNS server MIB charter/requirements" , at this point I'm not sure how many MIB's makes sense to define. I can think of statistics MIB, server configuration MIB, zone MIB .... or all in one MIB Olafur PS: The MIB or MIB's MUST be server implementation independent. 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 Oct 31 12:54:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08380 for ; Tue, 31 Oct 2000 12:54:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qf20-0000Gl-00 for namedroppers-data@psg.com; Tue, 31 Oct 2000 09:17:04 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qf20-0000Gf-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 09:17:04 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qf20-0004iu-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 09:17:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.0.20001031084938.00c6a3a0@204.29.28.145> Date: Tue, 31 Oct 2000 08:50:32 -0700 To: namedroppers@ops.ietf.org From: "Dwayne Carter" (by way of "Kevin J. Dunlap" ) Subject: RE: RFC 1611 support Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Count me in! Dwayne Carter System Engineer, Internet Connections, Inc. -----Original Message----- From: bind9-users-bounce@isc.org [mailto:bind9-users-bounce@isc.org]On Behalf Of Olafur Gudmundsson Sent: Monday, October 30, 2000 11:17 AM To: Dwayne Carter Cc: bind9-users@isc.org Subject: RE: RFC 1611 support At 05:56 AM 10/30/00, Dwayne Carter wrote: >darn, That was the one feature set I was looking for...Oh well, I guess I >will have to start coding... >May I why it is moving to historic? I believe that is a great feature for >monitor DNS activities. In a day or two following ID will be available that explains this http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.t xt Summary the MIB is bind 4.8.3 specific. ANYONE willing to work on defining a NEW MIB for DNS server, please let me know. Olafur (DNSEXT co-chair). 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 Oct 31 14:34:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16470 for ; Tue, 31 Oct 2000 14:34:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13qgHO-00061h-00 for namedroppers-data@psg.com; Tue, 31 Oct 2000 10:37:02 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 13qgHN-00061b-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 10:37:01 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13qgHN-0005di-00 for namedroppers@ops.ietf.org; Tue, 31 Oct 2000 10:37:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Richard Barr Hibbs" To: "Namedroppers" Subject: RE: RFC1611 replacement effort Date: Tue, 31 Oct 2000 10:36:50 -0800 Message-ID: In-Reply-To: <4.3.2.7.2.20001030231627.00be1220@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Olafur Gudmundsson > Sent: Tuesday, October 31, 2000 7:14 AM > > > I asked on a BIND related mailing list for people to step forward > if they are interested in working on a replacement MIB for RFC1611. > > Anyone on this mailing list that is interested send me a note and > I will get all the interested parties organized on discussing > this issue. ...I'll assist in the efforts.... --Barr Hibbs, UltraDNS Corporation to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.