From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Randy Bush Subject: list policy Date: Wed, 01 Jan 2003 03:00:01 -0800 Lines: 67 Sender: owner-namedroppers@ops.ietf.org Return-path: To: namedroppers@ops.ietf.org Precedence: bulk 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. 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. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. 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. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Edward Lewis Subject: comments on DS-12, section 2.2.1.2 Date: Thu, 2 Jan 2003 11:52:43 -0500 Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net Return-path: X-Sender: edlewis@127.0.0.1 To: namedroppers@ops.ietf.org Precedence: bulk To the group - please scrutinize...In the spirit of "sending text": #2.2.1.2 Special processing when child and an ancestor share server # # When a child zone and a ancestor other than parent share an # authorative server, a DS aware server MUST answer with information # from child zone, as specified in section 2.2.1.1. This is to prevent # the server to be marked as lame for child. Special rules are needed to permit DS RR aware servers to gracefully interact with older caches which otherwise might falsely label a server as lame because of the new placement of the DS RR set. Such a situation might arise when a server is authoritative for both a zone and it's grandparent, but not the parent. This sounds like an obscure example, but it is very real. The root zone is currently served on 13 machines, and "root-servers.net." is served on 4 of the same 13, but "net." is served elsewhere. When a server receives a query for (, DS, IN), the response MUST be determined from reading these rules in order: 1) If the server is authoritative for the zone that holds the DS RR set (i.e., the zone that delegates away, aka the "parent" zone), the response contains the DS RR set as an authoritative answer. 2) If the server is offering recursive service, the server performs the query itself (according to the rules for resolvers described below) and returns it's findings. 3) If the server is authoritative for the zone that holds the 's SOA RR set, the response is an authoritative negative answer as described in 2.2.1.1. 4) If the server is authoritative for a zone above the QNAME, a referral to a more enclosing zone's servers is made. 5) If the server is not authoritative for any part of the QNAME, a response indicating a lame server for QNAME is given. [Editorial comment: notice the lack of RFC 2119 terms below this line. I am not sure what to require, most of what I have written might be considered recommendations for finding the data.] Using these rules will require some special processing on the part of a DS RR aware resolver. To illustrate this, an example is used. Assuming a server is authoritative for roots.example.net. and for the root zone but not the intervening two zones (or the intervening two label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN. The resolver will issue this request (assuming no cached data) expecting a referral to a net. server. Instead, rule number 3 above applies and a negative answer is returned by the server. The reaction by the resolver is not to accept this answer as final as it can determine from the SOA RR in the negative answer the context within which the server has answered. A solution to this is to instruct the resolver to hunt for the authoritative zone of the data in a brute force manner. This can be accomplished by taking the owner name of the returned SOA RR and strip off enough left-hand labels until a successful NS response is obtained. A successful response here means that the answer has NS records in it. (Entertaining the possibility that a cut point may be two labels down in a zone.) Returning to the example, the response will include a negative answer with either the SOA RR for "roots.example.net." or "example.net." depending on whether roots.example.net is a delegated domain. In either case, removing the least significant label of the SOA owner name will lead to the location of the desired data. # # This answer can cause problem for a DS aware resolver that is # traversing this branch of the DNS tree for the first time. The # resolver is expecting to get back either DS record or a delegation # information. The SOA with same name as QNAME informs the resolver # that the answer orignated from the zone below the one where the DS # resides. At this point the resolver has no information on how to get # from the ancestor to the parent. In this case the resolver SHOULD # attempt to fetch the delegation information by issuing a query with a # QNAME one label shorter and type NS. This will yield the NS set for # the parent, allowing the resolver to query for the DS record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "Olaf M. Kolkman" Subject: Version 2 of wildcard optimization draft Date: Fri, 3 Jan 2003 10:51:14 +0100 Organization: RIPE NCC Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Precedence: bulk Available in the ID repository soon, now at: http://www.ripe.net/DISI/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-02.html --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "Olaf M. Kolkman" Subject: Version 5 of keys signing key flag draft Date: Fri, 3 Jan 2003 10:49:58 +0100 Organization: RIPE NCC Lines: 14 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Precedence: bulk Available in the ID repository soon, now at: http://www.ripe.net/DISI/Notes/draft-ietf-dnsext-keyrr-key-signing-flag-05.html --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "Doug" Subject: Re: namedroppers, continued Date: Sun, 5 Jan 2003 19:04:41 -0500 Lines: 129 Sender: owner-ietf@ietf.org References: <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: , , , "Hallam-Baker, Phillip" Return-path: To: "Fred Baker" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Precedence: bulk Hello everyone, It seems to me if the mail server administrators would make the decision to require people that send emails from their servers to log into a valid account on that server and use the same valid account on the server as a return address it would negate the ability of a large percentage of the spamers to send the spam anon. This would allow easier filtering of many of the offending messages by domain. Additionally, the sending account field and the reply to field should be equal and clients should be required to use an email address that is associated with the account used to log into the server in the first place. This will need to be implemented in the beginning by administrators who run software capable of it, and it would be implemented later as part of the email client and/or server software using new software releases, patches, and individual customizations of existing software. I know that there are many people who will scream and gnash their teeth at this suggestion as it will force them to identify themselves to anon mailing lists but I think it would be an acceptable compromise if we could eliminate a major portion of the spam clogging our inboxes. Clients need to be identified by ISP based email servers using their DNS and IP address footprints and clients attempting to send email with improper footprints should be disregarded (making it very difficult to send email from the server if you truly are not a valid subscriber to the service, much like many of the current news servers do). Then to deal with the anonymous email servers out there (hotmail, yahoo, etc...) the operators of those services should require clients logging into those accounts to send email from a valid IP address with no unsecured proxy services running on them (much like many IRC servers are doing) and transmit this IP information along with the email being sent. This would allow for pinpoint identification of the senders of spam using IP addresses MAC addresses and time stamped logs for the specific purposes of taking legal action against these network abuses. I know it will be argued that this will require cooperation between ISPs and that some systems are already implementing these measures but if all administrators as a single body insist that everyone adhere to these rules or be excluded from sending email to clients of their services and enforced this through IP block and domain blocking the stragglers would be forced to adhere to these rules. Further, if a body such as the IETF stood behind this and perhaps drafted specifications for administrators, and software developers to follow when making new clients/servers and updating existing clients/servers it would hold added weight in the market place. The extra cost associated with such actions could be offset by saved resources, and additional revenues made as a result of higher subscription rates justified by superior spam filtering techniques and a greater number of subscribers to the service due to better service quality. I would also like to suggest that the California law that requires all unsolicited emails be appended with adv: in the subject line be expanded to a federal law and additionally require emails that are solicited by signing up for a service include exact information about who the sender bought your email address from in the email. These are just some ideas I have had on eliminating spam and should in no way be considered a flame against anyone. I know there is no way that this will stop all unsolicited email from being sent or received. I just thought they might help to get some people rolling on a solution and that it would be better than complaining about it. After all doesn't a global solution make more sense than venting about what should be done to keep it out of this mailing list. Thank you for your time and attention, Douglas Huyler Dougxx2@carolina.rr.com 704-721-0212 P.S. I am sorry this email comes so long after the original post was made but I don't read the list very often and after reading this thread from the begining to December 6th I thought I would reply. If someone else has brought these things up after this point I am sorry, but I haven't caught up with the list yet. ----- Original Message ----- From: "Fred Baker" To: "Hallam-Baker, Phillip" Cc: ; ; Sent: Friday, December 06, 2002 4:41 PM Subject: RE: namedroppers, continued > At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: > >The only way to resolve this issue properly would be to require every > >submission to an IETF mailing list to be cryptographically signed (PGP > >or S/MIME), to require the subscribers to register their signing key and > >to then filter the mail sent out on the list so that only signed mail > >gets through. > > I would be in favor of that, personally, as long as we can ensure that the > appropriate signature facility (be it RSA, PGP, or whatever) is freely > available to all who need to use it. The issue here is not us corporate > types who have a business reason to buy the software, it is the students > who often lack the funds. The big issue would be the procedures for posting > one's key to the appropriate place - what is to stop a spammer from posting > a key and sending the spam anyway? I'm not proposing a mechanism, but > someone who is good at such things might well find it of value. > > It doesn't address the "off topic" issue. As you say, that could be left to > a working group chair equiped with formal procedures developed by consensus > within the work group or adopted by the working group from a more general > place (ie, the IETF could suggest a procedure, and the WG could adopt it if > it didn't feel another procedure would be better). > > I have had a private exchange, over the past few days, with someone who > wished that the IETF would please document some good spam-elimination > procedure, so that it could be used world-wide to completely eliminate > spam. I think that boils down to "provide a global PKI" in this solution, > and presumes that spammers are incapable of using one. That might be a > great research topic. Too bad nobody has ever thought of it before; we > could really use the outcome of that research. (OK, so it's a lame attempt > at humor...) > > I think it was Steve Bellovin that suggested a procedure for reducing the > utility of spoofing source addresses in emails; if not, it was me and I > happened to suggest something his favorite algorithm fit into, by having a > host in each mail domain (mailid.example.com) be able to assert that its > domain had or had not sent an email within a given recent time period > whose MD5 hash, when divided by resulted in > . I could write that up in an internet draft if folks > think it makes sense. That would be a more global procedure that didn't > require a PKI and only addressed spoofed addresses. > From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "Doug" Subject: Fw: namedroppers, continued (flamed in less than an hour. figures) Date: Sun, 5 Jan 2003 21:59:16 -0500 Lines: 52 Sender: owner-ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: , Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Precedence: bulk I am wondering, is Daniel Senie normally rude to people she doesn't know or is she just having a bad day? I sent a message out with some informal suggestions in it that I thought might be helpful and she instantly jumps down my throat with a nasty reply? It isn't like she or anyone can accuse me of being a troll as I have only posted once or twice before. I am sorry I didn't consult my english professor or a text for proper form before I sent it (I really am), but I guess I thought it was an INFORMAL forum and I know my email was intended as an informal thought process to be shared with the group on an INFORMAL basis. Well anyway let me know what is going on with this as I am confused now (I really don't understand the attitude). I have included the entire text of her message below as well as my reply so everyone might know what I am talking about. Her message ----- Original Message ----- From: "Daniel Senie" To: "Doug" Sent: Sunday, January 05, 2003 7:45 PM Subject: Re: namedroppers, continued > Paragraph breaks MIGHT have made your email readable. Instead, I suspect > many folks will just hit delete. > My reply to her Well, I am sorry Mrs. Senie, that you feel the need to flame me for throwing out a few informal ideas in an informal open forum. Next time I will be sure to consult my old english professor on the proper format. Jeesh Couldn't come up with one descent comment could ya? What's next spelling errors and typos Doug ----- Original Message ----- From: "Daniel Senie" To: "Doug" Sent: Sunday, January 05, 2003 7:45 PM Subject: Re: namedroppers, continued > Paragraph breaks MIGHT have made your email readable. Instead, I suspect > many folks will just hit delete. > From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Franck Martin Subject: RE: namedroppers, continued (flamed in less than an hour. figure s) Date: Mon, 6 Jan 2003 15:46:08 +1200 Lines: 89 Sender: owner-ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org, iesg@ietf.org Return-path: To: "'Doug'" , ietf@ietf.org X-Mailer: Internet Mail Service (5.5.2650.21) Precedence: bulk Some people on the IETF as being technos lack people skills, that's why they work with computers... Do not worry about that... Each time I post a suggestion/comment I get always a bunch of answer like: "This is real stupid" without explaining me why... If your ego can pass that, you will be admitted to the IETF confrerie and be able to do the same to newbies... Cheers. Franck Martin > -----Original Message----- > From: Doug [mailto:Dougxx2@carolina.rr.com] > Sent: Monday, 6 January 2003 2:59 > To: ietf@ietf.org > Cc: namedroppers@ops.ietf.org; iesg@ietf.org > Subject: Fw: namedroppers, continued (flamed in less than an hour. > figures) > > > I am wondering, is Daniel Senie normally rude to people she > doesn't know or > is she just having a bad day? I sent a message out with some informal > suggestions in it that I thought might be helpful and she > instantly jumps > down my throat with a nasty reply? It isn't like she or > anyone can accuse me > of being a troll as I have only posted once or twice before. > I am sorry I > didn't consult my english professor or a text for proper form > before I sent > it (I really am), but I guess I thought it was an INFORMAL > forum and I know > my email was intended as an informal thought process to be > shared with the > group on an INFORMAL basis. Well anyway let me know what is > going on with > this as I am confused now (I really don't understand the > attitude). I have > included the entire text of her message below as well as my reply so > everyone might know what I am talking about. > > > Her message > > ----- Original Message ----- > From: "Daniel Senie" > To: "Doug" > Sent: Sunday, January 05, 2003 7:45 PM > Subject: Re: namedroppers, continued > > > > Paragraph breaks MIGHT have made your email readable. > Instead, I suspect > > many folks will just hit delete. > > > > My reply to her > > Well, I am sorry Mrs. Senie, that you feel the need to flame > me for throwing > out a few informal ideas in an informal open forum. Next time > I will be sure > to consult my old english professor on the proper format. > > Jeesh Couldn't come up with one descent comment could ya? > > What's next spelling errors and typos > > Doug > > ----- Original Message ----- > From: "Daniel Senie" > To: "Doug" > Sent: Sunday, January 05, 2003 7:45 PM > Subject: Re: namedroppers, continued > > > > Paragraph breaks MIGHT have made your email readable. > Instead, I suspect > > many folks will just hit delete. > > > > From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Valdis.Kletnieks@vt.edu Subject: Re: namedroppers, continued (flamed in less than an hour. figure s) Date: Sun, 05 Jan 2003 23:35:03 -0500 Lines: 41 Sender: owner-ietf@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1529921543P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "'Doug'" , ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Franck Martin In-Reply-To: Your message of "Mon, 06 Jan 2003 15:46:08 +1200." Precedence: bulk --==_Exmh_1529921543P Content-Type: text/plain; charset=us-ascii On Mon, 06 Jan 2003 15:46:08 +1200, Franck Martin said: > Some people on the IETF as being technos lack people skills, that's why they > work with computers... I usually explain it as "We're talking here about a collection of people who are paid vast sums of money for their ability to carry on productive conversations with inanimate objects". It's usually easy to see the need for the cutting of slack at that point. ;) > If your ego can pass that, you will be admitted to the IETF confrerie and be > able to do the same to newbies... Can anybody provide the original citation for the statement (similar to): "The flame you are complaining about did not cast any aspersion on your parentage or dietary preferences, and as such was mild by IETF standards"? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1529921543P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+GQd3cC3lWbTT17ARAmrqAJwJg0SfV2TxG1nxHrKy9MFNBa1XgQCfdSQ/ D9lWVTmMZd3QF6Oo3WgvBoU= =bPIn -----END PGP SIGNATURE----- --==_Exmh_1529921543P-- From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "Doug" Subject: Re: Fw: namedroppers, continued (flamed in less than an hour. figures) Date: Mon, 6 Jan 2003 00:59:41 -0500 Lines: 106 Sender: owner-ietf@ietf.org References: <004201c2b52f$9aab8ea0$0701a8c0@nailed.org> <3E18F6DD.69EE90B8@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: , , , "Daniel Senie" Return-path: To: "grenville armitage" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Precedence: bulk Grenvill Armitage, That is not the point and you know it. It is all about the nonsense attitude. Just ask yourself if it was all about making a polite suggestion then tell me why the word "might" was capitalized. Try reading what she wrote and putting emphasis on that word. Oh yeah I am going to continue to repost the nonsense as long as they are rude enough to keep sending it. The purpose of it is so that everyone knows how they are treating people and so that the other people that are being harassed by this incredibly rude person know that it is not just them and that this person is an incredible TROLL. What you are refering to as netiquette is an unspoken rule of USENET not a mailing list as far as I know, so I don't believe it applies here. In addition, I would like to add I thought this was a forum for professionals not kids. Before you start claiming that this person is not being a TROLL check out what the next response was. It isn't very professional or condusive to getting anything done in my opinion. Of course maybe the IETF isn't interested in getting anything done or talking about any real ideas. What do you think? I think that anyone that makes replies to messages in a public forum like THIS one which (unlike what usenet has turned into) is supposed to be about solving problems and getting things done, needs to be revealed to the group as a TROLL and a CHILD. I will personally be filtering the rest of the email from her since I don't have the time nor the desire to deal with the stupidity and I know there are plenty of other people here with things to say that are worth hearing. Hopefully you won't be the next person to go in my filter Grenville since I actually believe you were trying to do something here even if it was misguided. Bye bye Daniel. Oh, don't bother replying to my message with the obligatory "well fine I will ignore you to" because I won't see it. P.S. If you doubt the my claim that it was the entire message either time I can always post them as file attachments for the whole group to see. Done with this nonsense now, Doug Dougxx2@carolina.rr.com 704-721-0212 what follows is the childish reply I got from Daniel Senie ------------------------------------ At 09:40 PM 1/5/2003 >>Well, I am sorry Mrs. Senie, > >Mrs.? heh. > >> that you feel the need to flame me for throwing >>out a few informal ideas in an informal open forum. Next time I will be sure >>to consult my old english professor on the proper format. >> >>Jeesh Couldn't come up with one descent comment could ya? >> >You perhaps mean "decent"? The word you used refers to decreasing altitude. >> >> >>What's next spelling errors and typos >> >Absolutely. Should you wish to communicate your ideas to others, it'd >REALLY help if you learned to communicate effectively. ------------------------------------------------- end of childish rant from Daniel Senie Oh and for your information Daniel I think anyone with a reading level over fourth grade could understand what I said and I think everyone that did bother to read it knows it. ----- Original Message ----- From: "grenville armitage" To: "Doug" Sent: Sunday, January 05, 2003 10:24 PM Subject: Re: Fw: namedroppers, continued (flamed in less than an hour. figures) > > Doug wrote: > > > > I am wondering, is Daniel Senie normally rude to people she doesn't know or > > is she just having a bad day? > > My reading of what you claim is the entirety of Senie's email to you > is that you received a perfectly valid and succint suggestion. You seem > to be overreacting, and committing a greater netiquette sin of re-posting > someone's private email to you. > > What exactly are you upset about? > > cheers, > gja > -- > Grenville Armitage > http://caia.swin.edu.au From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Randy Bush Subject: non-approval Date: Mon, 06 Jan 2003 06:08:23 -0800 Lines: 12 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: To: namedroppers Precedence: bulk just so you know, as there is zero dns protocol content, i am not approving a spate of non-subscriber flamage and name-calling about anti-spam that you can read on the ietf mailing list if you wish. 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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dnsext-opcode-discover-01.txt Date: Tue, 07 Jan 2003 08:28:17 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org Return-path: To: IETF-Announce: ; Precedence: bulk X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content --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 : The DISCOVER opcode Author(s) : B. Manning, P. Vixie, E. Guttman Filename : draft-dnsext-opcode-discover-01.txt Pages : 0 Date : 2003-1-6 The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dnsext-opcode-discover-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-dnsext-opcode-discover-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: <2003-1-6145216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dnsext-opcode-discover-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dnsext-opcode-discover-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145216.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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Keith Moore Subject: commens on draft-dnsext-opcode-discover-01.txt Date: Tue, 7 Jan 2003 09:31:05 -0500 Lines: 93 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: moore@cs.utk.edu Return-path: To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Precedence: bulk Note: I'm reading this as if it's a draft protocol specification rather than as if it's intended as an informational or experimental document. Even if the latter is intended, some amount of clarification seems in order. 1. use of SRV to implement getservbyname It is not appropriate to use SRV lookups to implement getservbyname(). This would change the behavior of nearly every protocol on the Internet without considering the impact on the protocol or applications that use it. Use of SRV MUST be determined on a per-protocol or per-application basis. Furthermore SRV was intended to delegate services for specific DNS domains, and getservbyname() doesn't provide a way to input the domain for which the SRV query is being made. Trying to use SRV as a generic way to look up "well known ports" independent of domain is overloading the SRV RR type. That,and trying to use the network to look up constants never was a good idea, not in the context of YP/NIS or anything else. I've seen too many programs fail because getservbyname() was implemented using NIS, and the NIS server was down. It's not as if protocol implementors don't know what port numbers to use anyway. If it's reasonable for a protocol implementation to include string constants like "MAIL FROM" or "POST", then it's reasonable for that protocol implementation to include integer constants like htons(25) or htons(80). 2. under section 2, "method", "Example usage for gethostby{name,addr}-style requestors:" it's not at all clear why "the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in gethostbyname ) or why queries for a particular NAME should only be sent to servers that are authoritative for the enclosing ADDRESS domain. Is this really what is intended or is it just poor wording? It reads as if you're trying to make the results of DNS lookups vary according to location. 3. same section "Once one learns a host's FQDN by the above means, repeat the process for discovering the closest enclosing authoritative server of such local name." the idea that a host has "a" FQDN seems anachronistic at best. hosts have zero or more addresses assigned to them at any particular time; each address may be associated with zero or more FQDNs. the address-to-host bindings may be short- or long-lived. in general there is no way that the network can be expected to know whether a particular FQDN is any kind of "distinguished name" for a host. the host has to be configured to know this on its own. 4. regarding disconnected networks NO server -- whether multicast or not, whether using DISCOVER or not, whether using the DNS port or not, whether using the DNS protocl or not -- should be answering queries as if it were authoritative for any DNS zone for which that server is not authoritative. The result will inevitiably be that such results are leaked into, and mixed with, results from legitimate DNS servers. a network which appears isolated to one host in a network may not be isolated to another host in the same network. if you want "disconnected" servers to respond to queries for FQDNs then those servers need to be authoritative for those FQDNs, and they need to produce results which are consistent with the other servers for those FQDNs. if some of those servers are on isolated networks and others are on the global internet, this is not a problem as long as the rules for serial numbers are followed. DNS can cope with different servers returning different results as long as those servers have different serial numbers and single-copy serializability is maintained. If a host which is authoritative for one or more FQDNs that are assigned to a host migrates from one network to another, or for whatever reason acquires a new address and/or needs to change its RRs, that host can update its RRs on its stub server and increment the serial # for that zone. If and when the host has connectivity to the (other) advertised servers for that zone, it should update those servers. But even if the host finds itself on an isolated network there is no problem with its updating its own zone and incrementing the serial number, perhaps multiple times, as long as it updates the slave servers whenever it is possible to do so. Of course there are operational concerns associated with advertising RRs that point to addresses that are not reachable, but we generally expect protocols to be robust when hosts are not reachable anyway. Appropriate assignment of TTLs is the best solution here, and the host is in the best position to know whether its RRs should have long or short TTLs (e.g. whether it is stable or nomadic). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-03.txt Date: Wed, 08 Jan 2003 08:48:47 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org Return-path: To: IETF-Announce: ; Precedence: bulk X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content --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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-03.txt Pages : 14 Date : 2003-1-7 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ecc-key-03.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-ecc-key-03.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: <2003-1-7160648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7160648.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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-05.txt Date: Thu, 09 Jan 2003 09:14:21 -0500 Lines: 90 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org Return-path: To: IETF-Announce: ; Precedence: bulk X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content --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 : KEY RR Key-Signing Key (KSK) Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-05.txt Pages : 9 Date : 2003-1-8 With the DS resource record the concept of key-signing and zone- signing keys has been introduced. During key-exchanges with the parent there is a need to differentiate between these zone- and key- signing keys. We propose a flag to indicate which key is used as key-signing key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-keyrr-key-signing-flag-05.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-keyrr-key-signing-flag-05.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: <2003-1-9091940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9091940.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. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Thomas Narten Subject: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 11:24:52 -0500 Lines: 292 Sender: owner-ietf@ietf.org Cc: ietf@ietf.org, iesg@ietf.org, namedroppers Return-path: To: "D. J. Bernstein" Precedence: bulk Dan Bernstein has been making repeated claims that Randy is censoring his postings to namedroppers. I took a look at the claims he has made and here is how I see things. Executive summary: I see no evidence that Randy is censoring postings from Dan. It is the case that some of his messages do not appear to have made it out on namedroppers, but it is unclear why this is. Furthermore, given that most of these missing messages were cc'ed to other lists (i.e., the ietf and iesg lists), there is no evidence of censorship. Namedroppers is a posters-only mailing list that is run in conformance with the policies outlined in http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. Specifically, all mail sent to namedroppers is: 1) first run through spamassassin. Mail that is rejected here is not archived, as the number of such messages is large. All mail sent to mailing lists on the server hosting namedroppers is run though spamassassin, so this is not a namedroppers-specific procedure. 2) if sent by a subscriber to the mailing list (or by someone in the known posters list), the message is sent immediately. 3) Otherwise, it is queued waiting for approval (or rejection) by the maling list operators. Both Randy and Mark Kosters see these rejected postings. Mark has indicated that he has seen no rejected postings that were not forwarded to the namedroppers mailing list that should have been. It does appear that *some* of the message that Dan has sent to namedroppers have not appeared on the namedroppers mailing list. But it is unclear why that happened. At the time of these postings, some of his other messages have gone through. Also, most of the messages that didn't appear did appear on other mailing lists that were cc'ed. It is unclear why those messages did not make it to namedroppers, but now that Dan's posting address is in the the list of know posters for namedroppers, and his mail seems to be getting through, it seems best to just keep an eye on further problems and investigate them as soon as they happen (e.g, when relevant logs are available). I see no evidence that Randy (or anyone else) is singling out anyone's postings for rejection. Details on specifics follow. "D. J. Bernstein" writes: > Bush imposed his mailing-list control methods without IESG approval, in > violation of RFC 2418, section 3.2. He has been caught engaging in > content-based censorship several times: > http://cr.yp.to/djbdns/namedroppers.html > Background > > The DNS protocol is covered by various IETF specifications. > Unfortunately, obeying those specifications is not sufficient to ensure > interoperability with BIND, in part because the specifications are > ambiguous or otherwise flawed, and in part because BIND violates the > specifications in many ways. > > These facts have hurt competition, and contributed to BIND's market > share, at the expense of the users. For example, one site using lbnamed, > a special-purpose DNS implementation, has had interoperability problems > with BIND, and has been planning to abandon lbnamed in favor of BIND, > even though this means giving up some useful features. > > In late 1999, after yet another BIND security hole was announced, I > wrote a free BIND replacement. Interoperability among DNS > implementations is, of course, essential. I found the IETF > specifications horribly inadequate. > > > The namedroppers mailing list > > IETF carries out its DNS protocol standardization activities within the > DNSEXT working group. The DNSEXT mailing list is > namedroppers@internic.net, also known as comp.protocols.dns.std. This is old and incorrect, for quite some time. The mailing list is namedroppers@ops.ietf.org. Mail from the mailing list may be gatewayed one-way to usenet, but the reverse is not true. [Actually, I've been told that usenet mail is selectively being forwarded back to the list by someone, but it seems "very selectively", as this has happened to only a handful of messages in several months.] > ``Within the scope of this WG are protocol issues, including message > formats, message handling, and data formats,'' the DNSEXT charter says. > Several specific issues have been identified as work items, but other > DNS protocol issues remain clearly within the charter. In particular, > namedroppers is obviously the right forum for implementors to discuss > current and future DNS interoperability problems. > > Unfortunately, namedroppers is being run in a way that slows down, and > sometimes prevents, public communication among DNS implementors. > > Messages to namedroppers are not forwarded directly to subscribers. They > are first sent to Randy Bush. They wait for Bush's review. Bush > discards, edits, or misdirects messages that he doesn't like, and passes > along what's left. > > Here are some specific examples. Many of these incidents involved > opsmail.internic.net, which used some painfully slow, creaky, obsolete > software to distribute messages to subscribers. > > * 1998-12: Bush discarded a message from Richard Sexton commenting > on a proposed extension to MX records, a DNS protocol element. > * 1998-12: Bush edited a message of mine, unilaterally removing a > paragraph at the top that asked why opsmail was so slow. How is > someone supposed to find out what the namedroppers subscribers > think of how the mailing list is run, if complaints to the list > are censored? > * 1999-01: Bush discarded a message from Richard Sexton about client > interpretation of the AA bit, a DNS protocol element, by NSI, the > operators of some well-known DNS TLDs. > * 1999-12: Bush discarded a message of mine > concerning yet > another DNS protocol violation by BIND. ``This belongs in > bind-users@isc.org, not namedroppers,'' Bush told me > , incorrectly. > * 1999-12-31: opsmail finally sent a message that it had received on > 1999-11-04, nearly two months earlier, to a namedroppers > subscription address that had been removed from the list on > 1999-11-25. > * 1999-12-31: I sent an urgent message > to namedroppers > attempting to confirm rumors of a DNS server bug that, if true, > would have been triggered on occasion by my new DNS cache. Someone > else sent a message to namedroppers 14 hours later, and then > another message 4 hours after that; 12 minutes later, Bush sent > those two messages to opsmail; several hours later, opsmail > finally forwarded the messages to me. A day later, I asked Bush > why my message hadn't appeared yet. He finally sent my message to > opsmail three days after I had sent it. I saw a copy from opsmail > several hours after that. > * 2000-01-12: I sent another message > to namedroppers > pointing out a security problem that I had described on bugtraq, > and asking DNSEXT to fix the relevant RFC, which had been > co-written by Bush. My message never appeared on namedroppers. > Bush didn't send me an explanation. I learned much later that Bush > had deliberately misdirected > my message, > sending it to the dnsop mailing list. > * 2000-01-28: I sent a message > to namedroppers > pointing out how Bush's censorship activities had biased DNSEXT > discussions, and a message > to namedroppers > criticizing Bush's unilateral statement of the namedroppers scope. > These messages were direct responses to recent namedroppers > messages, the first by Thomas Narten, the second by Bush. Bush > sent both messages back to me, without saying explicitly what he > had done with them. > * 2000-02-20: I pointed out > on namedroppers > that thousands of system administrators were using dotted-decimal > domain names in MX records. There was some discussion on > namedroppers. Rob Austein and Bill Manning asked for evidence; > Bush claimed that he couldn't find even a single example ``in > almost twenty thousand zones secondaried here from all over the > world.'' A few days later, I sent survey results > to namedroppers > showing that there were approximately fifteen /thousand/ > second-level .com domains with dotted-decimal domain names in > their MX records, usually with no other MX records. My message > never appeared on namedroppers. ``Please report bugs in peoples > zone files to the people with the bugs, not namedroppers,'' Bush > told me. > * 2000-02-21: Bush discarded a message from Dean Anderson > > supporting expansion of the MX protocol definition to allow > dotted-decimal domain names. > * 2000-02-23: I sent another message > to namedroppers > objecting to Bush's censorship. Bush discarded my message. > * 2000-03-12: I sent a message > to namedroppers > asking about DNS query transmission strategy. Bush wrote back: > ``if your question is about the protocol, then fine. if it is > about how the dns operates and how folk's implementations effect > that, then post it to the mailing list for that implementation or > to the dnsop list. i.e. keep your bind bashing off this list.'' I > responded: ``My message asks about an efficiency problem in the > DNS protocol, and gives some illustrative examples. Are you going > to pass my message along to the list, or not?'' Bush discarded my > messages without further comment. > * 2001-03-17: I sent a message > to namedroppers > objecting to a BIND company proposal to modify the DNS protocol. > Bush discarded my message without comment. All of the above is so old there is no point in discussing again. See, for example, http://www.iab.org/Documents/BernsteinAppealResponse.txt > * 2002.11.17: I sent a message > to namedroppers > objecting to Bush and Gudmundsson sending the axfr-clarify > document to the IESG, and summarizing ten > problems with that document. Bush silently discarded my > message. This message was sent to the iesg, ietf and namedroppers mailing list. The message did make it out on at least the iesg mailing list (where I saw a copy), but I do not see it in the namedroppers archive. > * 2002.11.20: I sent a message > to namedroppers > discussing the lack of consensus behind axfr-clarify and > complaining about Bush's censorship. Bush silently discarded my > message. Again, this message was posted to the ietf, iesg and namedroppers list. I see this message did get posted to the iesg list; I do not see it in the namedroppers archive. > * 2002.11.20, continued: I sent a message > to namedroppers > discussing the interoperability problems in axfr-clarify. Bush > silently discarded my message. After Bush wrote (on another list) > ``it is easy to miss and therefore delete mis-posts,'' I sent a > message to > namedroppers saying ``Funny how this happens so often for people > you disagree with'' and reminding Bush that he was causing > problems for newsgroup readers, sublist readers, and ``readers > with private subscription addresses''; Bush allowed that message > through. Again, this message was posted to the ietf, iesg and namedroppers list. I see this message made it do the iesg list; I do not see it in the namedroppers archive. > * 2002.11.20, continued: I sent a message > to namedroppers > discussing the use of separate TCP/UDP ports. Bush silently > discarded my message. This note was allegedely sent to namedroppers (and no where else). It is not in the namedroppers archive. It is noted, however, that other messages from Dan did appear on namedroppers that day. > My subscription address stopped receiving messages from the > namedroppers mailing list. About 40 hours later, I asked Bush what > was going on: > > Is that address still on the list? If not, why not? Does your > software reveal subscription addresses? Does it allow > unconfirmed unsubscription requests? Does it use > non-cryptographic cookies in confirmation notices? If the > address is still on the list, why aren't the outgoing messages > being delivered? Is there some general problem with all > addresses? > > Suddenly the messages all came through. Can't say what this was all about. Temporary mail problems? > * 2002.11.23: I sent a message > and another > message to > namedroppers. Bush promptly forwarded both messages. However, in > the second message, he manually inserted my subscription address, > despite my previous comments about private subscription addresses > and forged unsubscription requests. (Was this malicious, or was it > just mind-bogglingly stupid?) Or perhaps, it was to make it clear to the poster which address the posting was coming from, since there seems to be confusion at times about whether someone is posting from the same address to which they are subscribed. "D. J. Bernstein" writes: > * 2002.11.25: I sent a message > From: "D. J. Bernstein" > To: namedroppers@ops.ietf.org > Cc: sob@harvard.edu > Date: 15 Dec 2002 03:18:14 -0000 > Subject: Re: repeating records > Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. > I've noticed that Randy Bush discarded Len Budney's note on this topic: > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org Not so. Len's note was posted to usenet, not to the namedroppers mailing list. Mail from usenet cannot be assumed to get gatewayed back to the mailing list. Thomas From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Paul Vixie Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 17:46:01 +0000 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: Cc: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers Return-path: To: Thomas Narten In-Reply-To: Message from Thomas Narten of "Fri, 10 Jan 2003 11:24:52 EST." <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Precedence: bulk thomas, et al, i have a bone to pick. while dr. bernstein would most likely say that i am no friend to him nor to his chosen issues, the fact is that his complaint has some validity if you look at it edge-on rather than face-on. > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. > > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. this is just wrong. spamassassin operates at the MUA level, and as such, the originating MTA receives a "final OK" and drops the connection before spamassassin begins its job. the MUA's only choices when dropping mail due to spamassassin's filtering are: issue a new message back to the sender to inform them of the bounce, or silently drop. because most of the mail spamassassin will drop has an invalid sender address, choice #2 is common. for an IETF list, if submitted mail is being dropped, there must be notice back to the sender. because the sender address will generally not be usable, the only possible choice is to issue the rejection at the MTA level. this will require tighter integration of spamassassin into the MTA level than is currently done on randy's system, or indeed, currently done anywhere at all. silent drops are fatal to the IETF's policy of open discourse, and dr. bernstein is right to complain about that aspect of the namedroppers problems he is experiencing. every time one of dr. bernstein's messages is dropped, dr. bernstein's originating MTA should experience an SMTP delivery error and therefore have the option of informing dr. bernstein that such rejection has occurred. one other very minor point: > > I've noticed that Randy Bush discarded Len Budney's note on this topic: > > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org > > Not so. Len's note was posted to usenet, not to the namedroppers > mailing list. Mail from usenet cannot be assumed to get gatewayed back > to the mailing list. as the usenet moderator of comp.protocols.dns.std, i set up a bidirectional gateway which isc operates. this gateway is far from perfect, and many posts have been dropped (silently, of course) over the years, and anyone who wants to really ensure that their words appear on namedroppers should avoid the use of the usenet->namedroppers gateway, and mail their words directly to the namedroppers list. paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Aaron Swartz Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 12:29:32 -0600 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers , iesg@ietf.org, ietf@ietf.org, "D. J. Bernstein" Return-path: To: Thomas Narten In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> X-Mailer: Apple Mail (2.548) Precedence: bulk Thomas Narten wrote: > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit- > policy.txt. This states: """ 4) Any held message that is later approved for distribution on the mailing list should appear on the list as a normal posting (e.g., with the proper sender in the From address, etc.). """ Later, however, you write: >> [...] However, in >> the second message, he manually inserted my subscription >> address, >> despite my previous comments about private subscription >> addresses >> and forged unsubscription requests. (Was this malicious, or was >> it >> just mind-bogglingly stupid?) > > Or perhaps, it was to make it clear to the poster which address the > posting was coming from, since there seems to be confusion at times > about whether someone is posting from the same address to which they > are subscribed. Including someone's private subscription address is not done for a normal posting. Doing it for a held message is a violation of the rule above, no? -- Aaron Swartz [http://www.aaronsw.com/] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Dean Anderson Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 13:41:06 -0500 (EST) Lines: 315 Sender: owner-namedroppers@ops.ietf.org References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "D. J. Bernstein" , , , namedroppers Return-path: X-X-Sender: dean@commander.av8.net To: Thomas Narten In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Precedence: bulk This isn't true. We have been examining the issue, and have found clear evidence that Bernstein's email has been censored and handled differently from other email to namedroppers in recent months, and in the past, prior to changes in the adminstration of namedroppers. We are not yet ready to summarize this evidence. However, it cannot be concluded that there is no such evidence. Dean Anderson On Fri, 10 Jan 2003, Thomas Narten wrote: > Dan Bernstein has been making repeated claims that Randy is censoring > his postings to namedroppers. I took a look at the claims he has made > and here is how I see things. > > Executive summary: I see no evidence that Randy is censoring postings > from Dan. It is the case that some of his messages do not appear to > have made it out on namedroppers, but it is unclear why this is. > Furthermore, given that most of these missing messages were cc'ed to > other lists (i.e., the ietf and iesg lists), there is no evidence of > censorship. > > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. > > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. > > 2) if sent by a subscriber to the mailing list (or by someone in the > known posters list), the message is sent immediately. > > 3) Otherwise, it is queued waiting for approval (or rejection) by the > maling list operators. Both Randy and Mark Kosters see these > rejected postings. Mark has indicated that he has seen no rejected > postings that were not forwarded to the namedroppers mailing list > that should have been. > > It does appear that *some* of the message that Dan has sent to > namedroppers have not appeared on the namedroppers mailing list. But > it is unclear why that happened. At the time of these postings, some > of his other messages have gone through. Also, most of the messages > that didn't appear did appear on other mailing lists that were > cc'ed. It is unclear why those messages did not make it to > namedroppers, but now that Dan's posting address is in the the list of > know posters for namedroppers, and his mail seems to be getting > through, it seems best to just keep an eye on further problems and > investigate them as soon as they happen (e.g, when relevant logs are > available). I see no evidence that Randy (or anyone else) is singling > out anyone's postings for rejection. > > Details on specifics follow. > > "D. J. Bernstein" writes: > > > Bush imposed his mailing-list control methods without IESG approval, in > > violation of RFC 2418, section 3.2. He has been caught engaging in > > content-based censorship several times: > > > http://cr.yp.to/djbdns/namedroppers.html > > > Background > > > > The DNS protocol is covered by various IETF specifications. > > Unfortunately, obeying those specifications is not sufficient to ensure > > interoperability with BIND, in part because the specifications are > > ambiguous or otherwise flawed, and in part because BIND violates the > > specifications in many ways. > > > > These facts have hurt competition, and contributed to BIND's market > > share, at the expense of the users. For example, one site using lbnamed, > > a special-purpose DNS implementation, has had interoperability problems > > with BIND, and has been planning to abandon lbnamed in favor of BIND, > > even though this means giving up some useful features. > > > > In late 1999, after yet another BIND security hole was announced, I > > wrote a free BIND replacement. Interoperability among DNS > > implementations is, of course, essential. I found the IETF > > specifications horribly inadequate. > > > > > > The namedroppers mailing list > > > > IETF carries out its DNS protocol standardization activities within the > > DNSEXT working group. The DNSEXT mailing list is > > namedroppers@internic.net, also known as comp.protocols.dns.std. > > This is old and incorrect, for quite some time. The mailing list is > namedroppers@ops.ietf.org. Mail from the mailing list may be gatewayed > one-way to usenet, but the reverse is not true. [Actually, I've been > told that usenet mail is selectively being forwarded back to the list > by someone, but it seems "very selectively", as this has happened to > only a handful of messages in several months.] > > > ``Within the scope of this WG are protocol issues, including message > > formats, message handling, and data formats,'' the DNSEXT charter says. > > Several specific issues have been identified as work items, but other > > DNS protocol issues remain clearly within the charter. In particular, > > namedroppers is obviously the right forum for implementors to discuss > > current and future DNS interoperability problems. > > > > Unfortunately, namedroppers is being run in a way that slows down, and > > sometimes prevents, public communication among DNS implementors. > > > > Messages to namedroppers are not forwarded directly to subscribers. They > > are first sent to Randy Bush. They wait for Bush's review. Bush > > discards, edits, or misdirects messages that he doesn't like, and passes > > along what's left. > > > > Here are some specific examples. Many of these incidents involved > > opsmail.internic.net, which used some painfully slow, creaky, obsolete > > software to distribute messages to subscribers. > > > > * 1998-12: Bush discarded a message from Richard Sexton commenting > > on a proposed extension to MX records, a DNS protocol element. > > * 1998-12: Bush edited a message of mine, unilaterally removing a > > paragraph at the top that asked why opsmail was so slow. How is > > someone supposed to find out what the namedroppers subscribers > > think of how the mailing list is run, if complaints to the list > > are censored? > > * 1999-01: Bush discarded a message from Richard Sexton about client > > interpretation of the AA bit, a DNS protocol element, by NSI, the > > operators of some well-known DNS TLDs. > > * 1999-12: Bush discarded a message of mine > > concerning yet > > another DNS protocol violation by BIND. ``This belongs in > > bind-users@isc.org, not namedroppers,'' Bush told me > > , incorrectly. > > * 1999-12-31: opsmail finally sent a message that it had received on > > 1999-11-04, nearly two months earlier, to a namedroppers > > subscription address that had been removed from the list on > > 1999-11-25. > > * 1999-12-31: I sent an urgent message > > to namedroppers > > attempting to confirm rumors of a DNS server bug that, if true, > > would have been triggered on occasion by my new DNS cache. Someone > > else sent a message to namedroppers 14 hours later, and then > > another message 4 hours after that; 12 minutes later, Bush sent > > those two messages to opsmail; several hours later, opsmail > > finally forwarded the messages to me. A day later, I asked Bush > > why my message hadn't appeared yet. He finally sent my message to > > opsmail three days after I had sent it. I saw a copy from opsmail > > several hours after that. > > * 2000-01-12: I sent another message > > to namedroppers > > pointing out a security problem that I had described on bugtraq, > > and asking DNSEXT to fix the relevant RFC, which had been > > co-written by Bush. My message never appeared on namedroppers. > > Bush didn't send me an explanation. I learned much later that Bush > > had deliberately misdirected > > my message, > > sending it to the dnsop mailing list. > > * 2000-01-28: I sent a message > > to namedroppers > > pointing out how Bush's censorship activities had biased DNSEXT > > discussions, and a message > > to namedroppers > > criticizing Bush's unilateral statement of the namedroppers scope. > > These messages were direct responses to recent namedroppers > > messages, the first by Thomas Narten, the second by Bush. Bush > > sent both messages back to me, without saying explicitly what he > > had done with them. > > * 2000-02-20: I pointed out > > on namedroppers > > that thousands of system administrators were using dotted-decimal > > domain names in MX records. There was some discussion on > > namedroppers. Rob Austein and Bill Manning asked for evidence; > > Bush claimed that he couldn't find even a single example ``in > > almost twenty thousand zones secondaried here from all over the > > world.'' A few days later, I sent survey results > > to namedroppers > > showing that there were approximately fifteen /thousand/ > > second-level .com domains with dotted-decimal domain names in > > their MX records, usually with no other MX records. My message > > never appeared on namedroppers. ``Please report bugs in peoples > > zone files to the people with the bugs, not namedroppers,'' Bush > > told me. > > * 2000-02-21: Bush discarded a message from Dean Anderson > > > > supporting expansion of the MX protocol definition to allow > > dotted-decimal domain names. > > * 2000-02-23: I sent another message > > to namedroppers > > objecting to Bush's censorship. Bush discarded my message. > > * 2000-03-12: I sent a message > > to namedroppers > > asking about DNS query transmission strategy. Bush wrote back: > > ``if your question is about the protocol, then fine. if it is > > about how the dns operates and how folk's implementations effect > > that, then post it to the mailing list for that implementation or > > to the dnsop list. i.e. keep your bind bashing off this list.'' I > > responded: ``My message asks about an efficiency problem in the > > DNS protocol, and gives some illustrative examples. Are you going > > to pass my message along to the list, or not?'' Bush discarded my > > messages without further comment. > > * 2001-03-17: I sent a message > > to namedroppers > > objecting to a BIND company proposal to modify the DNS protocol. > > Bush discarded my message without comment. > > All of the above is so old there is no point in discussing again. See, > for example, http://www.iab.org/Documents/BernsteinAppealResponse.txt > > > * 2002.11.17: I sent a message > > to namedroppers > > objecting to Bush and Gudmundsson sending the axfr-clarify > > document to the IESG, and summarizing ten > > problems with that document. Bush silently discarded my > > message. > > This message was sent to the iesg, ietf and namedroppers mailing > list. The message did make it out on at least the iesg mailing list > (where I saw a copy), but I do not see it in the namedroppers archive. > > > * 2002.11.20: I sent a message > > to namedroppers > > discussing the lack of consensus behind axfr-clarify and > > complaining about Bush's censorship. Bush silently discarded my > > message. > > Again, this message was posted to the ietf, iesg and namedroppers > list. I see this message did get posted to the iesg list; I do not see > it in the namedroppers archive. > > > * 2002.11.20, continued: I sent a message > > to namedroppers > > discussing the interoperability problems in axfr-clarify. Bush > > silently discarded my message. After Bush wrote (on another list) > > ``it is easy to miss and therefore delete mis-posts,'' I sent a > > message to > > namedroppers saying ``Funny how this happens so often for people > > you disagree with'' and reminding Bush that he was causing > > problems for newsgroup readers, sublist readers, and ``readers > > with private subscription addresses''; Bush allowed that message > > through. > > Again, this message was posted to the ietf, iesg and namedroppers > list. I see this message made it do the iesg list; I do not see it in > the namedroppers archive. > > > * 2002.11.20, continued: I sent a message > > to namedroppers > > discussing the use of separate TCP/UDP ports. Bush silently > > discarded my message. > > This note was allegedely sent to namedroppers (and no where else). It > is not in the namedroppers archive. It is noted, however, that other > messages from Dan did appear on namedroppers that day. > > > My subscription address stopped receiving messages from the > > namedroppers mailing list. About 40 hours later, I asked Bush what > > was going on: > > > > Is that address still on the list? If not, why not? Does your > > software reveal subscription addresses? Does it allow > > unconfirmed unsubscription requests? Does it use > > non-cryptographic cookies in confirmation notices? If the > > address is still on the list, why aren't the outgoing messages > > being delivered? Is there some general problem with all > > addresses? > > > > Suddenly the messages all came through. > > Can't say what this was all about. Temporary mail problems? > > > * 2002.11.23: I sent a message > > and another > > message to > > namedroppers. Bush promptly forwarded both messages. However, in > > the second message, he manually inserted my subscription address, > > despite my previous comments about private subscription addresses > > and forged unsubscription requests. (Was this malicious, or was it > > just mind-bogglingly stupid?) > > Or perhaps, it was to make it clear to the poster which address the > posting was coming from, since there seems to be confusion at times > about whether someone is posting from the same address to which they > are subscribed. > > "D. J. Bernstein" writes: > > > * 2002.11.25: I sent a message > > From: "D. J. Bernstein" > > To: namedroppers@ops.ietf.org > > Cc: sob@harvard.edu > > Date: 15 Dec 2002 03:18:14 -0000 > > Subject: Re: repeating records > > Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. > > > I've noticed that Randy Bush discarded Len Budney's note on this topic: > > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org > > Not so. Len's note was posted to usenet, not to the namedroppers > mailing list. Mail from usenet cannot be assumed to get gatewayed back > to the mailing list. > > 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 13:30:51 -0700 (MST) Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <20030110174601.4A501379FBB@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: , , Return-path: To: In-Reply-To: <20030110174601.4A501379FBB@as.vix.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.5) Precedence: bulk Interesting since others in this thread also seem to sensor or refuse valid requests made to them... its amazing we all can't just get along and "do the right thing (tm)" which is to help build a robust global system.. much sadness because of these childish activities and lack of acceptance of human traits..... Q The gadget geek > thomas, et al, > > i have a bone to pick. while dr. bernstein would most likely say that > i am no friend to him nor to his chosen issues, the fact is that his > complaint has some validity if you look at it edge-on rather than > face-on. > >> Namedroppers is a posters-only mailing list that is run in conformance >> with the policies outlined in >> http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. >> >> Specifically, all mail sent to namedroppers is: >> >> 1) first run through spamassassin. Mail that is rejected here is not >> archived, as the number of such messages is large. All mail sent to >> mailing lists on the server hosting namedroppers is run though >> spamassassin, so this is not a namedroppers-specific procedure. > > this is just wrong. spamassassin operates at the MUA level, and as > such, the originating MTA receives a "final OK" and drops the > connection before spamassassin begins its job. the MUA's only choices > when dropping mail due to spamassassin's filtering are: issue a new > message back to the sender to inform them of the bounce, or silently > drop. because most of the mail spamassassin will drop has an invalid > sender address, choice #2 is common. > > for an IETF list, if submitted mail is being dropped, there must be > notice back to the sender. because the sender address will generally > not be usable, the only possible choice is to issue the rejection at > the MTA level. this will require tighter integration of spamassassin > into the MTA level than is currently done on randy's system, or indeed, > currently done anywhere at all. > > silent drops are fatal to the IETF's policy of open discourse, and dr. > bernstein is right to complain about that aspect of the namedroppers > problems he is experiencing. every time one of dr. bernstein's > messages is dropped, dr. bernstein's originating MTA should experience > an SMTP delivery error and therefore have the option of informing dr. > bernstein that such rejection has occurred. > > one other very minor point: > >> > I've noticed that Randy Bush discarded Len Budney's note on this >> > topic: >> > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org >> >> Not so. Len's note was posted to usenet, not to the namedroppers >> mailing list. Mail from usenet cannot be assumed to get gatewayed back >> to the mailing list. > > as the usenet moderator of comp.protocols.dns.std, i set up a > bidirectional gateway which isc operates. this gateway is far from > perfect, and many posts have been dropped (silently, of course) over > the years, and anyone who wants to really ensure that their words > appear on namedroppers should avoid the use of the usenet->namedroppers > gateway, and mail their words directly to the namedroppers list. > > paul > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Eliot Lear Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 15:40:10 -0800 Lines: 79 Sender: owner-ietf@ietf.org References: <20030110174601.4A501379FBB@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ietf@ietf.org, iesg@ietf.org, namedroppers Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en To: Paul Vixie In-Reply-To: <20030110174601.4A501379FBB@as.vix.com> Content-Transfer-Encoding: 7bit Precedence: bulk Paul, I would settle for the message being logged as dropped on some web site. Or, if disk space is really an issue, I would also find it acceptable to have a global IETF whitelist and bounce mail from people who are not on it. That having been said, I have no problem with the message returning as a bounce above the MTA level, so long a sa bounce is returned. That means that you have to have a valid return address. I don't believe the process has to be so open such that we should respond to invalid return addresses. Eliot Paul Vixie wrote: > thomas, et al, > > i have a bone to pick. while dr. bernstein would most likely say that > i am no friend to him nor to his chosen issues, the fact is that his > complaint has some validity if you look at it edge-on rather than face-on. > > >>Namedroppers is a posters-only mailing list that is run in conformance >>with the policies outlined in >>http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. >> >>Specifically, all mail sent to namedroppers is: >> >>1) first run through spamassassin. Mail that is rejected here is not >> archived, as the number of such messages is large. All mail sent to >> mailing lists on the server hosting namedroppers is run though >> spamassassin, so this is not a namedroppers-specific procedure. > > > this is just wrong. spamassassin operates at the MUA level, and as such, > the originating MTA receives a "final OK" and drops the connection before > spamassassin begins its job. the MUA's only choices when dropping mail > due to spamassassin's filtering are: issue a new message back to the sender > to inform them of the bounce, or silently drop. because most of the mail > spamassassin will drop has an invalid sender address, choice #2 is common. > > for an IETF list, if submitted mail is being dropped, there must be notice > back to the sender. because the sender address will generally not be usable, > the only possible choice is to issue the rejection at the MTA level. this > will require tighter integration of spamassassin into the MTA level than is > currently done on randy's system, or indeed, currently done anywhere at all. > > silent drops are fatal to the IETF's policy of open discourse, and dr. > bernstein is right to complain about that aspect of the namedroppers problems > he is experiencing. every time one of dr. bernstein's messages is dropped, > dr. bernstein's originating MTA should experience an SMTP delivery error and > therefore have the option of informing dr. bernstein that such rejection has > occurred. > > one other very minor point: > > >>>I've noticed that Randy Bush discarded Len Budney's note on this topic: >>>http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org >> >>Not so. Len's note was posted to usenet, not to the namedroppers >>mailing list. Mail from usenet cannot be assumed to get gatewayed back >>to the mailing list. > > > as the usenet moderator of comp.protocols.dns.std, i set up a bidirectional > gateway which isc operates. this gateway is far from perfect, and many posts > have been dropped (silently, of course) over the years, and anyone who wants > to really ensure that their words appear on namedroppers should avoid the use > of the usenet->namedroppers gateway, and mail their words directly to the > namedroppers list. > > paul > > > From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Keith Moore Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 19:59:58 -0500 Lines: 22 Sender: owner-ietf@ietf.org References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: moore@cs.utk.edu, djb@cr.yp.to, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Return-path: To: Thomas Narten In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Content-Transfer-Encoding: 7bit Precedence: bulk > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. SpamAssissin needs to be shot. Most of its criteria are really poorly chosen. Even if its criteria are good at identifying spam on a large scale (with few false positives) that doesn't mean they will work well for a narrowly-focused discussion. In my experience SpamAssassin has too high a false positive rate to be trusted without human review as a backup. Keith p.s. regarding messages that did not make it to the namedroppers archive - are the IETF archives still using to/cc message headers to decide which archive a message should be stored in? if so, is it possible that a message which was sent to multiple lists might be archived in only one of those lists? From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: bert hubert Subject: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 13:15:40 +0100 Lines: 23 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.3.28i Precedence: bulk In a refreshing change, here is a question about DNS. I'm wondering if anybody knows of any client library actually using additional/authority records in answers to recursion desired/recursion available questions, with the exception of the SOA negative presence indication. Thanks. Regards, bert hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Rob Austein Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 11:40:19 -0500 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <20030111121540.GA22025@outpost.ds9a.nl> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: To: namedroppers@ops.ietf.org In-Reply-To: <20030111121540.GA22025@outpost.ds9a.nl> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) Precedence: bulk At Sat, 11 Jan 2003 13:15:40 +0100, bert hubert wrote: > > In a refreshing change, here is a question about DNS. Thank you! > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. Additional for sure: think about QTYPE=MX. Dunno about authority: offhand I can't remember any use for it, but that doesn't prove that somebody else hasn't got one. --Rob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Paul Vixie Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 18:33:49 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from bert hubert of "Sat, 11 Jan 2003 13:15:40 +0100." <20030111121540.GA22025@outpost.ds9a.nl> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Precedence: bulk > In a refreshing change, here is a question about DNS. > > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. sure. sendmail's internal getmxrr does this, to try to get the MX and A from a single dns transaction. as far as i know, so does kerberos's internal getsrvbyname. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: bert hubert Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 20:12:24 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111183349.553C0379FBB@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org Return-path: To: Paul Vixie Content-Disposition: inline In-Reply-To: <20030111183349.553C0379FBB@as.vix.com> User-Agent: Mutt/1.3.28i Precedence: bulk On Sat, Jan 11, 2003 at 06:33:49PM +0000, Paul Vixie wrote: > sure. sendmail's internal getmxrr does this, to try to get the MX and A > from a single dns transaction. as far as i know, so does kerberos's > internal getsrvbyname. Thanks, also to Rob. Indeed, I only forgot about that one because my own boneheaded mailer did not take advantage from that at one point. But I wonder about the utility of authority in this case - I've already seen the powerdns recursor, a work in progress, spit out the weirdest things. An example is www.bibleinfo.org which defines its own NS records with a 10 second TTL. After those are passed, the 'best' NS records are the ORG ones, which are then attached to the answer, leading to an overly large packet. [btw, I wonder why the ORG NS records are in COM? Seems silly] A simple solution to that is not allowing a child to lower the TTL of existing records, but that does not solve the root issue of the silliness of adding the 'best' NS records known. Was there a non-human rationale to adding those? Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Paul Vixie Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 19:45:56 +0000 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from bert hubert of "Sat, 11 Jan 2003 20:12:24 +0100." <20030111191224.GA30869@outpost.ds9a.nl> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Precedence: bulk > An example is www.bibleinfo.org which defines its own NS records with a 10 > second TTL. After those are passed, the 'best' NS records are the ORG ones, > which are then attached to the answer, leading to an overly large packet. > > A simple solution to that is not allowing a child to lower the TTL of > existing records, but that does not solve the root issue of the silliness of > adding the 'best' NS records known. Was there a non-human rationale to > adding those? the child zone owns the delegation point. the parent's zone-bottom NS RR's are not authoritative in the parent, they are just hints/glue. the child's data, no matter how icky the TTL's are, is what you have to keep, TTL and all. you could keep an opaqued copy of the parent's hints/glue around, so that when the child's NS RRset expires, you can go back to the glue that got you to the child in the first place. but you have to keep going back to the child. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "D. J. Bernstein" Subject: Re: does anybody use additional/authority records on RD/RA replies Date: 11 Jan 2003 20:04:42 -0000 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111164019.BFC7618E8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. To: namedroppers@ops.ietf.org Content-Disposition: inline Precedence: bulk Rob Austein writes: > Additional for sure: think about QTYPE=MX. Clients have to be prepared to ask for A records in a new DNS query. The MX response often doesn't have any additional data. It is, of course, safe for a cache to leave out authority and additional records. dnscache has always done this; BIND 9 can now do it, except for SOA records, with the ``minimal-responses'' option. One client---sendmail---tries to skip the A query by caching A records from the MX response. I'm amused by the ``save network traffic'' excuse for this complication. If you really care about DNS traffic, why aren't you running a real DNS cache on the same machine? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Bruce Campbell Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 22:33:48 +0100 (CET) Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <20030111200442.19176.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org In-Reply-To: <20030111200442.19176.qmail@cr.yp.to> Precedence: bulk On 11 Jan 2003, D. J. Bernstein wrote: > Rob Austein writes: > > Additional for sure: think about QTYPE=MX. > > One client---sendmail---tries to skip the A query by caching A records > from the MX response. I'm amused by the ``save network traffic'' excuse > for this complication. If you really care about DNS traffic, why aren't > you running a real DNS cache on the same machine? It is possible, especially with the example that you've posted, that the design decision that lead to trying to obtain an 'A' from the additional section of a 'MX' answer was made at a time when Internet links were relatively expensive, and/or at a time when the memory footprint of a DNS cache was not available on every machine. Of course nowadays, the design of a new piece of software doesn't have to take into account costs incurred by the entity running their software as bandwidth/memory/cpu is so cheap, mores the pity. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Mark.Andrews@isc.org Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sun, 12 Jan 2003 10:32:32 +1100 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <20030111121540.GA22025@outpost.ds9a.nl> Cc: namedroppers@ops.ietf.org Return-path: To: bert hubert In-reply-to: Your message of "Sat, 11 Jan 2003 13:15:40 BST." <20030111121540.GA22025@outpost.ds9a.nl> Precedence: bulk > In a refreshing change, here is a question about DNS. > > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. > > Thanks. > > Regards, > > bert hubert > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > http://netherlabs.nl Consulting > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: The update code in libresolv will take advantage of the NS RRset if it is there along with the address records in the additional section when determining the zone a particular domain name belongs to. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Michael Milligan Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 11 Jan 2003 16:43:10 -0700 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111183349.553C0379FBB@as.vix.com> <20030111191224.GA30869@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 To: bert hubert In-Reply-To: <20030111191224.GA30869@outpost.ds9a.nl> Precedence: bulk bert hubert wrote: > > [btw, I wonder why the ORG NS records are in COM? Seems silly] They are not "in COM" of course... the gTLD servers, which are authoritative for com, are also still authoritative for org. I'm sure that's the case only for the transition of org to Afilias, but you never know how long QA can take when it comes to the gTLD servers... ;-) Side note: I do find it interesting that a.gtld-servers.net and g.gtld-servers.net have TTLs of 172800 (2 days) for the org NS record set and the rest of the gTLD servers have 518400 (6 days). Regards, Mike -- Michael Milligan -- Free Agent -- milli@acmeps.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Michael Richardson Subject: the DS deployment problem Date: Sun, 12 Jan 2003 17:07:16 -0800 Lines: 83 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Return-path: To: namedroppers Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- So, I didn't realize that there was already a document specifying some more details about how to handle DS for the ancestor problem. But that -12 of the DS draft now has: 313a315,333 > 2.2.1.2 Special processing when child and an ancestor share server > > When a child zone and a ancestor other than parent share an > authorative server, a DS aware server MUST answer with information > from child zone, as specified in section 2.2.1.1. This is to prevent > the server to be marked as lame for child. > > This answer can cause problem for a DS aware resolver that is > traversing this branch of the DNS tree for the first time. The > resolver is expecting to get back either DS record or a delegation > information. The SOA with same name as QNAME informs the resolver > that the answer orignated from the zone below the one where the DS > resides. At this point the resolver has no information on how to get > from the ancestor to the parent. In this case the resolver SHOULD > attempt to fetch the delegation information by issuing a query with a > QNAME one label shorter and type NS. This will yield the NS set for > the parent, allowing the resolver to query for the DS record. > I want to make sure that I understand this. It seemed too simple to me! Given two name servers: NS-A NS-B +------------+ +--------------+ | example.| | b.example. | |a.b.example.| | | +------------+ +--------------+ with records: example. NS NS-A b.example. NS NS-B SOA foo SOA bar KEY xxxxx KEY yyyyy b.example. NS NS-B a.b.example. DS hash(zzzzz) DS hash(yyyyy) NS NS-A a.b.example. NS NS-A SOA baz KEY zzzzz So, if I ask NS-A, for a.b.example DS, then I get "a.b.example. SOA baz", and I get no other information, because the DS doesn't reside there. I do not get "b.example. NS NS-B", because I didn't ask for that. So, the instructions say, as for "b.example. NS", and we can make progress. Now, part of the problem was, what if there was a recursive resolving DNS server in front of the querier, that didn't know about DS. And one was forced to use this. (A proxy DNS server in a firewall for instance) So, I think that this doesn't screw anything up as well. I think, that one has to do queries with one shorter label recursively in the situation where maybe a server is authoritative for example. and a.b.c.example. I may be wrong here - I have to think about it some more. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiIRQIqHRg3pndX9AQHFsgQAqmU8xrXkjxyoWzgNNvtZm49LesalGIVi ydOHG1KmjKYfTAlWea7Ux/Iq3zcpq/XPoVv1WbpTf/Jyw1wZWbeYmNmZaYfojt2P XSO4++CbdY7+iVdp2sUv0zYwp7ZiMBtItpNHuMJD30gxuSHfKAZtHVODDGZujElq 51L/Z0h4rI8= =QFri -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: the DS deployment problem Date: Sun, 12 Jan 2003 21:01:02 -0500 Lines: 83 Sender: owner-namedroppers@ops.ietf.org References: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-path: X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Michael Richardson , namedroppers In-Reply-To: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> Precedence: bulk At 20:07 2003-01-12, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >So, I didn't realize that there was already a document specifying some more >details about how to handle DS for the ancestor problem. But that -12 of the >DS draft now has: > >313a315,333 > > 2.2.1.2 Special processing when child and an ancestor share server > > > > When a child zone and a ancestor other than parent share an > > authorative server, a DS aware server MUST answer with information > > from child zone, as specified in section 2.2.1.1. This is to prevent > > the server to be marked as lame for child. > > > > This answer can cause problem for a DS aware resolver that is > > traversing this branch of the DNS tree for the first time. The > > resolver is expecting to get back either DS record or a delegation > > information. The SOA with same name as QNAME informs the resolver > > that the answer orignated from the zone below the one where the DS > > resides. At this point the resolver has no information on how to get > > from the ancestor to the parent. In this case the resolver SHOULD > > attempt to fetch the delegation information by issuing a query with a > > QNAME one label shorter and type NS. This will yield the NS set for > > the parent, allowing the resolver to query for the DS record. > > > >I want to make sure that I understand this. It seemed too simple to me! Thank you simple is good. >Given two name servers: > > NS-A NS-B > +------------+ +--------------+ > | example.| | b.example. | > |a.b.example.| | | > +------------+ +--------------+ > >with records: > > example. NS NS-A b.example. NS NS-B > SOA foo SOA bar > KEY xxxxx KEY yyyyy > b.example. NS NS-B a.b.example. DS hash(zzzzz) > DS hash(yyyyy) NS NS-A > a.b.example. NS NS-A > SOA baz > KEY zzzzz > >So, if I ask NS-A, for a.b.example DS, then I get "a.b.example. SOA baz", and >I get no other information, because the DS doesn't reside there. >I do not get "b.example. NS NS-B", because I didn't ask for that. So, the >instructions say, as for "b.example. NS", and we can make progress. > >Now, part of the problem was, what if there was a recursive resolving DNS >server in front of the querier, that didn't know about DS. And one was forced >to use this. (A proxy DNS server in a firewall for instance) > >So, I think that this doesn't screw anything up as well. > >I think, that one has to do queries with one shorter label recursively in the >situation where maybe a server is authoritative for example. and >a.b.c.example. I may be wrong here - I have to think about it some more. This problem has been flagged as a DS problem but it is not, it is a general DNSSEC problem. In your example if you had asked for "a.b.example. KEY" you got back signed answer, but the resolver has to go back and construct the key chain from . to a.b.example. in order to verify the result. If there had not been a ancestor in the path, the key chain is constructed while traversing down the referral chain. 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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Bill Manning Subject: Re: commens on draft-dnsext-opcode-discover-01.txt Date: Mon, 13 Jan 2003 10:49:35 -0800 (PST) Lines: 148 Sender: owner-namedroppers@ops.ietf.org References: <20030107093105.12ade898.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, moore@cs.utk.edu Return-path: In-Reply-To: <20030107093105.12ade898.moore@cs.utk.edu> from Keith Moore at "Jan 7, 3 09:31:05 am" To: moore@cs.utk.edu (Keith Moore) X-Mailer: ELM [version 2.4ME+ PL39 (25)] Precedence: bulk % Note: I'm reading this as if it's a draft protocol specification % rather than as if it's intended as an informational or experimental % document. Even if the latter is intended, some amount of clarification % seems in order. Thanks for your comments. Note that it is clearly -NOT- expected to be a draft protocol specification. This is the documentation of a set of experiments that were run in 1998/1999 and some of the lessons learned. % 1. use of SRV to implement getservbyname % % It is not appropriate to use SRV lookups to implement getservbyname(). Why? Its not forbidden and it can be made to work. % This would change the behavior of nearly every protocol on the Internet % without considering the impact on the protocol or applications that use % it. Use of SRV MUST be determined on a per-protocol or per-application % basis. Where your references to "it" is the call getservbyname() correct? % Furthermore SRV was intended to delegate services for specific DNS domains, % and getservbyname() doesn't provide a way to input the domain for which % the SRV query is being made. Trying to use SRV as a generic way to look % up "well known ports" independent of domain is overloading the SRV RR type. Not really. % That,and trying to use the network to look up constants never was a good % idea, not in the context of YP/NIS or anything else. I've seen too many % programs fail because getservbyname() was implemented using NIS, and the % NIS server was down. It's not as if protocol implementors don't know what % port numbers to use anyway. If it's reasonable for a protocol implementation % to include string constants like "MAIL FROM" or "POST", then it's reasonable % for that protocol implementation to include integer constants like htons(25) % or htons(80). The experiment made the presumption that the constants being lookedup were available from the system being queried. Extrapolation to over network lookups was done as proof of concept and to explore the ramifications thereof. % 2. under section 2, "method", "Example usage for gethostby{name,addr}-style % requestors:" % % it's not at all clear why "the zone name of the enclosing in-addr.arpa, % ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in % gethostbyname ) or why queries for a particular NAME should only be sent % to servers that are authoritative for the enclosing ADDRESS domain. % % Is this really what is intended or is it just poor wording? It reads % as if you're trying to make the results of DNS lookups vary according % to location. Correct. the results were to vary based on location/topology. % 3. same section % % "Once one learns a host's FQDN by the above means, repeat the process % for discovering the closest enclosing authoritative server of such % local name." % % the idea that a host has "a" FQDN seems anachronistic at best. hosts have % zero or more addresses assigned to them at any particular time; each % address may be associated with zero or more FQDNs. the address-to-host % bindings may be short- or long-lived. in general there is no way that the % network can be expected to know whether a particular FQDN is any kind of % "distinguished name" for a host. the host has to be configured to know % this on its own. the host (knowing its FQDN) responds to requests by sending its FQDN. One of the preconditions of the experiment is that each participating node is "imprinted" with an FQDN and some key material that is tied to that FQDN. % 4. regarding disconnected networks % % NO server -- whether multicast or not, whether using DISCOVER or not, % whether using the DNS port or not, whether using the DNS protocl or not -- % should be answering queries as if it were authoritative for any DNS zone % for which that server is not authoritative. The result will inevitiably % be that such results are leaked into, and mixed with, results from % legitimate DNS servers. a network which appears isolated to one host % in a network may not be isolated to another host in the same network. Perhaps we should include the TBDS final report in the references. The experiment presumes that each node is authoritative for its point in the DNS heirarchy. This draft does not presume to answer authoritativly for any part of the DNS. It presumes that the caching servers will cache information they receive, just as happens now. % if you want "disconnected" servers to respond to queries for FQDNs then % those servers need to be authoritative for those FQDNs, and they need % to produce results which are consistent with the other servers for those % FQDNs. if some of those servers are on isolated networks and others are % on the global internet, this is not a problem as long as the rules for % serial numbers are followed. DNS can cope with different servers % returning different results as long as those servers have different % serial numbers and single-copy serializability is maintained. Yes. % If a host which is authoritative for one or more FQDNs that are assigned % to a host migrates from one network to another, or for whatever reason % acquires a new address and/or needs to change its RRs, that host can update % its RRs on its stub server and increment the serial # for that zone. If % and when the host has connectivity to the (other) advertised servers for % that zone, it should update those servers. But even if the host finds itself % on an isolated network there is no problem with its updating its own zone % and incrementing the serial number, perhaps multiple times, as long as it % updates the slave servers whenever it is possible to do so. Of course there % are operational concerns associated with advertising RRs that point to % addresses that are not reachable, but we generally expect protocols to be % robust when hosts are not reachable anyway. Appropriate assignment of TTLs % is the best solution here, and the host is in the best position to know % whether its RRs should have long or short TTLs (e.g. whether it is stable % or nomadic). The model here is that the FQDN does not change based on location in the topology. The dynamic update features existant in todays protocols are largely intact from the old work. It is true that dynamic dns work has evolved since this experiment was run. % -- % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % archive: % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Edward Lewis Subject: Re: the DS deployment problem Date: Mon, 13 Jan 2003 11:02:28 -0800 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> To: Michael Richardson Precedence: bulk At 17:07 -0800 1/12/03, Michael Richardson wrote: >So, I didn't realize that there was already a document specifying some more >details about how to handle DS for the ancestor problem. But that -12 of the >DS draft now has: I sent some suggested text for the section in a message: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02256.html But there's been no discussion of it. (The text was prompted by some confusion a few of us had regarding great-great-*-great-grandparents and the 'strip a label' instruction.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Keith Moore Subject: Re: commens on draft-dnsext-opcode-discover-01.txt Date: Mon, 13 Jan 2003 14:09:34 -0500 Lines: 134 Sender: owner-namedroppers@ops.ietf.org Cc: moore@cs.utk.edu, namedroppers@ops.ietf.org Return-path: X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Bill Manning Precedence: bulk On Mon, 13 Jan 2003 10:49:35 -0800 (PST) Bill Manning wrote: > % Note: I'm reading this as if it's a draft protocol specification > % rather than as if it's intended as an informational or experimental > % document. Even if the latter is intended, some amount of clarification > % seems in order. > > > Thanks for your comments. Note that it is clearly -NOT- > expected to be a draft protocol specification. This is > the documentation of a set of experiments that were run in > 1998/1999 and some of the lessons learned. > > % 1. use of SRV to implement getservbyname > % > % It is not appropriate to use SRV lookups to implement getservbyname(). > > Why? Its not forbidden and it can be made to work. a) it's changing the behavior of existing applications that expect well-known port numbers. b) it's violating the SRV RFC, which states that each application needs to define how SRV is used. > % This would change the behavior of nearly every protocol on the Internet > % without considering the impact on the protocol or applications that use > % it. Use of SRV MUST be determined on a per-protocol or per-application > % basis. > > Where your references to "it" is the call getservbyname() correct yes, but it's also true for SRV in general. > % Furthermore SRV was intended to delegate services for specific DNS domains, > % and getservbyname() doesn't provide a way to input the domain for which > % the SRV query is being made. Trying to use SRV as a generic way to look > % up "well known ports" independent of domain is overloading the SRV RR type. > > Not really. I strongly and emphatically disagree. > % That,and trying to use the network to look up constants never was a good > % idea, not in the context of YP/NIS or anything else. I've seen too many > % programs fail because getservbyname() was implemented using NIS, and the > % NIS server was down. It's not as if protocol implementors don't know what > % port numbers to use anyway. If it's reasonable for a protocol implementation > % to include string constants like "MAIL FROM" or "POST", then it's reasonable > % for that protocol implementation to include integer constants like htons(25) > % or htons(80). > > The experiment made the presumption that the constants being lookedup > were available from the system being queried. Extrapolation to over > network lookups was done as proof of concept and to explore the > ramifications thereof. I doubt your experiments were of sufficient scale to show the problems. > > % 2. under section 2, "method", "Example usage for gethostby{name,addr}-style > % requestors:" > % > % it's not at all clear why "the zone name of the enclosing in-addr.arpa, > % ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in > % gethostbyname ) or why queries for a particular NAME should only be sent > % to servers that are authoritative for the enclosing ADDRESS domain. > % > % Is this really what is intended or is it just poor wording? It reads > % as if you're trying to make the results of DNS lookups vary according > % to location. > > Correct. the results were to vary based on location/topology. well, that's another lousy idea. many applications depend on DNS names producing consistent results from multiple locations in the Internet. > % 3. same section > % > % "Once one learns a host's FQDN by the above means, repeat the process > % for discovering the closest enclosing authoritative server of such > % local name." > % > % the idea that a host has "a" FQDN seems anachronistic at best. hosts have > % zero or more addresses assigned to them at any particular time; each > % address may be associated with zero or more FQDNs. the address-to-host > % bindings may be short- or long-lived. in general there is no way that the > % network can be expected to know whether a particular FQDN is any kind of > % "distinguished name" for a host. the host has to be configured to know > % this on its own. > > > the host (knowing its FQDN) responds to requests by sending > its FQDN. One of the preconditions of the experiment is that > each participating node is "imprinted" with an FQDN and some > key material that is tied to that FQDN. again the idea that a host has "a" FQDN seems anachronistic. if you can generalize this to something like "a server on a host may be made authoritative for zero or more FQDNs" then it might be more useful. > > % 4. regarding disconnected networks > % > % NO server -- whether multicast or not, whether using DISCOVER or not, > % whether using the DNS port or not, whether using the DNS protocl or not -- > % should be answering queries as if it were authoritative for any DNS zone > % for which that server is not authoritative. The result will inevitiably > % be that such results are leaked into, and mixed with, results from > % legitimate DNS servers. a network which appears isolated to one host > % in a network may not be isolated to another host in the same network. > > > Perhaps we should include the TBDS final report in the references. > The experiment presumes that each node is authoritative for its > point in the DNS heirarchy. This draft does not presume to answer > authoritativly for any part of the DNS. It presumes that the caching > servers will cache information they receive, just as happens now. some of additional context would help the draft immensely. stating your goals, assumptions, the constraints you imposed, the limitations of your work, all seem appropriate for a description of an experiment. Keith -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Bill Manning Subject: Re: commens on draft-dnsext-opcode-discover-01.txt Date: Mon, 13 Jan 2003 11:37:43 -0800 (PST) Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <200301131909.h0DJ9YA09218@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bmanning@ISI.EDU, moore@cs.utk.edu, namedroppers@ops.ietf.org Return-path: In-Reply-To: <200301131909.h0DJ9YA09218@astro.cs.utk.edu> from Keith Moore at "Jan 13, 3 02:09:34 pm" To: moore@cs.utk.edu (Keith Moore) X-Mailer: ELM [version 2.4ME+ PL39 (25)] Precedence: bulk % > Thanks for your comments. Note that it is clearly -NOT- % > expected to be a draft protocol specification. This is % > the documentation of a set of experiments that were run in % > 1998/1999 and some of the lessons learned. % > % > % 1. use of SRV to implement getservbyname % > % % > % It is not appropriate to use SRV lookups to implement getservbyname(). % > % > Why? Its not forbidden and it can be made to work. % % a) it's changing the behavior of existing applications that expect % well-known port numbers. % % b) it's violating the SRV RFC, which states that each application needs % to define how SRV is used. it was an experiment. changing behaviour is one thing that experiments do. and wrt SRV, we defined how SRV is used for DNS. % > % the SRV query is being made. Trying to use SRV as a generic way to look % > % up "well known ports" independent of domain is overloading the SRV RR type. % > % > Not really. % % I strongly and emphatically disagree. thats allowed. % > The experiment made the presumption that the constants being lookedup % > were available from the system being queried. Extrapolation to over % > network lookups was done as proof of concept and to explore the % > ramifications thereof. % % I doubt your experiments were of sufficient scale to show the problems. that kind of presumes a single suite of problems to be shown. we found several and identified ways to overcome some of them. % > Correct. the results were to vary based on location/topology. % % well, that's another lousy idea. many applications depend on DNS names % producing consistent results from multiple locations in the Internet. your concept of "lousy" ideas may even be relevent. % > the host (knowing its FQDN) responds to requests by sending % > its FQDN. One of the preconditions of the experiment is that % > each participating node is "imprinted" with an FQDN and some % > key material that is tied to that FQDN. % % again the idea that a host has "a" FQDN seems anachronistic. % if you can generalize this to something like "a server on a host may be % made authoritative for zero or more FQDNs" % then it might be more useful. so set the wayback machine for 1998 and we'll be happy to redo the work. % > Perhaps we should include the TBDS final report in the references. % > The experiment presumes that each node is authoritative for its % > point in the DNS heirarchy. This draft does not presume to answer % > authoritativly for any part of the DNS. It presumes that the caching % > servers will cache information they receive, just as happens now. % % some of additional context would help the draft immensely. % stating your goals, assumptions, the constraints you imposed, the % limitations of your work, all seem appropriate for a description of an % experiment. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Keith Moore Subject: Re: commens on draft-dnsext-opcode-discover-01.txt Date: Mon, 13 Jan 2003 14:51:05 -0500 Lines: 38 Sender: owner-namedroppers@ops.ietf.org Cc: moore@cs.utk.edu, namedroppers@ops.ietf.org Return-path: X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Bill Manning Precedence: bulk > % > % It is not appropriate to use SRV lookups to implement getservbyname(). > % > > % > Why? Its not forbidden and it can be made to work. > % > % a) it's changing the behavior of existing applications that expect > % well-known port numbers. > % > % b) it's violating the SRV RFC, which states that each application needs > % to define how SRV is used. > > it was an experiment. changing behaviour is one thing that experiments > do. and wrt SRV, we defined how SRV is used for DNS. silly me. I thought RFC 2782 defined how SRV was used for DNS, and that the RFCs for applications defined which port numbers they use. >From RFC 2782: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification. -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Paul Vixie Subject: Re: commens on draft-dnsext-opcode-discover-01.txt Date: Mon, 13 Jan 2003 20:35:17 +0000 Lines: 9 Sender: owner-namedroppers@ops.ietf.org References: Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from Keith Moore of "Mon, 13 Jan 2003 14:51:05 EST." <200301131951.h0DJp5A09369@astro.cs.utk.edu> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Precedence: bulk i thought i'd let everybody know that after some deep talks with stuart cheshire over at apple, i am withdrawing my support and co-authorship of the DISCOVER draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Michael Richardson Subject: Re: the DS deployment problem Date: Mon, 13 Jan 2003 14:32:17 -0800 Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Return-path: To: namedroppers In-reply-to: Your message of "Mon, 13 Jan 2003 11:02:28 PST." Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis writes: Edward> At 17:07 -0800 1/12/03, Michael Richardson wrote: >> So, I didn't realize that there was already a document specifying some more >> details about how to handle DS for the ancestor problem. But that -12 of the >> DS draft now has: Edward> I sent some suggested text for the section in a message: Edward> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02256.html Edward> But there's been no discussion of it. (The text was prompted by some Edward> confusion a few of us had regarding great-great-*-great-grandparents Edward> and the 'strip a label' instruction.) Here are your comments, again: Edward> 1) If the server is authoritative for the zone that holds the DS RR Edward> set (i.e., the zone that delegates away, aka the "parent" Edward> zone), the response contains the DS RR set as an authoritative answer. Edward> 2) If the server is offering recursive service, the server performs Edward> the query itself (according to the rules for resolvers described Edward> below) and returns it's findings. Edward> 3) If the server is authoritative for the zone that holds the Edward> 's SOA RR set, the response is an authoritative negative answer Edward> as described in 2.2.1.1. Edward> 4) If the server is authoritative for a zone above the QNAME, a Edward> referral to a more enclosing zone's servers is made. Edward> 5) If the server is not authoritative for any part of the QNAME, a Edward> response indicating a lame server for QNAME is given. I can not argue with any of these. Maybe I'm just too dead for too many late nights recently, to think these through. Can you tell me what problems each one of these points addresses? Olafur's rather simple suggestion, which I think was originally proposed for the DNSSEC work way back when (I spent yesterday in long meetings with John Gilmore, and we discussed this), gets rid of any issues with dealing with caches, since you do not depend upon them fetching the right stuff, you just keep asking on the way up the chain. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiM+b4qHRg3pndX9AQGADgQA6pdtMXX4sh/qk5lFb9BT6S9/Eg3bczdr VOL+mrzZeUT8duzYq5E5pRU2Xth5wI3uI+8uznJhgNWXU68S08gP31l7mePYRJzk Lwlwzb4QWbGr0mvE/zD4pE77zLMTU1jgWMNmkYpzbHiENLXTx9Gd3XBAc/sT6U9v pyxRpu/8o5k= =3Pm+ -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Edward Lewis Subject: Re: the DS deployment problem Date: Mon, 13 Jan 2003 16:17:19 -0800 Lines: 80 Sender: owner-namedroppers@ops.ietf.org References: <200301132232.h0DMWHqS005358@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <200301132232.h0DMWHqS005358@sandelman.ottawa.on.ca> To: Michael Richardson Precedence: bulk I jumbled your words to present a better response At 14:32 -0800 1/13/03, Michael Richardson wrote: >Olafur's rather simple suggestion, which I think was originally proposed for >the DNSSEC work way back when (I spent yesterday in long meetings with John >Gilmore, and we discussed this), gets rid of any issues with dealing with >caches, since you do not depend upon them fetching the right stuff, you just >keep asking on the way up the chain. What I suggested should be the same as Olafur's suggestion, just more tersely and concretely written. (The motivation of the suggestion was to clear up the text in -12, not conflict/change the strategy.) >I can not argue with any of these. Maybe I'm just too dead for too many late >nights recently, to think these through. Can you tell me what problems each >one of these points addresses? Sure, I'll hit them line by line. >Here are your comments, again: > > Ed> 1) If the server is authoritative for the zone that holds the DS RR > Ed> set (i.e., the zone that delegates away, aka the "parent" > Ed> zone), the response contains the DS RR set as an authoritative answer. The best of all possible situations is that the query has hit the (or a) "right" server. If a server holds the answer, there's no reason to withhold it. > Ed> 2) If the server is offering recursive service, the server performs > Ed> the query itself (according to the rules for resolvers described > Ed> below) and returns it's findings. I think this is the next step - regardless of any other configuration. (I can be argued over this.) I notice that I missed a doing a cache lookup, but that should probably be done here as well (cache then recurse) under the theory - if you have the answer, send it. > Ed> 3) If the server is authoritative for the zone that holds the > Ed> 's SOA RR set, the response is an authoritative negative answer > Ed> as described in 2.2.1.1. If the server serves the zone for which you want the DS, answer negatively. > Ed> 4) If the server is authoritative for a zone above the QNAME, a > Ed> referral to a more enclosing zone's servers is made. If the server is a grand*parent of the zone, refer down. > Ed> 5) If the server is not authoritative for any part of the QNAME, a > Ed> response indicating a lame server for QNAME is given. Otherwise, indicate lameness as traditional. The reason the above works is that there are instructions that the DS-seeker must follow. These include: If getting a negative answer for the DS, look at the SOA in the negative answer. This will give you the name of the zone where the query is returning from (the context of the answer). (This isn't a complete answer.) Strip one label, ask for the NS - ask there for DS. if there's no NS (and the answer has the next up SOA), ask for the the NS there etc. I'm losing focus in answering this...it's obvious. The "fear" is that zones may have multilabel deep delegations...that's where the confusion comes in. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Delegation signer-12 Date: Mon, 13 Jan 2003 20:53:45 -0500 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20021218133820.02a95870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Erik Nordmark Return-path: X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Edward Lewis , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?__Gu=F0mundsson?= , namedroppers@ops.ietf.org In-Reply-To: Precedence: bulk At 21:07 2002-12-20, Edward Lewis wrote: >I was staring at the new words on the handling of the DS RR in section >2.2.1.2 when I noticed this problem with the text: > ># 2.2.2 Signer's Name (replaces RFC3008 section 2.7) ># ># The signer's name field of a SIG RR MUST contain the name of the zone ># to which the data and signature belong. The combination of signer's > >This is a very bad idea. > >The signer's name had better remain as it is defined. So much for my rule >of thumb reaction. Here are a laundry list of reasons why I have a >problem with this section and idea: > >1) The section has nothing to do with the DS RR definition. > >2) There is no rationale presented for changing the syntactic definition >of the SIG RR. > >3) Reading between the lines, the author of the document seems to be either: > >3a) trying to clean up something in 3008 The title of the section says it is updating 3008, I thought that updating 3008 to reflect the DS was needed. If 3008 is not updated then the DS must be signed by the child KEY. >or >3b) is trying to usurp the signer name to mean the authority name > >If it is 3a - this is the wrong document. >If it is 3b - why do folks try to usurp fields for new purposes >needlessly. It's easy enough to discover the authority via SOA records in >responses. Some document must do this clarification, if not DS a small update to 3008. The sections that I'm less sure about if they belong are the 2.2.3 subsections that update RFC3090 comments. 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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: comments on DS-12, section 2.2.1.2 Date: Mon, 13 Jan 2003 21:02:05 -0500 Lines: 109 Sender: owner-namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: edlewis@arin.net Return-path: X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Edward Lewis , namedroppers@ops.ietf.org In-Reply-To: Precedence: bulk At 11:52 2003-01-02, Edward Lewis wrote: >To the group - please scrutinize...In the spirit of "sending text": thank you, thank you >#2.2.1.2 Special processing when child and an ancestor share server ># ># When a child zone and a ancestor other than parent share an ># authorative server, a DS aware server MUST answer with information ># from child zone, as specified in section 2.2.1.1. This is to prevent ># the server to be marked as lame for child. > >Special rules are needed to permit DS RR aware servers to gracefully >interact with older caches which otherwise might falsely label a server as >lame because of the new placement of the DS RR set. > >Such a situation might arise when a server is authoritative for both a >zone and it's grandparent, but not the parent. This sounds like an >obscure example, but it is very real. The root zone is currently served >on 13 machines, and "root-servers.net." is served on 4 of the same 13, but >"net." is served elsewhere. Much better than my text, will include in the document. >When a server receives a query for (, DS, IN), the response MUST be >determined from reading these rules in order: > >1) If the server is authoritative for the zone that holds the DS RR set >(i.e., the zone that delegates away, aka the "parent" zone), the >response contains the DS RR set as an authoritative answer. > >2) If the server is offering recursive service, the server performs the >query itself (according to the rules for resolvers described below) and >returns it's findings. > >3) If the server is authoritative for the zone that holds the 's >SOA RR set, the response is an authoritative negative answer as described >in 2.2.1.1. I do not think this is correct philosophically: A server than performs authoritative service as well as recursive service, should not switch back and forth between the two on a single query. It should complete the rule set for authoritative service first and then switch to the recursive service. Thus I would move rule 2 out of this list, and the rule is missing the condition that the query MUST have the RD bit set. >4) If the server is authoritative for a zone above the QNAME, a referral >to a more enclosing zone's servers is made. > >5) If the server is not authoritative for any part of the QNAME, a >response indicating a lame server for QNAME is given. > >[Editorial comment: notice the lack of RFC 2119 terms below this line. I >am not sure what to require, most of what I have written might be >considered recommendations for finding the data.] Most of the rules above are in the MUST category. Rules 1 and 3 are needed in the DS document. Rules 4 and 5 are standard DNS authoritative server rules and IMHO there is no need to restate them. >Using these rules will require some special processing on the part of a DS >RR aware resolver. To illustrate this, an example is used. > >Assuming a server is authoritative for roots.example.net. and for the root >zone but not the intervening two zones (or the intervening two label deep >zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN. > >The resolver will issue this request (assuming no cached data) expecting a >referral to a net. server. Instead, rule number 3 above applies and a >negative answer is returned by the server. The reaction by the resolver >is not to accept this answer as final as it can determine from the SOA RR >in the negative answer the context within which the server has answered. > >A solution to this is to instruct the resolver to hunt for the >authoritative zone of the data in a brute force manner. > >This can be accomplished by taking the owner name of the returned SOA RR >and strip off enough left-hand labels until a successful NS response is >obtained. A successful response here means that the answer has NS records >in it. (Entertaining the possibility that a cut point may be two labels >down in a zone.) > >Returning to the example, the response will include a negative answer with >either the SOA RR for "roots.example.net." or "example.net." depending on >whether roots.example.net is a delegated domain. In either case, removing >the least significant label of the SOA owner name will lead to the >location of the desired data. One minor nit, the only reason SOA is needed in a negative answers along with NXT is not confuse old resolvers, RFC3225 (DO bit) should have eliminated the need to include the SOA. If only NXT is sent in the SOA section then the singer name on the NXT reflects the zone where the DS belongs in. I will include this text or suggested successor in version 13 that will be submitted late Thursday (unless there is still debate going on about the text). 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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Edward Lewis Subject: Re: Delegation signer-12 Date: Tue, 14 Jan 2003 09:50:02 -0800 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20030113204546.023c1100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?___?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org, Erik Nordmark Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <5.1.1.6.2.20030113204546.023c1100@localhost> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= Precedence: bulk Well, you're right that 3008 does already redefine the SIG RR's signer name field and thus the change here is appropriate. Regardless, the change in section 2.7 of RFC 3008 was a mistake. But that's not to be argued here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Thomas Narten Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Tue, 14 Jan 2003 16:02:50 -0500 Lines: 41 Sender: owner-ietf@ietf.org References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Return-path: To: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers In-Reply-To: Message from narten@us.ibm.com of "Fri, 10 Jan 2003 11:24:52 EST." <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Precedence: bulk To clarify a bit, based on followup mail. AD hat was on in previous message, same here. I am not speaking for the full IESG, however. It was not my intent to imply that if messages did not get forwarded to one list, but did on another, that this somehow was OK and couldn't be censorship. It is not OK. The messages at issue should have made it out onto namedroppers. Regarding namedroppers mail processing: > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific > procedure. Strictly speaking, the above is not permitted by the published spam filtering guidelines. The issue isn't the use of spamassassin in front of the list, but post-processing of rejected messages. The current guidelines call for a human to manually approve the improperly flagged rejections. I have started a process to see what can be done to address the problem of rejections from spamassassin not being reviewed by a human when sent to namedroppers. In the case at issue, however, I do not believe that the use of spamassassin is the problem with the messages at issue. The explanation I find most likely is that the messages were deleted in haste rather than forwarded as they should have been after having been flagged as possible spam since they came from a non-subscriber. Of course, it is also not possible to prove intention in this case. Given that I have seen no compelling evidence that suggests a desire or intent to censor anyone on the list, I chose not to read such an intent in the cases at issue here. But of course, there is no way to prove one way or the other. Thomas From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Thomas Narten Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Tue, 14 Jan 2003 16:44:03 -0500 Lines: 62 Sender: owner-ietf@ietf.org References: <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> Cc: namedroppers , iesg@ietf.org, ietf@ietf.org, "D. J. Bernstein" Return-path: To: Aaron Swartz In-Reply-To: Message from me@aaronsw.com of "Fri, 10 Jan 2003 12:29:32 CST." <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> Precedence: bulk Aaron Swartz writes: > 4) Any held message that is later approved for distribution on the > mailing list should appear on the list as a normal posting (e.g., > with the proper sender in the From address, etc.). > """ > Later, however, you write: > >> [...] However, in > >> the second message, he manually inserted my subscription > >> address, > >> despite my previous comments about private subscription > >> addresses > >> and forged unsubscription requests. (Was this malicious, or was > >> it > >> just mind-bogglingly stupid?) > > > > Or perhaps, it was to make it clear to the poster which address the > > posting was coming from, since there seems to be confusion at times > > about whether someone is posting from the same address to which they > > are subscribed. > Including someone's private subscription address is not done for a > normal posting. Doing it for a held message is a violation of the rule > above, no? My recollection of the intent of the spam guidelines cited is two things: 1) it wasn't good enough to just resend the message to the list such that the message now appeared to have come from the person who forwarded it. This makes it hard to quote authors appropriately in followups, find specific messages (e.g., to search for the message by the original poster). That sort of thing. 2) It wasn't appropriate to edit the message in a way that might lead someone to claim that the message had been edited to alter its intent. Namedropper's mail that is manually forwarded has (for as long as I can remember) included a line indicating it has been forwarded. The current message (which was improved as a result of the recent attention) is: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] This seems like a reasonable thing to add to such messages. I would not want the guidelines cited to mean this is not permissable or that no other modification was permissible (e.g., adding a header line). One can debate whether including the specific information cited above was the right thing to do, but I don't see it as breach of the guidelines. Thomas From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Dean Anderson Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: Tue, 14 Jan 2003 17:09:16 -0500 (EST) Lines: 73 Sender: owner-namedroppers@ops.ietf.org References: <200301142102.h0EL2oV30388@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "D. J. Bernstein" , , , namedroppers Return-path: In-Reply-To: <200301142102.h0EL2oV30388@rotala.raleigh.ibm.com> To: Thomas Narten Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Perhaps it would be helpful to consider that other lists have multiple persons who can handle such processing, and that all of those persons get the flagged message. Anyone in the administrative group can approve the message. An audit trail might be helpful, in this case. Such an audit trail would have to be read-only to the persons doing the administration, as well as readable to the public, who might wish to see that the administrators are properly handling messages. --Dean On Tue, 14 Jan 2003, Thomas Narten wrote: > To clarify a bit, based on followup mail. > > AD hat was on in previous message, same here. I am not speaking for > the full IESG, however. > > It was not my intent to imply that if messages did not get forwarded > to one list, but did on another, that this somehow was OK and couldn't > be censorship. It is not OK. The messages at issue should have made it > out onto namedroppers. > > Regarding namedroppers mail processing: > > > 1) first run through spamassassin. Mail that is rejected here is not > > archived, as the number of such messages is large. All mail sent to > > mailing lists on the server hosting namedroppers is run though > > spamassassin, so this is not a namedroppers-specific > > procedure. > > Strictly speaking, the above is not permitted by the published spam > filtering guidelines. The issue isn't the use of spamassassin in front > of the list, but post-processing of rejected messages. The current > guidelines call for a human to manually approve the improperly flagged > rejections. I have started a process to see what can be done to > address the problem of rejections from spamassassin not being reviewed > by a human when sent to namedroppers. > > In the case at issue, however, I do not believe that the use of > spamassassin is the problem with the messages at issue. The > explanation I find most likely is that the messages were deleted in > haste rather than forwarded as they should have been after having been > flagged as possible spam since they came from a non-subscriber. > > Of course, it is also not possible to prove intention in this case. > Given that I have seen no compelling evidence that suggests a desire > or intent to censor anyone on the list, I chose not to read such an > intent in the cases at issue here. But of course, there is no way to > prove one way or the other. > > 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "D. J. Bernstein" Subject: Re: Dan Bernstein's issues about namedroppers list operation Date: 16 Jan 2003 00:59:20 -0000 Lines: 17 Sender: owner-ietf@ietf.org References: <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> <200301142144.h0ELi3O30583@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. To: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Content-Disposition: inline Precedence: bulk Thomas Narten writes: > One can debate whether including the specific information cited above > was the right thing to do That's the paragraph Bush added to other people's messages. Bush added a different paragraph to my messages. (The ones he didn't throw away, that is.) In that paragraph, he specifically included my private subscription address, which hadn't appeared anywhere in the messages I actually sent. Unintentional, eh? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "D. J. Bernstein" Subject: Re: does anybody use additional/authority records on RD/RA replies Date: 16 Jan 2003 01:12:13 -0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <20030111200442.19176.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. To: namedroppers@ops.ietf.org Content-Disposition: inline Precedence: bulk Bruce Campbell writes: > the memory footprint of a DNS cache You think that it's better use of memory to have separate caches---plus separate caching code---in every application? Bad design decisions like this are responsible for most of the bloat in programs like sendmail and named. It's particularly sad when one bloated program uses the size of another bloated program as an excuse to add even more bloat to the first instead of reusing the second. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "Bill Strahm" Subject: RE: Dan Bernstein's issues about namedroppers list operation Date: Wed, 15 Jan 2003 22:25:56 -0800 Lines: 28 Sender: owner-ietf@ietf.org References: <20030116005920.5503.qmail@cr.yp.to> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: To: "'D. J. Bernstein'" , , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030116005920.5503.qmail@cr.yp.to> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Precedence: bulk -----Original Message----- From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On Behalf Of D. J. Bernstein Sent: Wednesday, January 15, 2003 4:59 PM To: namedroppers@ops.ietf.org; iesg@ietf.org; ietf@ietf.org Subject: Re: Dan Bernstein's issues about namedroppers list operation Thomas Narten writes: > One can debate whether including the specific information cited above > was the right thing to do That's the paragraph Bush added to other people's messages. Bush added a different paragraph to my messages. (The ones he didn't throw away, that is.) In that paragraph, he specifically included my private subscription address, which hadn't appeared anywhere in the messages I actually sent. Unintentional, eh? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: "Hallam-Baker, Phillip" Subject: RE: Dan Bernstein's issues about namedroppers list operation Date: Thu, 16 Jan 2003 14:22:40 -0800 Lines: 164 Sender: owner-ietf@ietf.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0091_01C2BD83.CEB7E980" Cc: djb@cr.yp.to, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Return-path: To: Keith Moore , Thomas Narten X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C2BD83.CEB7E980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There is a proposal to start an IRTF research group on the topic of SPAM. Perhaps one of the things that could be looked at is how mailing lists could apply spam defenses and still maintain open-ness. Many of the problems with spam are now the second order effects of dropped messages that should have been forwarded. By default SpamAssasin is configured to consult a blacklist that is currently blocking all UUNET addresses because the maintainer does not like something that a UUNET subscriber is publishing on their site. I conclude that blacklists of that type will not last long as the Internet starts to re-route arround the censorship damage. That said, there is an old proverb in politics about what you should do when you become the story. I think the issues that concern the group members here are more than just the alleged filtering of Bernstein's posts. Phill > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 10, 2003 8:00 PM > To: Thomas Narten > Cc: moore@cs.utk.edu; djb@cr.yp.to; ietf@ietf.org; iesg@ietf.org; > namedroppers@ops.ietf.org > Subject: Re: Dan Bernstein's issues about namedroppers list operation > > > > > Specifically, all mail sent to namedroppers is: > > > > 1) first run through spamassassin. Mail that is rejected here is not > > archived, as the number of such messages is large. All > mail sent to > > mailing lists on the server hosting namedroppers is run though > > spamassassin, so this is not a namedroppers-specific procedure. > > SpamAssissin needs to be shot. Most of its criteria are > really poorly chosen. > Even if its criteria are good at identifying spam on a large > scale (with few > false positives) that doesn't mean they will work well for a > narrowly-focused > discussion. In my experience SpamAssassin has too high a > false positive rate > to be trusted without human review as a backup. > > Keith > > p.s. regarding messages that did not make it to the > namedroppers archive - > are the IETF archives still using to/cc message headers to > decide which > archive a message should be stored in? if so, is it > possible that a message > which was sent to multiple lists might be archived in only > one of those lists? > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0091_01C2BD83.CEB7E980 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDExNjIy MjIxMlowIwYJKoZIhvcNAQkEMRYEFJ3lZDYkUs/sRzfC+KhfGRj6LUnQMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUqTMmJwOP7FOpgLAYwy2GiJ0OoxiBPzDPqt2mDT5XAdxfBtQ LRuMr0T5j1LqvVMA7l6S3gKUPN1feplc58vUnf35NnK6mu7z8xdqZV98oieFQR6CcJJd2+OiL0/P bZrfpv+k3jSJaiiywyuruBx09dYCRDy273iTNJsz9O5Wv0UAAAAAAAA= ------=_NextPart_000_0091_01C2BD83.CEB7E980-- From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Dean Anderson Subject: RE: Dan Bernstein's issues about namedroppers list operation Date: Thu, 16 Jan 2003 19:21:01 -0500 (EST) Lines: 121 Sender: owner-namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Keith Moore , Thomas Narten , , , , Return-path: In-Reply-To: To: "Hallam-Baker, Phillip" Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] The current issues with namedroppers administration have nothing to do with SPAM, but rather have to do with draconian and un-audited controls given to one person _on_behalf_of_SPAM_. This was a unwise decision. SPAM problems did not require that supreme, un-audited authority be given one person. A large part of "SPAM" is not a matter of marketing. It is a matter of terrorism, where instead of violence, they conduct annoyance. The persons creating the vast bulk of the abuse are people trying to terrorize or annoy people into banning spam. Vixie said from the start that it was his goal to make things worse. He has succeeded: More annoying it is. These people have no real commercial motivation--at least, not with respect to the services described in the emails they send. They aren't trying to sell anything by email. They are trying to sabotage the system of email, and annoy people. One might wonder who would only want to annoy people, and for what purpose, since they are not trying to sell something. No matter what kind of system you build, if there is any openness for people, whatsoever, it will be vulnerable to abuse by people inclined to conduct such abuse. There is no way to prevent that abuse. You can try to delete the abuse, after it has occurred. You can implement moderation with the incumbent delays, and other problems, which are necessary or unnecessary consequences of moderation. You can complain to the ISP's who sold accounts to the abusers. Etc. These things are all activities performed after the fact. Even the moderation staff still has to deal with the abuse, if the entire list doesn't. When someone is trying to annoy you, the correct response is not to be annoyed, but to remain calm. Like terrorism, there is no solution to spam. Whatever you do, beyond punishing those directly responsible, will only make the matter worse. --Dean On Thu, 16 Jan 2003, Hallam-Baker, Phillip wrote: > There is a proposal to start an IRTF research group on the topic of > SPAM. Perhaps one of the things that could be looked at is how mailing > lists could apply spam defenses and still maintain open-ness. > > Many of the problems with spam are now the second order effects of > dropped messages that should have been forwarded. > > By default SpamAssasin is configured to consult a blacklist that is > currently blocking all UUNET addresses because the maintainer does not > like something that a UUNET subscriber is publishing on their site. I > conclude that blacklists of that type will not last long as the Internet > starts to re-route arround the censorship damage. > > > That said, there is an old proverb in politics about what you should do > when you become the story. I think the issues that concern the group > members here are more than just the alleged filtering of Bernstein's > posts. > > > Phill > > > -----Original Message----- > > From: Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Friday, January 10, 2003 8:00 PM > > To: Thomas Narten > > Cc: moore@cs.utk.edu; djb@cr.yp.to; ietf@ietf.org; iesg@ietf.org; > > namedroppers@ops.ietf.org > > Subject: Re: Dan Bernstein's issues about namedroppers list operation > > > > > > > > > Specifically, all mail sent to namedroppers is: > > > > > > 1) first run through spamassassin. Mail that is rejected here is not > > > archived, as the number of such messages is large. All > > mail sent to > > > mailing lists on the server hosting namedroppers is run though > > > spamassassin, so this is not a namedroppers-specific procedure. > > > > SpamAssissin needs to be shot. Most of its criteria are > > really poorly chosen. > > Even if its criteria are good at identifying spam on a large > > scale (with few > > false positives) that doesn't mean they will work well for a > > narrowly-focused > > discussion. In my experience SpamAssassin has too high a > > false positive rate > > to be trusted without human review as a backup. > > > > Keith > > > > p.s. regarding messages that did not make it to the > > namedroppers archive - > > are the IETF archives still using to/cc message headers to > > decide which > > archive a message should be stored in? if so, is it > > possible that a message > > which was sent to multiple lists might be archived in only > > one of those lists? > > > > -- > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Bruce Campbell Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Sat, 18 Jan 2003 11:57:37 +0100 (CET) Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <20030116011213.8744.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org In-Reply-To: <20030116011213.8744.qmail@cr.yp.to> Precedence: bulk On 16 Jan 2003, D. J. Bernstein wrote, removing the original context: > Bruce Campbell writes: > > the memory footprint of a DNS cache > > You think that it's better use of memory to have separate caches---plus > separate caching code---in every application? In the original context that I provided, it _was_ a better usage of _resources_, not necessarily memory, to re-use information previously received due to the greater expense of asking for the same information, _at that point in time_ (ie, more expensive internet links, more expensive cpu, more expensive memory). --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "D. J. Bernstein" Subject: Re: does anybody use additional/authority records on RD/RA replies Date: 18 Jan 2003 12:22:11 -0000 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <20030116011213.8744.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. To: namedroppers@ops.ietf.org Content-Disposition: inline Precedence: bulk Bruce Campbell writes: > more expensive internet links, more expensive cpu, more expensive memory I'm not saying that bandwidth, CPU time, and memory are free. I'm saying that the costs of the strategy you're advocating outweigh the benefits. A machine-wide cache is better than an ad-hoc cache in every program. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Bruce Campbell Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Mon, 20 Jan 2003 11:56:07 +0100 (CET) Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <20030118122211.4909.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org In-Reply-To: <20030118122211.4909.qmail@cr.yp.to> Precedence: bulk On 18 Jan 2003, D. J. Bernstein wrote: [ danny boy, you may wish to re-read this thread to understand why I keep putting in the original context. I dislike having my words quoted out of context in order to uphold statements outside said context. ] > Bruce Campbell writes: : > On 16 Jan 2003, D. J. Bernstein wrote, removing the original context: : > > You think that it's better use of memory to have separate caches---plus : > > separate caching code---in every application? : > In the original context that I provided, it _was_ a better usage of : > _resources_, not necessarily memory, to re-use information previously : > received due to the greater expense of asking for the same information, : >_at that point in time_ (ie, > > more expensive internet links, more expensive cpu, more expensive memory). > > I'm not saying that bandwidth, CPU time, and memory are free. Neither am I. You may wish to re-read this thread to understand the difference between the inverse of 'more expensive', ie 'cheaper' and 'free'. > I'm saying > that the costs of the strategy you're advocating outweigh the benefits. Given that I haven't been advocating any particular design strategy for writing programs today, I suspect that you meant to write: | I'm saying that the costs of using such an old strategy today outweigh | the benefits. You may wish to re-read this thread to understand the difference between the two statements. > A machine-wide cache is better than an ad-hoc cache in every program. Not quite correct. You probably mean: A machine-wide cache is better than an ad-hoc cache in most programs written today. There are programs written today which implement their own (DNS) caching simply because their design goal is pure speed, and the local machine-wide (DNS) cache, irrespective of the author of such, is too slow for their particular needs. You may wish to re-read the thread to understand why I put forward my thoughts on such a design strategy for times past in the first place. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "D. J. Bernstein" Subject: Re: does anybody use additional/authority records on RD/RA replies Date: 20 Jan 2003 11:57:53 -0000 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <20030118122211.4909.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. To: namedroppers@ops.ietf.org Content-Disposition: inline Precedence: bulk I'm not just saying that ad-hoc per-program DNS caches are bad design today. I'm also saying that they were bad design twenty years ago. The traffic argument is, and has always been, silly: a machine-wide cache saves more traffic. The memory argument is, and has always been, silly: a machine-wide cache uses less memory. The CPU-time argument is not silly, but if you measure carefully then you'll see that it's wrong. More importantly, all three arguments reflect a serious failure to put costs in perspective. As Knuth wrote thirty years ago: There is no doubt that the ``grail'' of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We _should_ forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. No rational estimate for the benefits of sendmail's ad-hoc DNS cache could ever have justified the lines of code spent on that cache. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Alexis Yushin Subject: Re: does anybody use additional/authority records on RD/RA replies Date: Mon, 20 Jan 2003 13:25:33 +0100 (CET) Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <20030120115753.39972.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org Return-path: In-Reply-To: <20030120115753.39972.qmail@cr.yp.to> To: "D. J. Bernstein" X-Mailer: ELM [version 2.4ME+ PL99b (25)] Precedence: bulk Once D. J. Bernstein wrote: >I'm not just saying that ad-hoc per-program DNS caches are bad design >today. I'm also saying that they were bad design twenty years ago. > >The traffic argument is, and has always been, silly: a machine-wide >cache saves more traffic. The memory argument is, and has always been, >silly: a machine-wide cache uses less memory. The CPU-time argument is >not silly, but if you measure carefully then you'll see that it's wrong. I think the real arguement here is that resolving process, quite often lengthy, potentionaly blocking operation, can dramatically impact the performance of the application unless optimized. Having dns cache built in ensures that the application does not rely on external software and will function reasonably even when no machine-wide dns cache software is in use, which is quite often the case. Now if machine-level dns caching was a standard feature of the resolver library or the operating system, I'm sure nobody would be implementing custom built in program-level dns caches. Until them I'm afraid it does make sense to avoid complicating dependancies. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "Hallam-Baker, Phillip" Subject: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Tue, 21 Jan 2003 10:30:18 -0800 Lines: 193 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0119_01C2C14E.374DCA50" Return-path: To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0119_01C2C14E.374DCA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bernstein is a whiner who deserves no sympathy from anyone. In order to avoid cluttering up his inbox with SPAM he has one of those annoying callback systems. Only thing is that the self-centered clod can't be bothered to put people who reply into a whitelist. What this means is that as a result of Mr* Bernsteins attempt to minimize the amount of spam HE receives, he is generating spam for EVERYONE ELSE. I have answered the call back twice, Bernstein continues to SPAM me. What is worse, the main purpose of the callback message appears to be to remind the recipient of the size of Bernstein's ego. If bernstein is having difficulty posting to the list I suspect that it is not at all unlikely that the cause will turn out to be some interaction between his eccentric mailing code and the mailing list software that he has not bothered to consider or investigate. Phill [*] Its only an assistant professorship that by European lights only ranks him as a mere lecturer. The fact that he has to refer to himself by title TEN times in his pompous note suggests that his sense of self importance is dangerously exagerated. -----Original Message----- From: The qsecretary program [mailto:djb-notbulkmail-eeac5f7ce0588c3ec6303c66f5f2ef59@cr.yp.to] Sent: Thursday, January 16, 2003 5:23 PM To: pbaker@verisign.com Subject: qsecretary notice Hi. This is D. J. Bernstein's automated mail-handling program. I've received a message from you. The top of your message is shown below. Professor Bernstein receives many interesting messages. Unfortunately, he also receives a torrent of unsolicited commercial mail, unsolicited job applications, unsolicited mailing-list subscriptions, forged mailing-list subscriptions, etc. Professor Bernstein has asked me to reject all bulk mail messages. But I'm a rather primitive computer program, and I'm not sure whether your message is bulk mail. If you reply to this notice, you are (1) acknowledging that Professor Bernstein does not want to receive bulk mail; (2) confirming that your message is not part of a bulk mailing; and (3) agreeing to pay Professor Bernstein $250 if your message is part of a bulk mailing. I won't look at the contents of your reply. A simple OK is fine, as long as it's sent to the address shown above. You don't have to include a second copy of your message. If you do not reply to this notice, your message will eventually be returned to you, and Professor Bernstein will not see it. I realize that this confirmation process is inconvenient. I'm sorry for the hassle. I hope that IM2000, Professor Bernstein's new Internet mail architecture, succeeds in eliminating these problems. In the meantime, we're all suffering because of a few inconsiderate people. Sincerely, The qsecretary program P.S. Professor Bernstein has asked me to convey his own apologies to you if you're someone he knows. I'm sure he'll tell me to accept subsequent messages from you without confirmation. If you're replying to a message that Professor Bernstein sent you, the problem is probably that the return address in your message isn't the same as the address that Professor Bernstein has on file. I'll let Professor Bernstein know that he should add your new address. P.P.S. If you're a legitimate mailing-list manager, and you've received what appears to be a subscription request from djb@cr.yp.to: That request is a forgery. Professor Bernstein uses different addresses for his mailing-list subscriptions. Please remove djb@cr.yp.to from your mailing list. Do not reply to this message. Note that high-quality mailing-list software confirms each subscription request with a secure cryptographic authenticator; supports tracing by returning a complete copy of each request, including Received fields; and supports filtering by adding a Mailing-List field to every outgoing message, including confirmation notices. If your software does not have these features, upgrade! ------=_NextPart_000_0119_01C2C14E.374DCA50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyMTE4 MDgzOVowIwYJKoZIhvcNAQkEMRYEFDAzImeCwWkumcnGeM8UON13A59qMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUygU16m8TPmOAxnQOIhrB6foHy1W3Rl8YrIy7QddvlJpl33y YuHdWjjrnB/ORffb7la+x1HIXiJXM/HNV6Ysg0H0ACy7lgx0kYZIg6ZYHuklRvk7kEiBaIxjxVUt CvCu16Utaw/2nap0yZlFfiaW/u9cOY4DbaBkokSdCVMEwSAAAAAAAAA= ------=_NextPart_000_0119_01C2C14E.374DCA50-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Valdis.Kletnieks@vt.edu Subject: Re: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Wed, 22 Jan 2003 13:13:12 -0500 Lines: 31 Sender: owner-ietf@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-227804608P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "Hallam-Baker, Phillip" In-Reply-To: Your message of "Tue, 21 Jan 2003 10:30:18 PST." Precedence: bulk --==_Exmh_-227804608P Content-Type: text/plain; charset=us-ascii On Tue, 21 Jan 2003 10:30:18 PST, "Hallam-Baker, Phillip" said: > [*] Its only an assistant professorship that by European lights > only ranks him as a mere lecturer. The fact that he has to refer And by common US practice, he has a PhD and is accorded the title Doctor. At the place he has a professorship, the customary usage is to use the title. Also, in the US, there is usually a distinction made between an assistant professor and an adjunct professor and a lecturer/instructor. --==_Exmh_-227804608P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+Lt84cC3lWbTT17ARAvx0AKDmHPYtgLsjUfRzefhR1MaPSFcjrgCg/JHB WTwMFAJhvMD11YOGUac8Y1M= =MvPu -----END PGP SIGNATURE----- --==_Exmh_-227804608P-- From owner-ietf@ietf.org Fri Dec 29 10:45:21 2006 From: Franck Martin Subject: RE: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Thu, 23 Jan 2003 10:18:45 +1200 Lines: 100 Sender: owner-ietf@ietf.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0026_01C2C2C8.D7AB7120"; protocol="application/x-pkcs7-signature" Return-path: To: "'Hallam-Baker, Phillip'" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C2C2C8.D7AB7120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Why don't he uses TMDA.sourceforge.net? Franck Martin ICT Specialist - EU/EDF8 Project > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Wednesday, 22 January 2003 6:30 > To: ietf@ietf.org; iesg@ietf.org; namedroppers@ops.ietf.org > Subject: Dan Berrnstein deserves what he gets. FW: qsecretary notice > > > Bernstein is a whiner who deserves no sympathy from anyone. > > In order to avoid cluttering up his inbox with SPAM he has > one of those annoying callback systems. Only thing is that the > self-centered clod can't be bothered to put people who reply into > a whitelist. > ------=_NextPart_000_0026_01C2C2C8.D7AB7120 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKVzCCBSQw ggSNoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWpp MQ0wCwYDVQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSVRVMRYwFAYDVQQDEw1T T1BBQyBSb290IENBMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNvcGFjLm9yZzAeFw0w MjA1MDkyMjEwMDZaFw0wMzA1MDkyMjEwMDZaMIGFMQswCQYDVQQGEwJGSjENMAsGA1UECBMERmlq aTENMAsGA1UEBxMEU3V2YTEOMAwGA1UEChMFU09QQUMxDDAKBgNVBAsTA0lUVTEZMBcGA1UEAxQQ ZnJhbmNrQHNvcGFjLm9yZzEfMB0GCSqGSIb3DQEJARYQZnJhbmNrQHNvcGFjLm9yZzCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA0soRghfaBJ3B6+yxHxEkHbtCF4a/ZNNUs9Sn38pBwXT0D/R6 iqhC+CCxjO/7mCe4F6pRZMTuN0Rv84ZMa77aNDBcVWiSsssoUS+64yxTefwnq3+gifNO7mVxE8yr a/LvvwKIGmr0R0Hz8kTidyUzcoQROFHfD27FJpjEsVFtOmcCAwEAAaOCApwwggKYMAkGA1UdEwQC MAAwPwYJYIZIAYb4QgENBDIWMENlcnRpZmljYXRlIGlzc3VlZCBieSBodHRwczovL3d3dy5zb3Bh Yy5vcmcvc3NsLzAdBgNVHQ4EFgQUukKEVhwnVd3F4n9WW26fA4c6wBEwgbYGA1UdIwSBrjCBq4AU OqATltJqhrl/LVS+UDvT8aTsUa+hgY+kgYwwgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWpp MQ0wCwYDVQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSVRVMRYwFAYDVQQDEw1T T1BBQyBSb290IENBMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNvcGFjLm9yZ4IBADAp BglghkgBhvhCAQIEHBYaaHR0cHM6Ly93d3cuc29wYWMub3JnL3NzbC8wNQYJYIZIAYb4QgEEBCgW Jmh0dHBzOi8vd3d3LnNvcGFjLm9yZy9zc2wvc29wYWMtY2EuY3JsMDkGCWCGSAGG+EIBAwQsFipo dHRwczovL3d3dy5zb3BhYy5vcmcvc3NsL3Jldm9jYXRpb24uaHRtbD8wNgYJYIZIAYb4QgEHBCkW J2h0dHBzOi8vd3d3LnNvcGFjLm9yZy9zc2wvcmVuZXdhbC5odG1sPzA0BglghkgBhvhCAQgEJxYl aHR0cHM6Ly93d3cuc29wYWMub3JnL3NzbC9wb2xpY3kuaHRtbDAuBgNVHRIEJzAlhiNodHRwczov L3d3dy5zb3BhYy5vcmcvc3NsL3NvcGFjLmNydDA3BgNVHR8EMDAuMCygKqAohiZodHRwczovL3d3 dy5zb3BhYy5vcmcvc3NsL3NvcGFjLWNhLmNybDANBgkqhkiG9w0BAQUFAAOBgQB+4WRRdMulWDp2 MNawJy9mksHVGL2l5BN6eBOcRcoi1cLgOvISZwoAp7C/vE/37lQRqbHcHATn4FU+bGjuxMu/YBYH ax5TYWV9G3/Gc0HA4UhPuvDLS1Z7woFsI5Ra2mJGyJgE8IWxt2HfRjR5fBEY/+PHVumXaRyxi6Fj em+AaTCCBSswggSUoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgYkxCzAJBgNVBAYTAkZKMQ0wCwYD VQQIEwRGaWppMQ0wCwYDVQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSVRVMRYw FAYDVQQDEw1TT1BBQyBSb290IENBMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNvcGFj Lm9yZzAeFw0wMjA1MDkwNDUxMDlaFw0xMjA1MDYwNDUxMDlaMIGJMQswCQYDVQQGEwJGSjENMAsG A1UECBMERmlqaTENMAsGA1UEBxMEU3V2YTEOMAwGA1UEChMFU09QQUMxDDAKBgNVBAsTA0lUVTEW MBQGA1UEAxMNU09QQUMgUm9vdCBDQTEmMCQGCSqGSIb3DQEJARYXYWRtaW5pc3RyYXRvckBzb3Bh Yy5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ/G829ctvoXf2qH0/THNKgdgTHjqOoJ 8M6B4jDu/t5kv3EQFXz65b8bAt3DnWtL29gSgmZ2Og4f5J1GjmqFRlzH8BJFGArWi6MmLuLmSvl3 ltM211jm66wxU+ePB2v4lledogiLRkIlAlZzzpLrdm6SlWPoxrZUE4juSKucSK/dAgMBAAGjggKf MIICmzAdBgNVHQ4EFgQUOqATltJqhrl/LVS+UDvT8aTsUa8wgbYGA1UdIwSBrjCBq4AUOqATltJq hrl/LVS+UDvT8aTsUa+hgY+kgYwwgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSVRVMRYwFAYDVQQDEw1TT1BBQyBS b290IENBMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNvcGFjLm9yZ4IBADAMBgNVHRME BTADAQH/MD8GCWCGSAGG+EIBDQQyFjBDZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgaHR0cHM6Ly93d3cu c29wYWMub3JnL3NzbC8wKQYJYIZIAYb4QgECBBwWGmh0dHBzOi8vd3d3LnNvcGFjLm9yZy9zc2wv MDUGCWCGSAGG+EIBBAQoFiZodHRwczovL3d3dy5zb3BhYy5vcmcvc3NsL3NvcGFjLWNhLmNybDA5 BglghkgBhvhCAQMELBYqaHR0cHM6Ly93d3cuc29wYWMub3JnL3NzbC9yZXZvY2F0aW9uLmh0bWw/ MDYGCWCGSAGG+EIBBwQpFidodHRwczovL3d3dy5zb3BhYy5vcmcvc3NsL3JlbmV3YWwuaHRtbD8w NAYJYIZIAYb4QgEIBCcWJWh0dHBzOi8vd3d3LnNvcGFjLm9yZy9zc2wvcG9saWN5Lmh0bWwwLgYD VR0SBCcwJYYjaHR0cHM6Ly93d3cuc29wYWMub3JnL3NzbC9zb3BhYy5jcnQwNwYDVR0fBDAwLjAs oCqgKIYmaHR0cHM6Ly93d3cuc29wYWMub3JnL3NzbC9zb3BhYy1jYS5jcmwwDQYJKoZIhvcNAQEF BQADgYEAVgR9VJL3PAR6ljg8PVSyGIJ+t+yvhtU6q6cEuONs1EILhhLae4XmajjVeXud9t/U+jNm 4IZi3XqWymeLV1oj/exU7Lcnog5CeA9QirpH+xlzHd2ByMW1RvbSmhgsbv8nQ7Y21Foxdx3lkAfi V2ya75RUFFATHjfddz5R2osj7yAxggKUMIICkAIBATCBjzCBiTELMAkGA1UEBhMCRkoxDTALBgNV BAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJVFUxFjAU BgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0cmF0b3JAc29wYWMu b3JnAgECMAkGBSsOAwIaBQCgggFaMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAzMDEyMjIyMTg1OFowIwYJKoZIhvcNAQkEMRYEFPr7n8cxZ1yVRFoPjXA3F3N6o6gz MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGgBgkrBgEEAYI3EAQxgZIwgY8wgYkx CzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYDVQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BB QzEMMAoGA1UECxMDSVRVMRYwFAYDVQQDEw1TT1BBQyBSb290IENBMSYwJAYJKoZIhvcNAQkBFhdh ZG1pbmlzdHJhdG9yQHNvcGFjLm9yZwIBAjANBgkqhkiG9w0BAQEFAASBgK9Ps5lASM2xRPzZSaV9 H+28MXw1Y3ILTXvTblgkyQpDai/OB3+LovQA1f9AopSij4p1Vo5jJap0obSi7bMJTWKrwmwGlNab 6p2wUrkfojsm+2+DIFH4dRypmmXQZqf/cixwzOSOzWqQBZ4WU8wxyma8ExQRJM5Qd3V6MWUqSOkc AAAAAAAA ------=_NextPart_000_0026_01C2C2C8.D7AB7120-- From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Jim Reid Subject: Re: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Fri, 24 Jan 2003 01:34:22 -0800 Lines: 8 Sender: owner-namedroppers@ops.ietf.org References: <200301221813.h0MIDCQY007903@turing-police.cc.vt.edu> Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Return-path: To: Valdis.Kletnieks@vt.edu In-Reply-To: Message from Valdis.Kletnieks@vt.edu of "Wed, 22 Jan 2003 13:13:12 EST." <200301221813.h0MIDCQY007903@turing-police.cc.vt.edu> Precedence: bulk Please take this debate about academic titles somewhere else. It's not relevant to any of the lists above. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: "Hallam-Baker, Phillip" Subject: RE: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Fri, 24 Jan 2003 08:08:26 -0800 Lines: 126 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_009C_01C2C398.CCFBE220"; micalg=SHA1 Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Return-path: To: Jim Reid , Valdis.Kletnieks@vt.edu X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C2C398.CCFBE220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My objective was to try to put an end to the Bernstein thread, not to start yet another. I appologise for paying insufficient respect to the decorations and titles of the New World. I did not realise that it was the custom in these parts for the holders of academic titles to address themselves in the third person. Phill Dr. Phillip M. Hallam-Baker, B.Sc(Soton), D.Phil(Oxon), C.Eng, FBCS > -----Original Message----- > From: Jim Reid [mailto:Jim.Reid@nominum.com] > Sent: Friday, January 24, 2003 4:34 AM > To: Valdis.Kletnieks@vt.edu > Cc: Hallam-Baker, Phillip; ietf@ietf.org; iesg@ietf.org; > namedroppers@ops.ietf.org > Subject: Re: Dan Berrnstein deserves what he gets. FW: > qsecretary notice > > > > Please take this debate about academic titles somewhere else. It's not > relevant to any of the lists above. > ------=_NextPart_000_009C_01C2C398.CCFBE220 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNDE2 MDczNlowIwYJKoZIhvcNAQkEMRYEFOAzEvkVm4WM893rsuvCV8x+y293MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAIAaKCkFIJ86z3laggDWtf8o1NGZOMnOgfUJxqQSINADvkmbY o6rEia8FQyrUDESW/RgKD/5FP8+uwnBUU5NJ21yPuj6gSVYKof8VuW7S7h6LnRTliV0GOftr2I5f aWJpRomQGnZlbqs0+8Cqp5ukAUAkiXm+3GoLHAkLpkX0EYkAAAAAAAA= ------=_NextPart_000_009C_01C2C398.CCFBE220-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 07:53:14 -0500 Lines: 90 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org Return-path: To: IETF-Announce: ; Precedence: bulk X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content --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 (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-00.txt Pages : 8 Date : 2003-1-29 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-insensitive-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-insensitive-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: <2003-1-29154628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-29154628.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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: dana@dtn.com Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 11:27:03 -0600 Lines: 95 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: To: Internet-Drafts@ietf.org, namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 X-MIMETrack: Serialize by Router on Omaha/ENG(Release 5.0.11 |July 24, 2002) at 01/30/2003 11:26:30 AM Precedence: bulk "There is one additional instance of note, which relfects the general..." (pg 6 para 2 line 1 (last para of section 4)) We should probably relfect on this awhile more lest the world think we have no spell checkers. Dan Internet-Drafts@ietf .org To: IETF-Announce: ; Sent by: cc: namedroppers@ops.ietf.org owner-namedroppers@o Subject: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt ps.ietf.org 01/30/2003 06:53 AM Please respond to Internet-Drafts 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 (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-00.txt Pages : 8 Date : 2003-1-29 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-insensitive-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-insensitive-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Donald Eastlake 3rd Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 18:01:43 -0500 (EST) Lines: 116 Sender: owner-namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org Return-path: X-X-Sender: dee3@netbusters.com To: dana@dtn.com In-Reply-To: Precedence: bulk Thanks for pointing this out. I'll do a revision before San Francisco. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003 dana@dtn.com wrote: > Date: Thu, 30 Jan 2003 11:27:03 -0600 > From: dana@dtn.com > To: Internet-Drafts@ietf.org, namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > "There is one additional instance of note, which relfects the general..." > (pg 6 para 2 line 1 (last para of section 4)) We should probably relfect > on this awhile more lest the world think we have no spell checkers. > > Dan > > > Internet-Drafts@ietf > .org To: IETF-Announce: ; > Sent by: cc: namedroppers@ops.ietf.org > owner-namedroppers@o Subject: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > ps.ietf.org > > > 01/30/2003 06:53 AM > Please respond to > Internet-Drafts > > > > > 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 (DNS) Case > Insensitivity > Clarification > Author(s) : D. Eastlake > Filename : draft-ietf-dnsext-insensitive-00.txt > Pages : 8 > Date : 2003-1-29 > > Domain Name System (DNS) names are 'case insensitive'. This document > explains exactly what that means and provides a clear specification > of the rules. This clarification should not have any interoperability > consequences. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-insensitive-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-insensitive-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. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.txt > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Scott Seligman Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 16:05:39 -0800 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: Return-path: To: namedroppers@ops.ietf.org Precedence: bulk >A period can also be protected from >recognition as a separator, so that it will be treated as a normal >label character, by preceeding it with a back-slash. In at least some common contexts, a backslash preceding any non-digit octet -- not just a period -- is interpreted as an escape character. This is most useful for embedding a backslash itself within a label ("ab\\cd" being the 5-octet label with a single backslash in the middle). A superfluous backslash is effectively ignored ("ab\de" represents the same label as "abde"). None of this really needs to be discussed to nail down the rules regarding case-sensitivity. But if it is going to be discussed, this should be taken into account. Scott Seligman Java Software Engineering Sun Microsystems -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Donald Eastlake 3rd Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 21:29:11 -0500 (EST) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <200301310005.QAA28975@spin.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org Return-path: X-X-Sender: dee3@netbusters.com To: Scott Seligman In-Reply-To: <200301310005.QAA28975@spin.SFBay.Sun.COM> Precedence: bulk The question is what do DNS Master File parsers and user interfaces do? I'm not included to specify a wider applicability of \ without some re-assurance from implementers. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003, Scott Seligman wrote: > Date: Thu, 30 Jan 2003 16:05:39 -0800 > From: Scott Seligman > To: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >A period can also be protected from > >recognition as a separator, so that it will be treated as a normal > >label character, by preceeding it with a back-slash. > > In at least some common contexts, a backslash preceding any non-digit > octet -- not just a period -- is interpreted as an escape character. > This is most useful for embedding a backslash itself within a label > ("ab\\cd" being the 5-octet label with a single backslash in the middle). > A superfluous backslash is effectively ignored ("ab\de" represents the > same label as "abde"). > > None of this really needs to be discussed to nail down the rules > regarding case-sensitivity. But if it is going to be discussed, this > should be taken into account. > > > Scott Seligman Java Software Engineering Sun Microsystems > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Scott Seligman Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 18:32:58 -0800 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: Cc: namedroppers@ops.ietf.org Return-path: To: Donald Eastlake 3rd In-reply-to: Your message of "Thu, 30 Jan 2003 21:29:11 EST." Precedence: bulk >> In at least some common contexts, a backslash preceding any non-digit >> octet -- not just a period -- is interpreted as an escape character. > >The question is what do DNS Master File parsers and user interfaces do? Right. That's what I'm talking about. BIND 8 for instance. Scott Seligman Java Software Engineering Sun Microsystems -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Donald Eastlake 3rd Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Thu, 30 Jan 2003 21:57:22 -0500 (EST) Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <200301310232.SAA29413@spin.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org Return-path: X-X-Sender: dee3@netbusters.com To: Scott Seligman In-Reply-To: <200301310232.SAA29413@spin.SFBay.Sun.COM> Precedence: bulk So your assertion is that every version of BIND and all versions of Microsoft DNS code and any other DNS code I'm overlooking all behave as your specify? Your original message says "some common contexts", not "all contexts" or even "all DNS Master File parsers and UIs". Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003, Scott Seligman wrote: > Date: Thu, 30 Jan 2003 18:32:58 -0800 > From: Scott Seligman > To: Donald Eastlake 3rd > Cc: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >> In at least some common contexts, a backslash preceding any non-digit > >> octet -- not just a period -- is interpreted as an escape character. > > > >The question is what do DNS Master File parsers and user interfaces do? > > Right. That's what I'm talking about. BIND 8 for instance. > > > Scott Seligman > Java Software Engineering > Sun Microsystems > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Rob Austein Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Fri, 31 Jan 2003 00:26:30 -0500 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: To: namedroppers@ops.ietf.org In-Reply-To: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) Precedence: bulk The "typographic convention" is decimal, not hexadecimal, and the rules for backslash are spelled out explicitly in RFC 1035: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. NB: this means that a backslash followed by one or two decimal digits is undefined, and that a backslash followed by four decimal digits parses as two encoded octets. s{bytes} {octets}g s{It is just that they are traditionally interpreted as ASCII characters} {Most applications, however, interpret them as ASCII characters} s{Historic Note} {Historical Note} s{elsewhere in the wire encoding} {elsewhere in the wire encoding of a DNS message} -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Scott Seligman Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Fri, 31 Jan 2003 02:24:12 -0800 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: Cc: namedroppers@ops.ietf.org Return-path: To: Donald Eastlake 3rd In-reply-to: Your message of "Thu, 30 Jan 2003 21:57:22 EST." Precedence: bulk >So your assertion is that every version of BIND and all versions of >Microsoft DNS code and any other DNS code I'm overlooking all behave as >your specify? Certainly not. I used the words "some" and "common", not "all". The paragraph purports to describe "_The_ typographic convention" (emphasis added) for labels. What it describes, however, differs from *some* common practice. If the paragraph had instead begun: "One of the possible typographic conventions" or something along those lines, that would be different. It's probably best to avoid this whole can of worms here and not mention such "typographic conventions" at all. The case sensitivity rules can be precisely specified without this. Scott Seligman Java Software Engineering Sun Microsystems -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Donald Eastlake 3rd Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Fri, 31 Jan 2003 08:37:49 -0500 (EST) Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <200301311024.CAA29646@spin.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org Return-path: X-X-Sender: dee3@netbusters.com To: Scott Seligman In-Reply-To: <200301311024.CAA29646@spin.SFBay.Sun.COM> Precedence: bulk The rule is included because the format of Master Files is part of the DNS standard. I'll try to take your comments into account in updating the draft...n Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Fri, 31 Jan 2003, Scott Seligman wrote: > Date: Fri, 31 Jan 2003 02:24:12 -0800 > From: Scott Seligman > To: Donald Eastlake 3rd > Cc: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >So your assertion is that every version of BIND and all versions of > >Microsoft DNS code and any other DNS code I'm overlooking all behave as > >your specify? > > Certainly not. I used the words "some" and "common", not "all". > > The paragraph purports to describe "_The_ typographic convention" > (emphasis added) for labels. What it describes, however, differs > from *some* common practice. If the paragraph had instead begun: > "One of the possible typographic conventions" or something along > those lines, that would be different. > > It's probably best to avoid this whole can of worms here and not > mention such "typographic conventions" at all. The case sensitivity > rules can be precisely specified without this. > > > Scott Seligman > Java Software Engineering > Sun Microsystems > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Scott Seligman Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt Date: Fri, 31 Jan 2003 10:23:25 -0800 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: Cc: namedroppers@ops.ietf.org Return-path: To: Donald Eastlake 3rd In-reply-to: Your message of "Fri, 31 Jan 2003 08:37:49 EST." Precedence: bulk >The rule is included because the format of Master Files is part of the >DNS standard. I'll try to take your comments into account in updating >the draft. You may wish to use this wording from RFC 1035 itself: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. Scott Seligman Java Software Engineering Sun Microsystems -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Q: Conflict between TSIG RFC and GSS-API documents Date: Fri, 31 Jan 2003 14:36:24 -0500 Lines: 38 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Return-path: X-Sender: (Unverified) To: namedroppers@ops.ietf.org X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Precedence: bulk From the minutes in ATLANTA: >GSSAPI and TSIG conflict: > DNSEXT wg generated TSIG RFC > DNSEXT wg processed gssapi TSIG > just before rfc editor started 48hour period we got a report > that there was a conflict between two the documents. > TSIG specifies that TSIG can only be used if original query > contains TSIG > GSSAPI specifies that last message in TKEY exchange has TSIG > last message is empty, and this proves the key negotiated is > working from security point of view this is a good thing > > TSIG needs minor updates before advancing to draft standard: > is this extensions one of them? > >The sense of the room was that this was a reasonable extensions and the >chair is instructed to take this question to the mailing list. Does the mailing list agree with this assessment and give its consensus that the lock on the GSS-API document be lifted ? Silence will be taken as agreement. Please post objections before Feb 12'th. thanks 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. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:21 2006 From: Edward Lewis Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents Date: Fri, 31 Jan 2003 15:47:23 -0500 Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <5.1.1.6.2.20030131124656.0191dd50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <5.1.1.6.2.20030131124656.0191dd50@localhost> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Precedence: bulk I'm not sure that I understand the question. The base TSIG PS document proscribes behavior in conflict with the proposed GSS-API. This conflict is allegedly removed either via an improvement to the base TSIG or by restricting the GSS-API proposal. As the former (improving the TSIG base) is more desirable, all things considered, the proposal is that GSS-API is allowed to proceed unmodified and that the TSIG base is improved. If I recall correctly, the above is what I think is being said. Although I agree with that assessment, that doesn't mean that I think it is a good idea to thaw the GSS-API document. I think it should be thawed in tandem with a document that proscribes the needed improvement to the TSIG base. I.e., a document specifying an extension to TSIG's base is needed before allowing an extension that would otherwise be in conflict. Basic principle: Make sure we have a clear base. Only then attempt modifications. Failure to heed this has proven in the past to lead to unpredictable consequences ("corner cases") when composing extensions and bases. At 14:36 -0500 1/31/03, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >From the minutes in ATLANTA: > > >>GSSAPI and TSIG conflict: >> DNSEXT wg generated TSIG RFC >> DNSEXT wg processed gssapi TSIG >> just before rfc editor started 48hour period we got a report >> that there was a conflict between two the documents. >> TSIG specifies that TSIG can only be used if original query >> contains TSIG >> GSSAPI specifies that last message in TKEY exchange has TSIG >> last message is empty, and this proves the key negotiated is >> working from security point of view this is a good thing >> >> TSIG needs minor updates before advancing to draft standard: >> is this extensions one of them? >> >>The sense of the room was that this was a reasonable extensions and the >>chair is instructed to take this question to the mailing list. > >Does the mailing list agree with this assessment and give >its consensus that the lock on the GSS-API document be lifted ? > >Silence will be taken as agreement. > >Please post objections before Feb 12'th. > >thanks > 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. >archive: -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: