From dns-dir-bounces@ietf.org Fri Aug 8 09:55:13 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136913A6CE8; Fri, 8 Aug 2008 09:55:13 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE333A6CE4; Fri, 8 Aug 2008 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY0daKOpxuqk; Fri, 8 Aug 2008 09:55:11 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 147D23A6C62; Fri, 8 Aug 2008 09:55:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,328,1215403200"; d="scan'208";a="117643055" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Aug 2008 12:55:05 -0400 X-IronPort-AV: E=Sophos;i="4.31,328,1215403200"; d="scan'208";a="253909702" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Aug 2008 12:55:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 18:55:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary agenda for the 8/14 IESG Telechat Thread-Index: Acj5d4AyHa7zj9wVSOWIM7diqUPwCg== From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , "IETF DNS Directorate" , Subject: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Please find below the preliminary agenda of the 8/14 IESG telechat. Please send me your questions, concerns and comments until 8/13 COB the latest. Thanks and Regards, Dan 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 - Information Model and XML Data Model for Traceroute Measurements (Proposed Standard) - draft-ietf-ippm-storetraceroutes-10.txt - Transport Mapping for Syslog (Proposed Standard) - draft-ietf-syslog-transport-tls-13.txt - Definitions of Textual Conventions for Pseudowires (PW) Management (Proposed Standard) - draft-ietf-pwe3-pw-tc-mib-14.txt - Guidelines for Application Designers on Using Unicast UDP (BCP) - draft-ietf-tsvwg-udp-guidelines-09.txt - Simple Network Management Protocol (SNMP) Context EngineID Discovery (Proposed Standard) - draft-ietf-opsawg-snmp-engineid-discovery-03.txt - Internet Message Store Events (Proposed Standard) - draft-ietf-lemonade-msgevent-06.txt 2.1.2 Returning Item - A Two-way Active Measurement Protocol (TWAMP) (Proposed Standard) - draft-ietf-ippm-twamp-09.txt 2.2 Individual Submissions 2.2.1 New Item - IANA Considerations for the IPv4 and IPv6 Router Alert Option (Proposed Standard) - draft-manner-router-alert-iana-03.txt - Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard) - draft-cain-post-inch-phishingextns-05.txt 3. Document Actions 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item - Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - draft-zhou-emu-fast-gtc-04.txt - Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - draft-cam-winget-eap-fast-provisioning-09.txt - Media Gateway Control Protocol Fax Package (Informational) - draft-andreasen-mgcp-fax-08.txt _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 12 02:09:54 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68033A6994; Tue, 12 Aug 2008 02:09:53 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5853A6924 for ; Tue, 12 Aug 2008 02:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4rsYWb-9F+E for ; Tue, 12 Aug 2008 02:09:51 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id EB0743A6994 for ; Tue, 12 Aug 2008 02:09:50 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSpt1-0002bv-K4; Tue, 12 Aug 2008 11:09:51 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id A39AD7E511F; Tue, 12 Aug 2008 11:09:50 +0200 (CEST) Date: Tue, 12 Aug 2008 11:09:49 +0200 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20080812090949.GA39227@unknown.office.denic.de> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: IETF DNS Directorate Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Dan, > Please find below the preliminary agenda of the 8/14 IESG telechat. > Please send me your questions, concerns and comments until 8/13 COB the > latest. a couple of drafts match DNS related keywords. I've looked into the following two: > - Guidelines for Application Designers on Using Unicast UDP (BCP) - > draft-ietf-tsvwg-udp-guidelines-09.txt Interesting from the DNS perspective is that our use of EDNS0 would likely be in conflict with "3.2. Message Size Guidelines". Another size related issue is asymmetry between requests and responses in UDP based protocols intended for Internet wide use. Under particular circumstances, this asymmetry can be abused for "amplification attacks". We know this for a subset of DNS, but any UDP based protocol that would respond with large chunks to arbitrary data would be vulnerable. As an unrealistic example, imagine a re-invention of the "chargen" protocol. Full disclosure: I've already mentioned this latter issue to the authors, but the conclusion was to wait for security review. > - Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, > and Other Crimeware (Proposed Standard) - > draft-cain-post-inch-phishingextns-05.txt See extra message with more detailed comments. No idea what to recommend here; the overall diction and idea don't seem to fit IETF style very well, but then I understand this is a leftover from the INCH WG - the history of which I just don't know. Generally appears gTLD centric with a couple of editorial and/or language issues. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 12 02:44:06 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6A23A6A07; Tue, 12 Aug 2008 02:44:06 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95C73A6A07 for ; Tue, 12 Aug 2008 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0czJXFMCDTpi for ; Tue, 12 Aug 2008 02:44:05 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 079BB3A683A for ; Tue, 12 Aug 2008 02:44:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,194,1217822400"; d="scan'208";a="139238821" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 12 Aug 2008 05:44:07 -0400 X-IronPort-AV: E=Sophos;i="4.32,194,1217822400"; d="scan'208";a="249461261" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Aug 2008 05:44:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 11:44:05 +0200 Message-ID: In-Reply-To: <20080812090949.GA39227@unknown.office.denic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat Thread-Index: Acj8WzGJtNbRtVpgRMmgLI8GDJ0bQAAAezOA References: <20080812090949.GA39227@unknown.office.denic.de> From: "Romascanu, Dan (Dan)" To: "Peter Koch" Cc: IETF DNS Directorate Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi Peter, Thanks for your reviews. See in-line wrt. draft-ietf-tsvwg-udp-guidelines-09.txt Dan > -----Original Message----- > From: Peter Koch [mailto:pk@DENIC.DE] > > > - Guidelines for Application Designers on Using Unicast UDP (BCP) - > > draft-ietf-tsvwg-udp-guidelines-09.txt > > Interesting from the DNS perspective is that our use of EDNS0 > would likely be in conflict with "3.2. Message Size Guidelines". This is not something new or unexpected. The Transport Considerations section of RFC2671 would be probably written differently today. I do not think that the document needs to be modified in any way, do you or somebody else think differently? > > Another size related issue is asymmetry between requests and > responses in UDP based protocols intended for Internet wide > use. Under particular circumstances, this asymmetry can be > abused for "amplification attacks". > We know this for a subset of DNS, but any UDP based protocol > that would respond with large chunks to arbitrary data would > be vulnerable. > As an unrealistic example, imagine a re-invention of the > "chargen" protocol. > > Full disclosure: I've already mentioned this latter issue to > the authors, > but the conclusion was to wait for security review. I do not know if SEC-DIR included this in their review, and I do not see yet the SEC Ads having entered a position. How would this change the guidelines as they currently show up in the document? Should asymmetry between requests and responses be discouraged, or does it need to be mentioned in the Security considerations sections of protocol documents that may have this characteristic? _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 12 03:07:06 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2B63A69EE; Tue, 12 Aug 2008 03:07:06 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F22D3A68D1 for ; Tue, 12 Aug 2008 03:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B8FPAxf+jBq for ; Tue, 12 Aug 2008 03:07:04 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id C24663A69BD for ; Tue, 12 Aug 2008 03:06:45 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSqlU-0000L1-IN; Tue, 12 Aug 2008 12:06:08 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 7A7177E5515; Tue, 12 Aug 2008 12:06:08 +0200 (CEST) Date: Tue, 12 Aug 2008 12:06:08 +0200 From: Peter Koch To: Patrick Cain , David Jevans Message-ID: <20080812100608.GA39395@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: dns-dir@ietf.org Subject: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hello, this is a review of . Its primary purpose is identifying DNS related issues as input to further review by the OPS and INT area directors. Regards, Peter Koch > Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, > and Other Crimeware > draft-cain-post-inch-phishingextns-05 > 3.3. Correctness of Fraud Activity Reports > > The Fraud Activity Report MUST pass XML validation using the schema > defined in [RFC5070] and the extensions defined in > > of this document. This headline should be renamed "Syntactical Correctness ..." because it could otherwise be perdevied to deal with the validation of the report content. > 4.5. FraudType attribute > 5. dnsspoof. This choice does not have a related FraudParameter. > This is used for a spoofed DNS (e.g., malware changes localhost > file so visits to www.example.com go to another IP address > chosen by the fraudster). DNS spoofing is usually to involve forged DNS responses, not manipulating the resolution path. It could be argued that in the case described here, DNS doesn't even get used. > 4.9.2. DomainData element > > Zero or more element values. The DomainData element describes the > registration, delegation, and control of a domain used to source the > lure. Capturing the domain data is very useful when investigating or > correlating events. It is unclear to me what "domain used to source the lure" means. Is it the header or envelope From address of an email? > The structure of a DomainData element is as follows: > > +--------------------+ > | DomainData | > +--------------------+ > | |<>----------[ Name ] > | |<>--(0..1)--[ DateDomainWasChecked ] > | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] > | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] > | |<>--(0..*)--[ Nameservers ] > | |<>--(0..*)--[ DNSRecord ] > | |<>--(0..*)--[ DomainContacts ] > +--------------------+ > > Figure 4.3 The DomainData element [...] > 4.9.2.1. Name > > REQUIRED. One value of iodef:MLStringType [RFC5070], Section 2.4]. > The Name element is the domain name used in this event. How is usage defined here? Also, judging from the following, if the authors believe that the domain name should be modified to just cover the "registry level", they should make that explicit: If "www.example.com" was "used", would "www.example.com" or just "example.com" appear in the report? > 4.9.2.6. DNSRecord element > > Zero or more values. This element allows the reporter to duplicate > the DNS record data as defined by [RFC1034], and returned by the DNS. > Including this information allows for tracking, trending, and > identification of the very transient DNS mapping and structure of > crimeware domains. > > +----------------+ > | DNSRecord | > +----------------+ > | |<>--(1..1)--[ owner ] > | |<>--(1..1)--[ type ] > | |<>--(0..1)--[ class ] > | |<>--(0..1)--[ ttl ] > | |<>--(1..1)--[ rdata ] > +----------------+ > > Figure 4.4 The DomainContacts element I wonder why we do not already have an XML schema describing DNS RRs. > 4.9.2.6.1. owner element > > REQUIRED. One String Value. This element identifies the superior > node in the DNS hierarchy. "Superior node" is either a wrong description (Is "example.com" superior to "www.example.com"?) or an outright misunderstanding of what a "DNS owner name" means. > 4.9.2.6.3. class element > > Zero or one value of a STRING. This field contains one value from > the IANA DNS Domain System Class Registry. The value will be the two > character representation of class, instead of a decimal number to > ease data entry from standard DNS tools. The default value for this > field is "IN" to note the Internet. Not being an XML expert this still seems to be in conflict with the schema defined later, which makes this mandatory. Also I'm not sure why and how anything else but "IN" would come into play. > 4.9.2.7.1. SameDomainContact > > REQUIRED. One iodef:DNSNAME. The SameDomainContact element is > populated with a domain name if the contact information for this > domain is identical to that name in this or another report. > Implementors are cautioned to only use this element when the domain > contact data returned by the registrar is identical. This tacitly assumes a "thin registry" model; s/registrar/registrar or registry/; > 4.9.2.7.2.1. Role attribute > > REQUIRED. ENUM. The role attribute is extended from the iodef:role- > ext attribute with values identified in [CRISP]. The role-ext value The reference is broken. Also, the protocol's name is IRIS, not CRISP. > of the role attribute should be used, with the role-ext attribute > value chosen from one of the following values: > > 1. registrant. This identified Contact is the domain registrant. > > 2. registrar. This contact identifies the registrar of this > domain. > > 3. billing. This entry is the billing or financial contact. > > 4. technical. This contact deals with technical issues. > > 5. administrative. This contact handles administrative matters for > this domain. > > 6. legal. This entry deals with legal issues for this domain. > > 7. zone. This entry controls the DNS zone information. > > 8. abuse. This entry accepts abuse issues. > > 9. security. This entry accepts security issues. Why have the attribute values been chosen to differ from those defined in IRIS-DREG? > 10. domainOwner. This lists the owner of the domain. This doesn't appear in RFC 3982. How is the "owner" different from the "registrant"? > 11. ipAddressOwner. This entry identifies the assignee of the IP > address space. Which IP address space? > 12. hostingProvider. This contact is the hosting provider of this > domain. At best, this should be _a_ provider, not _the_. > 4.9.3. SystemStatus attribute > > REQUIRED. ENUM. The SystemStatus attribute assesses a domain's > involvement in this event. Domains are elements in a name space, not acting parties. How can a domain be "involved" in anything? The IETF should resist the temptation to standardize colloquial abuse of the meaning of "domain". > 1. spoofed. This domain or system did not participate in this > event, but its address space or DNS name was forged. It's just identifiers, but "spoofed" and "forged" appear to me as different scenarios. > 4.9.4. DomainStatus attribute > > ENUM. The DomainStatus attribute describes the registry status of a > domain at the time of the report. The below enumerated list is taken > verbose from the 'domainStatusType' of the Extensible Provisioning > Protocol[RFC4933] and "Domain Registry Version 2 for the Internet > Registry Information Service" internet-draft [CRISP]. NIT: no longer an "internet-draft". > 4.9.7.1.1. Name element > > One STRING, representing the WINDOWS Operating System Registry Key > Name. Ouch; shouldn't the document then at least have a reference to such Key Names' syntax? Better yet, no OS would be preferred over others and this be redefined as "vendor specific key" or similar. > 4.17. EmailRecord element > > Extensions are also made to the iodef:Incident.EventData element to > include the actual email message received in phishing lure or > widespread spam emails. The ability to report spam is included > within a PhraudReport to support exchanging information about large- > scale spam activities related to phishing, not necessarily a single > spam message to a user. As such the spam reporting mechanism was not > designed to minimize overhead and processing, but to support other > widely-used spam reporting formats such as the MAAWG's Abuse > Reporting Format [ARF]. > > Reporting of the actual mail message is supported by choosing one of > three methods. First, an ARF message may be included. Second, the > message may be included as one large string. Third, the header and > body components may be dissected and included as a series of strings. [...] > 4.17.2.2. ARFText > > Zero or one value of STRING. The Messaging Anti-Abuse Working Group > (MAAWG) defined a format for sending abuse and list control traffic > to other parties. Since many of these reports will get integrated > into incident processes, the raw Abuse Reporting Format [ARF] may be > inserted into this element. This seems to suggest a normative reference to the "Abuse Reporting Format", but the [ARF] reference is informative only and, more importantly, is MAAWG eligible for normative references at all? > Appendix B. Example Virus Report The examples in this appendix contains lots of non-RFC2606 domain names and non-reserved IP addresses. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 12 03:19:10 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777023A69ED; Tue, 12 Aug 2008 03:19:10 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB69B3A69ED for ; Tue, 12 Aug 2008 03:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfCZRPcvuCmA for ; Tue, 12 Aug 2008 03:19:08 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0675D3A68D1 for ; Tue, 12 Aug 2008 03:19:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,195,1217822400"; d="scan'208";a="117969324" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Aug 2008 06:18:07 -0400 X-IronPort-AV: E=Sophos;i="4.32,195,1217822400"; d="scan'208";a="249478820" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Aug 2008 06:18:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 12:18:04 +0200 Message-ID: In-Reply-To: <20080812100608.GA39395@unknown.office.denic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt Thread-Index: Acj8YzHjnZ3A11c+RvWMoW9X8HrEzAAAT/2w References: <20080812100608.GA39395@unknown.office.denic.de> From: "Romascanu, Dan (Dan)" To: "Peter Koch" , "Patrick Cain" , "David Jevans" Cc: dns-dir@ietf.org Subject: Re: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Thanks, Peter. I will forward this also to the IESG and will discuss with the INT and SEC Area Directors what needs to be turned into clocking comments. Dan > -----Original Message----- > From: dns-dir-bounces@ietf.org > [mailto:dns-dir-bounces@ietf.org] On Behalf Of Peter Koch > Sent: Tuesday, August 12, 2008 1:06 PM > To: Patrick Cain; David Jevans > Cc: dns-dir@ietf.org > Subject: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt > > Hello, > > this is a review of > . Its primary > purpose is identifying DNS related issues as input to further > review by the OPS and INT area directors. > > Regards, > Peter Koch > > > Extensions to the IODEF-Document Class for Reporting > Phishing, Fraud, > > and Other Crimeware > > draft-cain-post-inch-phishingextns-05 > > > > 3.3. Correctness of Fraud Activity Reports > > > > The Fraud Activity Report MUST pass XML validation using > the schema > > defined in [RFC5070] and the extensions defined in > > > > of this document. > > This headline should be renamed "Syntactical Correctness ..." > because it could otherwise be perdevied to deal with the > validation of the report content. > > > 4.5. FraudType attribute > > > 5. dnsspoof. This choice does not have a related > FraudParameter. > > This is used for a spoofed DNS (e.g., malware > changes localhost > > file so visits to www.example.com go to another IP address > > chosen by the fraudster). > > DNS spoofing is usually to involve forged DNS responses, not > manipulating the resolution path. It could be argued that in > the case described here, DNS doesn't even get used. > > > 4.9.2. DomainData element > > > > Zero or more element values. The DomainData element > describes the > > registration, delegation, and control of a domain used > to source the > > lure. Capturing the domain data is very useful when > investigating or > > correlating events. > > It is unclear to me what "domain used to source the lure" > means. Is it the header or envelope From address of an email? > > > The structure of a DomainData element is as follows: > > > > +--------------------+ > > | DomainData | > > +--------------------+ > > | |<>----------[ Name ] > > | |<>--(0..1)--[ DateDomainWasChecked ] > > | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] > > | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] > > | |<>--(0..*)--[ Nameservers ] > > | |<>--(0..*)--[ DNSRecord ] > > | |<>--(0..*)--[ DomainContacts ] > > +--------------------+ > > > > Figure 4.3 The DomainData element > [...] > > 4.9.2.1. Name > > > > REQUIRED. One value of iodef:MLStringType [RFC5070], > Section 2.4]. > > The Name element is the domain name used in this event. > > How is usage defined here? Also, judging from the following, > if the authors believe that the domain name should be > modified to just cover the "registry level", they should make > that explicit: > If "www.example.com" was "used", would "www.example.com" or > just "example.com" appear in the report? > > > 4.9.2.6. DNSRecord element > > > > Zero or more values. This element allows the reporter > to duplicate > > the DNS record data as defined by [RFC1034], and > returned by the DNS. > > Including this information allows for tracking, trending, and > > identification of the very transient DNS mapping and structure of > > crimeware domains. > > > > +----------------+ > > | DNSRecord | > > +----------------+ > > | |<>--(1..1)--[ owner ] > > | |<>--(1..1)--[ type ] > > | |<>--(0..1)--[ class ] > > | |<>--(0..1)--[ ttl ] > > | |<>--(1..1)--[ rdata ] > > +----------------+ > > > > Figure 4.4 The DomainContacts element > > I wonder why we do not already have an XML schema describing DNS RRs. > > > 4.9.2.6.1. owner element > > > > REQUIRED. One String Value. This element identifies > the superior > > node in the DNS hierarchy. > > "Superior node" is either a wrong description (Is > "example.com" superior to "www.example.com"?) or an outright > misunderstanding of what a "DNS owner name" means. > > > 4.9.2.6.3. class element > > > > Zero or one value of a STRING. This field contains one > value from > > the IANA DNS Domain System Class Registry. The value > will be the two > > character representation of class, instead of a decimal number to > > ease data entry from standard DNS tools. The default > value for this > > field is "IN" to note the Internet. > > Not being an XML expert this still seems to be in conflict > with the schema defined later, which makes this mandatory. > Also I'm not sure why and how anything else but "IN" would > come into play. > > > 4.9.2.7.1. SameDomainContact > > > > REQUIRED. One iodef:DNSNAME. The SameDomainContact element is > > populated with a domain name if the contact information for this > > domain is identical to that name in this or another report. > > Implementors are cautioned to only use this element when > the domain > > contact data returned by the registrar is identical. > > This tacitly assumes a "thin registry" model; > s/registrar/registrar or registry/; > > > 4.9.2.7.2.1. Role attribute > > > > REQUIRED. ENUM. The role attribute is extended from > the iodef:role- > > ext attribute with values identified in [CRISP]. The role-ext > > value > > The reference is broken. Also, the protocol's name is IRIS, not CRISP. > > > of the role attribute should be used, with the role-ext attribute > > value chosen from one of the following values: > > > > 1. registrant. This identified Contact is the domain > registrant. > > > > 2. registrar. This contact identifies the registrar of this > > domain. > > > > 3. billing. This entry is the billing or financial contact. > > > > 4. technical. This contact deals with technical issues. > > > > 5. administrative. This contact handles > administrative matters for > > this domain. > > > > 6. legal. This entry deals with legal issues for this domain. > > > > 7. zone. This entry controls the DNS zone information. > > > > 8. abuse. This entry accepts abuse issues. > > > > 9. security. This entry accepts security issues. > > Why have the attribute values been chosen to differ from > those defined in IRIS-DREG? > > > 10. domainOwner. This lists the owner of the domain. > > This doesn't appear in RFC 3982. How is the "owner" > different from the "registrant"? > > > 11. ipAddressOwner. This entry identifies the assignee > of the IP > > address space. > > Which IP address space? > > > 12. hostingProvider. This contact is the hosting > provider of this > > domain. > > At best, this should be _a_ provider, not _the_. > > > 4.9.3. SystemStatus attribute > > > > REQUIRED. ENUM. The SystemStatus attribute assesses a domain's > > involvement in this event. > > Domains are elements in a name space, not acting parties. > How can a domain be "involved" in anything? The IETF should > resist the temptation to standardize colloquial abuse of the > meaning of "domain". > > > 1. spoofed. This domain or system did not participate in this > > event, but its address space or DNS name was forged. > > It's just identifiers, but "spoofed" and "forged" appear to > me as different scenarios. > > > 4.9.4. DomainStatus attribute > > > > ENUM. The DomainStatus attribute describes the registry > status of a > > domain at the time of the report. The below enumerated > list is taken > > verbose from the 'domainStatusType' of the Extensible > Provisioning > > Protocol[RFC4933] and "Domain Registry Version 2 for the Internet > > Registry Information Service" internet-draft [CRISP]. > > NIT: no longer an "internet-draft". > > > 4.9.7.1.1. Name element > > > > One STRING, representing the WINDOWS Operating System > Registry Key > > Name. > > Ouch; shouldn't the document then at least have a reference > to such Key Names' syntax? > Better yet, no OS would be preferred over others and this be > redefined as "vendor specific key" or similar. > > > 4.17. EmailRecord element > > > > Extensions are also made to the iodef:Incident.EventData > element to > > include the actual email message received in phishing lure or > > widespread spam emails. The ability to report spam is included > > within a PhraudReport to support exchanging information > about large- > > scale spam activities related to phishing, not > necessarily a single > > spam message to a user. As such the spam reporting > mechanism was not > > designed to minimize overhead and processing, but to > support other > > widely-used spam reporting formats such as the MAAWG's Abuse > > Reporting Format [ARF]. > > > > Reporting of the actual mail message is supported by > choosing one of > > three methods. First, an ARF message may be included. > Second, the > > message may be included as one large string. Third, the > header and > > body components may be dissected and included as a > series of strings. > > [...] > > > 4.17.2.2. ARFText > > > > Zero or one value of STRING. The Messaging Anti-Abuse > Working Group > > (MAAWG) defined a format for sending abuse and list > control traffic > > to other parties. Since many of these reports will get > integrated > > into incident processes, the raw Abuse Reporting Format > [ARF] may be > > inserted into this element. > > This seems to suggest a normative reference to the "Abuse > Reporting Format", but the [ARF] reference is informative > only and, more importantly, is MAAWG eligible for normative > references at all? > > > Appendix B. Example Virus Report > > The examples in this appendix contains lots of non-RFC2606 > domain names and non-reserved IP addresses. > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 12 09:37:29 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE023A6A8F; Tue, 12 Aug 2008 09:37:29 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF95E3A6A8F for ; Tue, 12 Aug 2008 09:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH5KVv-PFEYd for ; Tue, 12 Aug 2008 09:37:28 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 6CDF83A6780 for ; Tue, 12 Aug 2008 09:37:11 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSwri-0000uj-7x; Tue, 12 Aug 2008 18:36:58 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 19AB87E6343; Tue, 12 Aug 2008 18:36:57 +0200 (CEST) Date: Tue, 12 Aug 2008 18:36:57 +0200 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20080812163657.GG39395@unknown.office.denic.de> References: <20080812090949.GA39227@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: IETF DNS Directorate Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi Dan, > > > draft-ietf-tsvwg-udp-guidelines-09.txt > > > > Interesting from the DNS perspective is that our use of EDNS0 > > would likely be in conflict with "3.2. Message Size Guidelines". > > This is not something new or unexpected. The Transport Considerations > section of RFC2671 would be probably written differently today. I do not > think that the document needs to be modified in any way, do you or > somebody else think differently? no, the document is fine, as I understand it won't be in the way of advancing EDNS0 on the standards track. > > Another size related issue is asymmetry between requests and > > responses in UDP based protocols intended for Internet wide > > use. Under particular circumstances, this asymmetry can be > > abused for "amplification attacks". [...] > I do not know if SEC-DIR included this in their review, and I do not see > yet the SEC Ads having entered a position. How would this change the > guidelines as they currently show up in the document? Should asymmetry > between requests and responses be discouraged, or does it need to be > mentioned in the Security considerations sections of protocol documents > that may have this characteristic? I think it's difficult to generally discourage the size asymmetry, because its effect depends on multiple factors only known when the protocol is designed. Pointing out the issue to be addressed in that particular protocol's security considerations is absolutely sufficient IMHO and up to the security folks whether any such pointer is necessary here. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Aug 14 09:36:40 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B7428C154; Thu, 14 Aug 2008 09:36:40 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2579F3A6BEC for ; Thu, 14 Aug 2008 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyJ3a0IUHnjT for ; Thu, 14 Aug 2008 09:36:39 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 2147C3A6CB2 for ; Thu, 14 Aug 2008 09:36:30 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 14 Aug 2008 09:35:31 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Aug 2008 09:36:31 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Aug 2008 09:36:31 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 12:36:30 -0400 Received: from [172.28.13.44] ([172.28.13.44] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 12:36:29 -0400 Message-ID: <48A45F0A.5000309@juniper.net> Date: Thu, 14 Aug 2008 12:36:26 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Peter Koch References: <20080812090949.GA39227@unknown.office.denic.de> In-Reply-To: <20080812090949.GA39227@unknown.office.denic.de> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 14 Aug 2008 16:36:29.0985 (UTC) FILETIME=[E76DF110:01C8FE2B] Cc: IETF DNS Directorate Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Peter, Thanks for the heads up. The Transport ADs didn't post a ballot for this draft, so we couldn't vote on it or register comments. This document will return to the agenda in two weeks. Ron Peter Koch wrote: > Dan, > >> Please find below the preliminary agenda of the 8/14 IESG telechat. >> Please send me your questions, concerns and comments until 8/13 COB the >> latest. > > a couple of drafts match DNS related keywords. I've looked into the following > two: > >> - Guidelines for Application Designers on Using Unicast UDP (BCP) - >> draft-ietf-tsvwg-udp-guidelines-09.txt > > Interesting from the DNS perspective is that our use of EDNS0 would likely > be in conflict with "3.2. Message Size Guidelines". > > Another size related issue is asymmetry between requests and responses > in UDP based protocols intended for Internet wide use. Under particular > circumstances, this asymmetry can be abused for "amplification attacks". > We know this for a subset of DNS, but any UDP based protocol that would > respond with large chunks to arbitrary data would be vulnerable. > As an unrealistic example, imagine a re-invention of the "chargen" protocol. > > Full disclosure: I've already mentioned this latter issue to the authors, > but the conclusion was to wait for security review. > >> - Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, >> and Other Crimeware (Proposed Standard) - >> draft-cain-post-inch-phishingextns-05.txt > > See extra message with more detailed comments. No idea what to recommend > here; the overall diction and idea don't seem to fit IETF style very > well, but then I understand this is a leftover from the INCH WG - the > history of which I just don't know. Generally appears gTLD centric > with a couple of editorial and/or language issues. > > -Peter > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Fri Aug 15 02:57:39 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B682D3A69E1; Fri, 15 Aug 2008 02:57:39 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B2F3A6784 for ; Fri, 15 Aug 2008 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11jrVDyq2Fjo for ; Fri, 15 Aug 2008 02:57:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 044C83A6A49 for ; Fri, 15 Aug 2008 02:57:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,214,1217822400"; d="scan'208";a="118398147" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Aug 2008 05:57:40 -0400 X-IronPort-AV: E=Sophos;i="4.32,214,1217822400"; d="scan'208";a="259106638" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Aug 2008 05:57:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 11:57:37 +0200 Message-ID: In-Reply-To: <48A45F0A.5000309@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat Thread-Index: Acj+K+7rxu88nv/iRZ+M258jx8FDewAkSFXQ References: <20080812090949.GA39227@unknown.office.denic.de> <48A45F0A.5000309@juniper.net> From: "Romascanu, Dan (Dan)" To: "Ron Bonica" , "Peter Koch" Cc: IETF DNS Directorate Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Actually a ballot was possible (accessed from the IETF tracker) and I entered a DISCUSS on the asymmetry issue. Lars proposed the following solution: > How about adding this sentence to the first paragraph of the security considerations section: "Applications that respond to short requests with potentially large responses are vulnerable to amplification attacks, and SHOULD authenticate the sender before responding. The source IP address of a request is not a useful authenticator, because it can be spoofed." Dan > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: Thursday, August 14, 2008 7:36 PM > To: Peter Koch > Cc: Romascanu, Dan (Dan); IETF DNS Directorate > Subject: Re: [dns-dir] Preliminary agenda for the 8/14 IESG Telechat > > Peter, > > Thanks for the heads up. The Transport ADs didn't post a > ballot for this draft, so we couldn't vote on it or register > comments. This document will return to the agenda in two weeks. > > Ron > > > Peter Koch wrote: > > Dan, > > > >> Please find below the preliminary agenda of the 8/14 IESG telechat. > >> Please send me your questions, concerns and comments until > 8/13 COB > >> the latest. > > > > a couple of drafts match DNS related keywords. I've looked > into the > > following > > two: > > > >> - Guidelines for Application Designers on Using Unicast > UDP (BCP) - > >> draft-ietf-tsvwg-udp-guidelines-09.txt > > > > Interesting from the DNS perspective is that our use of EDNS0 would > > likely be in conflict with "3.2. Message Size Guidelines". > > > > Another size related issue is asymmetry between requests > and responses > > in UDP based protocols intended for Internet wide use. Under > > particular circumstances, this asymmetry can be abused for > "amplification attacks". > > We know this for a subset of DNS, but any UDP based protocol that > > would respond with large chunks to arbitrary data would be > vulnerable. > > As an unrealistic example, imagine a re-invention of the > "chargen" protocol. > > > > Full disclosure: I've already mentioned this latter issue > to the authors, > > but the conclusion was to wait for security review. > > > >> - Extensions to the IODEF-Document Class for Reporting Phishing, > >> Fraud, and Other Crimeware (Proposed Standard) - > >> draft-cain-post-inch-phishingextns-05.txt > > > > See extra message with more detailed comments. No idea what to > > recommend here; the overall diction and idea don't seem to > fit IETF > > style very well, but then I understand this is a leftover from the > > INCH WG - the history of which I just don't know. > Generally appears > > gTLD centric with a couple of editorial and/or language issues. > > > > -Peter > > _______________________________________________ > > dns-dir mailing list > > dns-dir@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-dir > > > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 19 11:32:05 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9341C28C18B; Tue, 19 Aug 2008 11:32:05 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384CA28C1FF for ; Tue, 19 Aug 2008 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+LxzbumpZ2f for ; Tue, 19 Aug 2008 11:32:03 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 887733A6AEB for ; Tue, 19 Aug 2008 11:31:57 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KVVck-0007tS-SU; Tue, 19 Aug 2008 20:08:06 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id C66FC7E99DB; Tue, 19 Aug 2008 20:08:06 +0200 (CEST) Date: Tue, 19 Aug 2008 20:08:06 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20080819180806.GM1740@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] Draft Minutes of 2nd Meeting (Thursday) at IETF72 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear All, with apologies for the delay, here is a draft version of our second DNS directorate meeting over Thursday's dinner at IETF72. Please let me know of any omissions or inaccuracies in this or the Tuesday meeting minutes. -Peter --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="IETF72-Minutes2.txt" ----------------------------------------------------------------------------- D R A F T M I N U T E S ----------------------------------------------------------------------------- 2008-07-31 20:25-22:30 UTC+1 DNS Directorate Meeting II at IETF72 ----------------------------------------------------------------------------- Tom, Olafur, Matt, Erik, Andrew, Liman, Peter, Olaf, Roy ----------------------------------------------------------------------------- $Id: IETF72-Minutes2.txt,v 1.2 2008/08/19 18:03:14 pk Exp $ ----------------------------------------------------------------------------- o Pending IESG Statement on RFC 2606 ("example.org") and 2606bis [?] Also: The draft (meanwhile available: draft-ellermann-idnabis-test-tlds-11.txt) strives to amend RFC 2606/BCP 32) with additional "reserved" TLDs for example and test use, most notably the IDN test TLDs created by ICANN/IANA. Discussion: This needs to be brought to Thomas as ICANN Liaison, it should also be subject to a "laugh test" with some people in ICANN and IANA. The current status of the document is unclear. Vint Cerf (idnabis chair), Lisa Dusseault (APPS AD) and Thomas (see above) shoudl be informed that the DNS Directorate is having an eye on this draft and offers review. [Action]: Olaf to coordinate with Thomas Second issue: other ASCII TLDs for 2 reasons: 1) conflict with .local 2) have more "usable" TLDs available for examples and documentation touches upon gTLD selection process and is ICANN policy anyway would likely be in conflict with IAB response to ICANN on gTLD selection criteria Olaf suggests to only discuss tradeoffs, provide considerations, but to not make strong recommendations w.r.t. single letter doamins, digits etc.; also "local." should not be explicitly named, but it could be documented that "some" TLDs are in widespread use and might cause problems. o Signing the DNS root [?] [Skipped] o IANA accused of "bypassing" the IETF in setting up the TLD TAR [Peter] [Skipped] o Returning Patterns of suboptimal/concerning use of the DNS [Skipped] o DNS and Cookie Spec Issues [Skipped] o DNS related language and terminology in RFCs [Skipped] o Weight of DNS considerations in IESG review [Skipped] o Fast Flux Draft [Roy, Peter] Submitted to RFC Editor on Independent Submission Stream This draft was briefly discussed on the directorate mailing list; it raised some operational concerns and can be read to redefine protocol semantics, thus competing with the DNSEXT WG. [Action]: Roy to take this to the Author, the RFC Editor, the 4 ADs, and the DNS directorate o SRV port name/number registry at IANA Several drafts, including those mentioned above, propose work and procedural changes in the area of port numbers and port identifier assignment, including use of identifiers in the "Service" part of the SRV owner name. Dave Crocker has also been working in that area, proposing an "underscore label registry". The directorate discussed whether this was a DNS issue at all or something merely happening in APPS, because it was _use_ of an already existing RR type. There was rough consensus that DNS clue needed to be injected, especially when "underscore labels" would be declared special and/or the applicability statement of RFC 2782 (SRV RR) was modified or generalized. [Action]: {note is incomplete, but lists Olafur -- apologies} o HTTP based DNS zone data provisioning The draft specifies an HTTP based DNS zone update mechanism; it is an individual submission that was briefly discussed on the APPS Area discussion list; both Peter and Patrik have been in contact with Cullen; intended status and direction of the draft are not yet completely clear o IRTF DNS related drafts - "DNS Blacklists and Whitelists" - "Guidelines for Management of DNSBLs for Email" [Action]: Peter to contact Lisa w.r.t. review for an AD sponsored document on Standards Track [Action]: Roy to find reviewers for both drafts; the 2nd might also go into DNSOP o The Myth of 13 Root Name Servers [Skipped] 2230 c/d ----------------------------------------------------------------------------- --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --7AUc2qLy4jB3hD7Z-- From dns-dir-bounces@ietf.org Tue Aug 19 11:48:22 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F51A3A69CE; Tue, 19 Aug 2008 11:48:22 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127DA3A68E0 for ; Tue, 19 Aug 2008 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiHGdfrl7So1 for ; Tue, 19 Aug 2008 11:48:14 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 66F0F3A69CE for ; Tue, 19 Aug 2008 11:48:14 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KVVlZ-00045Q-I4; Tue, 19 Aug 2008 20:17:13 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 7D71E7E9A04; Tue, 19 Aug 2008 20:17:13 +0200 (CEST) Date: Tue, 19 Aug 2008 20:17:13 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20080819181713.GN1740@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] Meeting/TelCo 2008-09-01 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Dear DNS Directorate Members, in Dublin we agreed upon a monthly conf call, the next to be scheduled 1 September, 1600 Paris local time (1400 UTC). The "escape clause" was that there MUST be an agenda one week in advance (25 August). Given that we postponed a couple of agenda items during the physical meetings in Dublin, I'd like to suggest we start with these leftovers: o Review of Action Items o Returning Patterns of suboptimal/concerning use of the DNS o DNS and HTTP Cookie Spec Issues o DNS related language and terminology in RFCs Please let me know additional topics (or req for changes) by Friday this week. The plan was to use Nominet's Telco logistics for the call (thanks to Roy, who is kindly asked to follow up with the details). -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 19 16:52:24 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF88E3A6C5D; Tue, 19 Aug 2008 16:52:24 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555383A6C5D for ; Tue, 19 Aug 2008 16:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.408 X-Spam-Level: * X-Spam-Status: No, score=1.408 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_50=0.001, HELO_EQ_SE=0.35, MANGLED_FREE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1002WPxLYB9 for ; Tue, 19 Aug 2008 16:52:22 -0700 (PDT) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 85D373A6A49 for ; Tue, 19 Aug 2008 16:52:22 -0700 (PDT) Received: from core.dnss.ec (core.dnss.ec [82.94.105.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 5598E2D57F for ; Wed, 20 Aug 2008 01:51:46 +0200 (MEST) Received: from [127.0.0.1] by core.dnss.ec (PGP Universal service); Wed, 20 Aug 2008 01:51:46 +0200 X-PGP-Universal: processed; by core.dnss.ec on Wed, 20 Aug 2008 01:51:46 +0200 Message-Id: From: Roy Arends To: IETF DNS Directorate In-Reply-To: <20080819181713.GN1740@unknown.office.denic.de> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 20 Aug 2008 01:51:45 +0200 References: <20080819181713.GN1740@unknown.office.denic.de> X-Mailer: Apple Mail (2.928.1) Subject: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This meeting will be held on September 1st, 2008 at: 0700 San Francisco 1000 Washington 1400 UTC 1500 London 1600 Paris The teleconference logistics are as follows. You will hear music until the moderator joins. US (east) +1 7183541169 US (west) +1 4089616553 NL +31 202013852 UK +44 2078193600 FR +33 171230055 SE +46 858536827 CA 18667425608 FI +358 969379595 Conference Code: 4227104 If you have any issues dialing in, require a toll-free number or if your country is not in the above list, please contact me. I can also be reached over xmpp: roy@dnss.ec With kind regards, Roy _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 20 06:14:05 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B347A3A68C0; Wed, 20 Aug 2008 06:14:05 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D333A68AE for ; Wed, 20 Aug 2008 06:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw4caqlgMcNj for ; Wed, 20 Aug 2008 06:14:03 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 3C03E3A63C9 for ; Wed, 20 Aug 2008 06:14:03 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7KDDSOv018225 for ; Wed, 20 Aug 2008 09:13:28 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7KDDSPX173276 for ; Wed, 20 Aug 2008 09:13:28 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7KDDSIM019297 for ; Wed, 20 Aug 2008 09:13:28 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-45-102.mts.ibm.com [9.48.45.102]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7KDDRF4019191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 09:13:28 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m7KDDQUM022984; Wed, 20 Aug 2008 09:13:26 -0400 Message-Id: <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> To: Roy Arends In-reply-to: References: <20080819181713.GN1740@unknown.office.denic.de> Comments: In-reply-to Roy Arends message dated "Wed, 20 Aug 2008 01:51:45 +0200." Date: Wed, 20 Aug 2008 09:13:25 -0400 From: Thomas Narten Cc: IETF DNS Directorate Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > This meeting will be held on September 1st, 2008 at: That's Labor Day in US. I'll (hopefully) be having a fun day with the family. Thomas _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 20 07:17:29 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F9C3A6C1F; Wed, 20 Aug 2008 07:17:29 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76CE28C192 for ; Wed, 20 Aug 2008 07:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPTet3yz+t6m for ; Wed, 20 Aug 2008 07:17:26 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id E639328C164 for ; Wed, 20 Aug 2008 07:16:36 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7KEGJR7000827 for ; Wed, 20 Aug 2008 10:16:19 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7KEG3XT108672 for ; Wed, 20 Aug 2008 08:16:16 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7KEG3bT030742 for ; Wed, 20 Aug 2008 08:16:03 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-211-253.mts.ibm.com [9.65.211.253]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7KEG1VC030529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 08:16:02 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m7KEG0fK005253; Wed, 20 Aug 2008 10:16:00 -0400 Message-Id: <200808201416.m7KEG0fK005253@cichlid.raleigh.ibm.com> To: Peter Koch In-reply-to: <20080819180806.GM1740@unknown.office.denic.de> References: <20080819180806.GM1740@unknown.office.denic.de> Comments: In-reply-to Peter Koch message dated "Tue, 19 Aug 2008 20:08:06 +0200." Date: Wed, 20 Aug 2008 10:16:00 -0400 From: Thomas Narten Cc: IETF DNS Directorate Subject: Re: [dns-dir] Draft Minutes of 2nd Meeting (Thursday) at IETF72 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Some quick comments. > o IANA accused of "bypassing" the IETF in setting up the TLD TAR [Peter] > [Skipped] What is this? Does this refer to the Interim Trust Anchor Repository? If so, IANA did indeed coordinate with the IETF, though unofficially (i.e., there was no formal IAB statement). But Russ and Olaf were made aware of this (as were others) and AFAICT, there was universal support for going forward with the ITAR. (Basically, whatever concerns people had, the alternatives of IANA not creating this were worse, i.e., RIPE would have felt compelled to create the registry, which they didn't want to to do.) > o Returning Patterns of suboptimal/concerning use of the DNS > [Skipped] I'm curious as to what this is... > o DNS and Cookie Spec Issues > [Skipped] Ditto. > o DNS related language and terminology in RFCs > [Skipped] ?? > o Weight of DNS considerations in IESG review > [Skipped] ?? > o Fast Flux Draft [Roy, Peter] > > Submitted to RFC Editor on Independent Submission Stream > This draft was briefly discussed on the directorate mailing list; > it raised some operational concerns and can be read to redefine > protocol semantics, thus competing with the DNSEXT WG. > [Action]: Roy to take this to the Author, the RFC Editor, the 4 ADs, > and the DNS directorate I've also pinged Steve Crocker (SSAC) about whether they have looked at this. SSAC has studied the FF issue a bit and would be ICANN's focal point for clue about FF. > o SRV port name/number registry at IANA > > > Several drafts, including those mentioned above, propose work > and procedural changes in the area of port numbers and port > identifier assignment, including use of identifiers in the > "Service" part of the SRV owner name. Dave Crocker has also > been working in that area, proposing an "underscore label > registry". > The directorate discussed whether this was a DNS issue at all or > something merely happening in APPS, because it was _use_ of an > already existing RR type. There was rough consensus that DNS > clue needed to be injected, especially when "underscore labels" > would be declared special and/or the applicability statement > of RFC 2782 (SRV RR) was modified or generalized. > [Action]: {note is incomplete, but lists Olafur -- apologies} I believe that tsvwg-iana-ports is not trying to get into the SRV discussion. That document has enough stuff in it without tackling SRV. But, again, it is understood that an SRV registry is needed and someone needs to write a document. It would be good to (finally) make that happen. > o The Myth of 13 Root Name Servers > [Skipped] Is there a document that addresses this? From an ICANN perspective, a document is clearly needed that explains the 13 limit, and discusses the real issues. I have seen confusion even among the DNS clueful about what the real limits/restrictions are. Thomas _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 20 07:34:24 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56D03A6BF4; Wed, 20 Aug 2008 07:34:24 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C86D3A6BF4 for ; Wed, 20 Aug 2008 07:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cadmoSlYBOrD for ; Wed, 20 Aug 2008 07:34:19 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 7F81B28C1E0 for ; Wed, 20 Aug 2008 07:32:25 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7KEVfC6029928 for ; Wed, 20 Aug 2008 10:31:41 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7KEVfVg234662 for ; Wed, 20 Aug 2008 10:31:41 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7KEVeLp022392 for ; Wed, 20 Aug 2008 10:31:40 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-211-253.mts.ibm.com [9.65.211.253]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7KEVd28022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Aug 2008 10:31:40 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m7KEVcLb005418 for ; Wed, 20 Aug 2008 10:31:38 -0400 Message-Id: <200808201431.m7KEVcLb005418@cichlid.raleigh.ibm.com> To: dns-dir@ietf.org Date: Wed, 20 Aug 2008 10:31:38 -0400 From: Thomas Narten Subject: [dns-dir] FWD: [IANA #160339] RFC3832 - locate missing registry X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org FYI. IANA is cleaning up stuff that was not done correctly. It appears to me that RFC 3832 requests IANA to register a name for SRV records. But the mythical SRV registry doesn't formally exist... Thomas ------- Forwarded Message From: "Pearl Liang via RT" Cc: zwb@cs.columbia.edu, hgs@cs.columbia.edu, Erik.Guttman@sun.com, bisdik@us.ibm.com, wfj@us.ibm.com, narten@us.ibm.com Date: Mon, 18 Aug 2008 23:18:24 +0000 Subject: [IANA #160339] RFC3832 - locate missing registry Reply-To: iana-questions@icann.org RT-Ticket: IANA #160339 Managed-by: RT 3.5.HEAD (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org Dear Authors and AD: IANA currently completed a project to go through existing RFCs to verify if there were any IANA actions that were never completed. We are now going through the results of that project and are trying to determine if the actions should be performed or if they are not needed. We are contacting you as either an author, working group chair, area director or in an expert role for this RFC or protocol. If you feel that you can not assist in making suggestions, please let us know. REVIEWER COMMENTS: RFC 3832 Section 7 defines slpda tcp/udp and states that these are registered with IANA. It appears that the assignments were not being registered: Service Field Protocol Field Reference ------------- -------------- --------- slpda tcp [RFC3832] slpda udp [RFC3832] Could you let us know to which protocol/registry we register these assignments? Also are these under the protocol SLPv2? Please review the IANA Matrix: http://www.iana.org/protocols/ We thank you any help you can provide. When we receive a reply we will complete the action as soon as we can. Thank you in advance for your help and time. Regards, Pearl Liang IANA ------- End of Forwarded Message _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Aug 21 08:03:09 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4D83A68A6; Thu, 21 Aug 2008 08:03:09 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1173A68A6 for ; Thu, 21 Aug 2008 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jZ7NqPx4a1H for ; Thu, 21 Aug 2008 08:03:03 -0700 (PDT) Received: from cliffie.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id 6BEA43A67F4 for ; Thu, 21 Aug 2008 08:03:03 -0700 (PDT) Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id F26AC13676C for ; Thu, 21 Aug 2008 11:02:36 -0400 (EDT) Received: from dul1mcmlarson-l1.verisignlabs.com (dul1mcmlarson-l1.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id F07292423EF for ; Thu, 21 Aug 2008 11:02:36 -0400 (EDT) Date: Thu, 21 Aug 2008 11:02:29 -0400 From: Matt Larson To: IETF DNS Directorate Message-ID: <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.11 Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, 20 Aug 2008, Thomas Narten wrote: > > This meeting will be held on September 1st, 2008 at: > > That's Labor Day in US. I'll (hopefully) be having a fun day with the > family. Likewise. Is there any possibility of rescheduling? Matt _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Aug 21 08:57:12 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0653A6A31; Thu, 21 Aug 2008 08:57:12 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590DA3A6A8C for ; Thu, 21 Aug 2008 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqMjTBf1Qun5 for ; Thu, 21 Aug 2008 08:57:07 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id B7D0E3A69B2 for ; Thu, 21 Aug 2008 08:56:49 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KWCWu-0007hZ-SE; Thu, 21 Aug 2008 17:56:56 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id AD81A7EC8B7; Thu, 21 Aug 2008 17:56:56 +0200 (CEST) Date: Thu, 21 Aug 2008 17:56:56 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20080821155656.GC6169@unknown.office.denic.de> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Matt, all, > > That's Labor Day in US. I'll (hopefully) be having a fun day with the > > family. > > Likewise. Is there any possibility of rescheduling? I've set up another doodle poll at to choose between September, 1st and 8th. It says 2 pm - 3 pm, that is UTC (and 1600-1700 Paris local). Next time I'll try the new timezone support. Just for completeness, here are the next "regular" call dates: Monday, 6 October 2008 Monday, 3 November 2008 Monday,17 November 2008 [Lunch meeting @IETF73] Monday, 1 December 2008 Monday, 5 January 2009 -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sat Aug 23 23:53:37 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479063A6AF8; Sat, 23 Aug 2008 23:53:37 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A143F3A689B; Sat, 23 Aug 2008 23:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbitRfgnudZZ; Sat, 23 Aug 2008 23:53:34 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0E6BC3A67FD; Sat, 23 Aug 2008 23:53:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="132267476" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Aug 2008 02:53:13 -0400 X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="258529058" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Aug 2008 02:53:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Aug 2008 08:53:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for August 28, 2008 Telechat Thread-Index: AckD3eLBpz8FqVY6SVquGK+vCm6bxAB158Og From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Please see below the preliminary agenda of the 8/28 IESG telechat. Please send me comments and concerns related to the documents and WG charters brought up for approval until 8/27 COB the latest. Thanks and Regards, Dan 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-mpls-number-0-bw-te-lsps-11.txt A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link (Proposed Standard) - 1 of 1 Token: Ross Callon 2.1.2 Returning Item NONE 2.1.3 For Action o draft-ietf-opsawg-snmp-engineid-discovery-03.txt Simple Network Management Protocol (SNMP) Context EngineID Discovery (Proposed Standard) - 1 of 1 Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Item o draft-cain-post-inch-phishingextns-05.txt Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard) - 1 of 1 Token: Tim Polk 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mip6-whyauthdataoption-06.txt Why Authentication Data suboption is needed for MIP6 (Informational) - 1 of 1 Note: No document shepherd -- old MIP6 document Token: Jari Arkko 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-cam-winget-eap-fast-provisioning-09.txt Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - 1 of 2 Token: Tim Polk o draft-sun-dime-itu-t-rw-01.txt Diameter ITU-T Rw Policy Enforcement Interface Application (Informational) - 2 of 2 Token: Dan Romascanu 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-nmrg-snmp-measure-05.txt SNMP Traffic Measurements and Trace Exchange Formats (Informational) - 1 of 1 Note: Proposed IESG Note: . . The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing.. . This RFC is not a candidate for any level of Internet Standard.. The IETF disclaims any knowledge of the fitness of this RFC for. any purpose and notes that the decision to publish is not based on. IETF review apart from the IETF Last Call on the allocation of an URI by IANA and the IESG review for conflict with IETF work.. The RFC Editor has chosen to publish this document at its. discretion. See RFC 3932 for more information.. . Token: Dan Romascanu 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Operational Security Capabilities for IP Network Infrastructure (opsec) - 1 of 1 Token: Ron Bonica 4.2.2 Proposed for Approval o Sieve Mail Filtering Language (sieve) - 1 of 1 Token: Lisa Dusseault _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Aug 25 00:47:08 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF2A3A6902; Mon, 25 Aug 2008 00:47:08 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB563A688E for ; Mon, 25 Aug 2008 00:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZZQpL3Fs510 for ; Mon, 25 Aug 2008 00:47:06 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id A435B3A67E5 for ; Mon, 25 Aug 2008 00:47:06 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KXWmR-0005B6-1a; Mon, 25 Aug 2008 09:46:27 +0200 Received: from localhost by x27.adm.denic.de with local id 1KXWl1-0000Uo-Pa; Mon, 25 Aug 2008 09:44:59 +0200 Date: Mon, 25 Aug 2008 09:44:59 +0200 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20080825074459.GB28428@x27.adm.denic.de> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Dan, > 2.2.1 New Item > o draft-cain-post-inch-phishingextns-05.txt > Extensions to the IODEF-Document Class for Reporting Phishing, > Fraud, > and > Other Crimeware (Proposed Standard) - 1 of 1 this draft, deferred from 2008-08-14, was the only one triggering on my DNS keywords. Two weeks ago I sent in a review, but haven't heard back from the authors, yet. The proto summary now gave some helpful background information about the drafts history and current use of the scheme, but I'd re-submit my review here. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Aug 25 00:59:42 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A4F3A688E; Mon, 25 Aug 2008 00:59:42 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F943A688E for ; Mon, 25 Aug 2008 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_20=-0.74, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJzpecUYId6t for ; Mon, 25 Aug 2008 00:59:39 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 91C0F3A67E5 for ; Mon, 25 Aug 2008 00:59:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="txt'208?scan'208,208";a="140895086" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 25 Aug 2008 03:58:55 -0400 X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="txt'208?scan'208,208";a="265875353" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Aug 2008 03:58:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C90688.6AFCE40A" Date: Mon, 25 Aug 2008 09:58:52 +0200 Message-ID: In-Reply-To: <20080825074459.GB28428@x27.adm.denic.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat Thread-Index: AckGhrUuZjTqkcSuTgSx3ETHeF3OBAAAVPAg References: <20080825074459.GB28428@x27.adm.denic.de> From: "Romascanu, Dan (Dan)" To: "Peter Koch" Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C90688.6AFCE40A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am working to sort out the DISCUSS (show stoppers) from COMMENT (nice-to-have, nits) issues. It would be useful if you can indicate what you believe are the show stoppers in your review (attached) to make sure I do not miss anything critical.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Peter Koch [mailto:peter@denic.de] On Behalf Of Peter Koch > Sent: Monday, August 25, 2008 10:45 AM > To: Romascanu, Dan (Dan) > Cc: IETF DNS Directorate > Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for=20 > August 28, 2008 Telechat >=20 > Dan, >=20 > > 2.2.1 New Item > > o draft-cain-post-inch-phishingextns-05.txt > > Extensions to the IODEF-Document Class for Reporting Phishing,=20 > > Fraud, and > > Other Crimeware (Proposed Standard) - 1 of 1 >=20 > this draft, deferred from 2008-08-14, was the only one=20 > triggering on my DNS keywords. Two weeks ago I sent in a=20 > review, but haven't heard back from the authors, yet. The=20 > proto summary now gave some helpful background information=20 > about the drafts history and current use of the scheme, but=20 > I'd re-submit my review here. >=20 > -Peter >=20 ------_=_NextPart_001_01C90688.6AFCE40A Content-Type: text/plain; name="dns-dir review of draft-cain-post-inch-phishingextns-05.txt.txt" Content-Transfer-Encoding: base64 Content-Description: dns-dir review of draft-cain-post-inch-phishingextns-05.txt.txt Content-Disposition: attachment; filename="dns-dir review of draft-cain-post-inch-phishingextns-05.txt.txt" RnJvbTogZG5zLWRpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBQZXRlciBLb2NoIFtw a0BERU5JQy5ERV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxMiwgMjAwOCAxOjA2IFBNDQpUbzog UGF0cmljayBDYWluOyBEYXZpZCBKZXZhbnMNCkNjOiBkbnMtZGlyQGlldGYub3JnDQpTdWJqZWN0 OiBbZG5zLWRpcl0gcmV2aWV3IG9mIGRyYWZ0LWNhaW4tcG9zdC1pbmNoLXBoaXNoaW5nZXh0bnMt MDUudHh0DQoNCkhlbGxvLA0KDQp0aGlzIGlzIGEgcmV2aWV3IG9mIDxkcmFmdC1jYWluLXBvc3Qt aW5jaC1waGlzaGluZ2V4dG5zLTA1LnR4dD4uICBJdHMgcHJpbWFyeSBwdXJwb3NlIGlzIGlkZW50 aWZ5aW5nIEROUyByZWxhdGVkIGlzc3VlcyBhcyBpbnB1dCB0byBmdXJ0aGVyIHJldmlldyBieSB0 aGUgT1BTIGFuZCBJTlQgYXJlYSBkaXJlY3RvcnMuDQoNClJlZ2FyZHMsDQogIFBldGVyIEtvY2gN Cg0KPiAgRXh0ZW5zaW9ucyB0byB0aGUgSU9ERUYtRG9jdW1lbnQgQ2xhc3MgZm9yIFJlcG9ydGlu ZyBQaGlzaGluZywgRnJhdWQsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIE90aGVy IENyaW1ld2FyZQ0KPiAgICAgICAgICAgICAgICAgIGRyYWZ0LWNhaW4tcG9zdC1pbmNoLXBoaXNo aW5nZXh0bnMtMDUNCg0KDQo+IDMuMy4gIENvcnJlY3RuZXNzIG9mIEZyYXVkIEFjdGl2aXR5IFJl cG9ydHMNCj4gDQo+ICAgIFRoZSBGcmF1ZCBBY3Rpdml0eSBSZXBvcnQgTVVTVCBwYXNzIFhNTCB2 YWxpZGF0aW9uIHVzaW5nIHRoZSBzY2hlbWENCj4gICAgZGVmaW5lZCBpbiBbUkZDNTA3MF0gYW5k IHRoZSBleHRlbnNpb25zIGRlZmluZWQgaW4NCj4gDQo+ICAgIDxBcHBlbmRpeEE+IG9mIHRoaXMg ZG9jdW1lbnQuDQoNClRoaXMgaGVhZGxpbmUgc2hvdWxkIGJlIHJlbmFtZWQgIlN5bnRhY3RpY2Fs IENvcnJlY3RuZXNzIC4uLiIgYmVjYXVzZSBpdCBjb3VsZCBvdGhlcndpc2UgYmUgcGVyZGV2aWVk IHRvIGRlYWwgd2l0aCB0aGUgdmFsaWRhdGlvbiBvZiB0aGUgcmVwb3J0IGNvbnRlbnQuDQoNCj4g NC41LiAgRnJhdWRUeXBlIGF0dHJpYnV0ZQ0KDQo+ICAgIDUuICAgZG5zc3Bvb2YuICBUaGlzIGNo b2ljZSBkb2VzIG5vdCBoYXZlIGEgcmVsYXRlZCBGcmF1ZFBhcmFtZXRlci4NCj4gICAgICAgICBU aGlzIGlzIHVzZWQgZm9yIGEgc3Bvb2ZlZCBETlMgKGUuZy4sIG1hbHdhcmUgY2hhbmdlcyBsb2Nh bGhvc3QNCj4gICAgICAgICBmaWxlIHNvIHZpc2l0cyB0byB3d3cuZXhhbXBsZS5jb20gZ28gdG8g YW5vdGhlciBJUCBhZGRyZXNzDQo+ICAgICAgICAgY2hvc2VuIGJ5IHRoZSBmcmF1ZHN0ZXIpLg0K DQpETlMgc3Bvb2ZpbmcgaXMgdXN1YWxseSB0byBpbnZvbHZlIGZvcmdlZCBETlMgcmVzcG9uc2Vz LCBub3QgbWFuaXB1bGF0aW5nIHRoZSByZXNvbHV0aW9uIHBhdGguICBJdCBjb3VsZCBiZSBhcmd1 ZWQgdGhhdCBpbiB0aGUgY2FzZSBkZXNjcmliZWQgaGVyZSwgRE5TIGRvZXNuJ3QgZXZlbiBnZXQg dXNlZC4NCg0KPiA0LjkuMi4gIERvbWFpbkRhdGEgZWxlbWVudA0KPiANCj4gICAgWmVybyBvciBt b3JlIGVsZW1lbnQgdmFsdWVzLiAgVGhlIERvbWFpbkRhdGEgZWxlbWVudCBkZXNjcmliZXMgdGhl DQo+ICAgIHJlZ2lzdHJhdGlvbiwgZGVsZWdhdGlvbiwgYW5kIGNvbnRyb2wgb2YgYSBkb21haW4g dXNlZCB0byBzb3VyY2UgdGhlDQo+ICAgIGx1cmUuICBDYXB0dXJpbmcgdGhlIGRvbWFpbiBkYXRh IGlzIHZlcnkgdXNlZnVsIHdoZW4gaW52ZXN0aWdhdGluZyBvcg0KPiAgICBjb3JyZWxhdGluZyBl dmVudHMuDQoNCkl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCAiZG9tYWluIHVzZWQgdG8gc291cmNl IHRoZSBsdXJlIiBtZWFucy4gIElzIGl0IHRoZSBoZWFkZXIgb3IgZW52ZWxvcGUgRnJvbSBhZGRy ZXNzIG9mIGFuIGVtYWlsPw0KDQo+ICAgIFRoZSBzdHJ1Y3R1cmUgb2YgYSBEb21haW5EYXRhIGVs ZW1lbnQgaXMgYXMgZm9sbG93czoNCj4gDQo+ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4g ICAgfCBEb21haW5EYXRhICAgICAgICAgfA0KPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ ICAgIHwgICAgICAgICAgICAgICAgICAgIHw8Pi0tLS0tLS0tLS1bIE5hbWUgXQ0KPiAgICB8ICAg ICAgICAgICAgICAgICAgICB8PD4tLSgwLi4xKS0tWyBEYXRlRG9tYWluV2FzQ2hlY2tlZCBdDQo+ ICAgIHwgRU5VTSBTeXN0ZW1TdGF0dXMgIHw8Pi0tKDAuLjEpLS1bIFJlZ2lzdHJhdGlvbkRhdGUg XQ0KPiAgICB8IEVOVU0gRG9tYWluU3RhdHVzICB8PD4tLSgwLi4xKS0tWyBFeHBpcmF0aW9uRGF0 ZSBdDQo+ICAgIHwgICAgICAgICAgICAgICAgICAgIHw8Pi0tKDAuLiopLS1bIE5hbWVzZXJ2ZXJz IF0NCj4gICAgfCAgICAgICAgICAgICAgICAgICAgfDw+LS0oMC4uKiktLVsgRE5TUmVjb3JkIF0N Cj4gICAgfCAgICAgICAgICAgICAgICAgICAgfDw+LS0oMC4uKiktLVsgRG9tYWluQ29udGFjdHMg XQ0KPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiAgICAgICAgICAgICAgICAgRmln dXJlIDQuMyBUaGUgRG9tYWluRGF0YSBlbGVtZW50DQpbLi4uXQ0KPiA0LjkuMi4xLiAgTmFtZQ0K PiANCj4gICAgUkVRVUlSRUQuICBPbmUgdmFsdWUgb2YgaW9kZWY6TUxTdHJpbmdUeXBlIFtSRkM1 MDcwXSwgU2VjdGlvbiAyLjRdLg0KPiAgICBUaGUgTmFtZSBlbGVtZW50IGlzIHRoZSBkb21haW4g bmFtZSB1c2VkIGluIHRoaXMgZXZlbnQuDQoNCkhvdyBpcyB1c2FnZSBkZWZpbmVkIGhlcmU/ICBB bHNvLCBqdWRnaW5nIGZyb20gdGhlIGZvbGxvd2luZywgaWYgdGhlIGF1dGhvcnMgYmVsaWV2ZSB0 aGF0IHRoZSBkb21haW4gbmFtZSBzaG91bGQgYmUgbW9kaWZpZWQgdG8ganVzdCBjb3ZlciB0aGUg InJlZ2lzdHJ5IGxldmVsIiwgdGhleSBzaG91bGQgbWFrZSB0aGF0IGV4cGxpY2l0Og0KSWYgInd3 dy5leGFtcGxlLmNvbSIgd2FzICJ1c2VkIiwgd291bGQgInd3dy5leGFtcGxlLmNvbSIgb3IganVz dCAiZXhhbXBsZS5jb20iIGFwcGVhciBpbiB0aGUgcmVwb3J0Pw0KDQo+IDQuOS4yLjYuICBETlNS ZWNvcmQgZWxlbWVudA0KPiANCj4gICAgWmVybyBvciBtb3JlIHZhbHVlcy4gIFRoaXMgZWxlbWVu dCBhbGxvd3MgdGhlIHJlcG9ydGVyIHRvIGR1cGxpY2F0ZQ0KPiAgICB0aGUgRE5TIHJlY29yZCBk YXRhIGFzIGRlZmluZWQgYnkgW1JGQzEwMzRdLCBhbmQgcmV0dXJuZWQgYnkgdGhlIEROUy4NCj4g ICAgSW5jbHVkaW5nIHRoaXMgaW5mb3JtYXRpb24gYWxsb3dzIGZvciB0cmFja2luZywgdHJlbmRp bmcsIGFuZA0KPiAgICBpZGVudGlmaWNhdGlvbiBvZiB0aGUgdmVyeSB0cmFuc2llbnQgRE5TIG1h cHBpbmcgYW5kIHN0cnVjdHVyZSBvZg0KPiAgICBjcmltZXdhcmUgZG9tYWlucy4NCj4gDQo+ICAg ICstLS0tLS0tLS0tLS0tLS0tKw0KPiAgICB8IEROU1JlY29yZCAgICAgIHwNCj4gICAgKy0tLS0t LS0tLS0tLS0tLS0rDQo+ICAgIHwgICAgICAgICAgICAgICAgfDw+LS0oMS4uMSktLVsgb3duZXIg XQ0KPiAgICB8ICAgICAgICAgICAgICAgIHw8Pi0tKDEuLjEpLS1bIHR5cGUgXQ0KPiAgICB8ICAg ICAgICAgICAgICAgIHw8Pi0tKDAuLjEpLS1bIGNsYXNzIF0NCj4gICAgfCAgICAgICAgICAgICAg ICB8PD4tLSgwLi4xKS0tWyB0dGwgXQ0KPiAgICB8ICAgICAgICAgICAgICAgIHw8Pi0tKDEuLjEp LS1bIHJkYXRhIF0NCj4gICAgKy0tLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiAgICAgICAgICAgICAg RmlndXJlIDQuNCBUaGUgRG9tYWluQ29udGFjdHMgZWxlbWVudA0KDQpJIHdvbmRlciB3aHkgd2Ug ZG8gbm90IGFscmVhZHkgaGF2ZSBhbiBYTUwgc2NoZW1hIGRlc2NyaWJpbmcgRE5TIFJScy4NCg0K PiA0LjkuMi42LjEuICBvd25lciBlbGVtZW50DQo+IA0KPiAgICBSRVFVSVJFRC4gIE9uZSBTdHJp bmcgVmFsdWUuICBUaGlzIGVsZW1lbnQgaWRlbnRpZmllcyB0aGUgc3VwZXJpb3INCj4gICAgbm9k ZSBpbiB0aGUgRE5TIGhpZXJhcmNoeS4NCg0KIlN1cGVyaW9yIG5vZGUiIGlzIGVpdGhlciBhIHdy b25nIGRlc2NyaXB0aW9uIChJcyAiZXhhbXBsZS5jb20iIHN1cGVyaW9yIHRvICJ3d3cuZXhhbXBs ZS5jb20iPykgb3IgYW4gb3V0cmlnaHQgbWlzdW5kZXJzdGFuZGluZyBvZiB3aGF0IGEgIkROUyBv d25lciBuYW1lIiBtZWFucy4NCg0KPiA0LjkuMi42LjMuICBjbGFzcyBlbGVtZW50DQo+IA0KPiAg ICBaZXJvIG9yIG9uZSB2YWx1ZSBvZiBhIFNUUklORy4gIFRoaXMgZmllbGQgY29udGFpbnMgb25l IHZhbHVlIGZyb20NCj4gICAgdGhlIElBTkEgRE5TIERvbWFpbiBTeXN0ZW0gQ2xhc3MgUmVnaXN0 cnkuICBUaGUgdmFsdWUgd2lsbCBiZSB0aGUgdHdvDQo+ICAgIGNoYXJhY3RlciByZXByZXNlbnRh dGlvbiBvZiBjbGFzcywgaW5zdGVhZCBvZiBhIGRlY2ltYWwgbnVtYmVyIHRvDQo+ICAgIGVhc2Ug ZGF0YSBlbnRyeSBmcm9tIHN0YW5kYXJkIEROUyB0b29scy4gIFRoZSBkZWZhdWx0IHZhbHVlIGZv ciB0aGlzDQo+ICAgIGZpZWxkIGlzICJJTiIgdG8gbm90ZSB0aGUgSW50ZXJuZXQuDQoNCk5vdCBi ZWluZyBhbiBYTUwgZXhwZXJ0IHRoaXMgc3RpbGwgc2VlbXMgdG8gYmUgaW4gY29uZmxpY3Qgd2l0 aCB0aGUgc2NoZW1hIGRlZmluZWQgbGF0ZXIsIHdoaWNoIG1ha2VzIHRoaXMgbWFuZGF0b3J5LiAg QWxzbyBJJ20gbm90IHN1cmUgd2h5IGFuZCBob3cgYW55dGhpbmcgZWxzZSBidXQgIklOIiB3b3Vs ZCBjb21lIGludG8gcGxheS4NCg0KPiA0LjkuMi43LjEuICBTYW1lRG9tYWluQ29udGFjdA0KPiAN Cj4gICAgUkVRVUlSRUQuICBPbmUgaW9kZWY6RE5TTkFNRS4gIFRoZSBTYW1lRG9tYWluQ29udGFj dCBlbGVtZW50IGlzDQo+ICAgIHBvcHVsYXRlZCB3aXRoIGEgZG9tYWluIG5hbWUgaWYgdGhlIGNv bnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoaXMNCj4gICAgZG9tYWluIGlzIGlkZW50aWNhbCB0byB0 aGF0IG5hbWUgaW4gdGhpcyBvciBhbm90aGVyIHJlcG9ydC4NCj4gICAgSW1wbGVtZW50b3JzIGFy ZSBjYXV0aW9uZWQgdG8gb25seSB1c2UgdGhpcyBlbGVtZW50IHdoZW4gdGhlIGRvbWFpbg0KPiAg ICBjb250YWN0IGRhdGEgcmV0dXJuZWQgYnkgdGhlIHJlZ2lzdHJhciBpcyBpZGVudGljYWwuDQoN ClRoaXMgdGFjaXRseSBhc3N1bWVzIGEgInRoaW4gcmVnaXN0cnkiIG1vZGVsOyBzL3JlZ2lzdHJh ci9yZWdpc3RyYXIgb3IgcmVnaXN0cnkvOw0KDQo+IDQuOS4yLjcuMi4xLiAgUm9sZSBhdHRyaWJ1 dGUNCj4gDQo+ICAgIFJFUVVJUkVELiAgRU5VTS4gIFRoZSByb2xlIGF0dHJpYnV0ZSBpcyBleHRl bmRlZCBmcm9tIHRoZSBpb2RlZjpyb2xlLQ0KPiAgICBleHQgYXR0cmlidXRlIHdpdGggdmFsdWVz IGlkZW50aWZpZWQgaW4gW0NSSVNQXS4gIFRoZSByb2xlLWV4dCANCj4gdmFsdWUNCg0KVGhlIHJl ZmVyZW5jZSBpcyBicm9rZW4uIEFsc28sIHRoZSBwcm90b2NvbCdzIG5hbWUgaXMgSVJJUywgbm90 IENSSVNQLg0KDQo+ICAgIG9mIHRoZSByb2xlIGF0dHJpYnV0ZSBzaG91bGQgYmUgdXNlZCwgd2l0 aCB0aGUgcm9sZS1leHQgYXR0cmlidXRlDQo+ICAgIHZhbHVlIGNob3NlbiBmcm9tIG9uZSBvZiB0 aGUgZm9sbG93aW5nIHZhbHVlczoNCj4gDQo+ICAgIDEuICAgcmVnaXN0cmFudC4gIFRoaXMgaWRl bnRpZmllZCBDb250YWN0IGlzIHRoZSBkb21haW4gcmVnaXN0cmFudC4NCj4gDQo+ICAgIDIuICAg cmVnaXN0cmFyLiAgVGhpcyBjb250YWN0IGlkZW50aWZpZXMgdGhlIHJlZ2lzdHJhciBvZiB0aGlz DQo+ICAgICAgICAgZG9tYWluLg0KPiANCj4gICAgMy4gICBiaWxsaW5nLiAgVGhpcyBlbnRyeSBp cyB0aGUgYmlsbGluZyBvciBmaW5hbmNpYWwgY29udGFjdC4NCj4gDQo+ICAgIDQuICAgdGVjaG5p Y2FsLiAgVGhpcyBjb250YWN0IGRlYWxzIHdpdGggdGVjaG5pY2FsIGlzc3Vlcy4NCj4gDQo+ICAg IDUuICAgYWRtaW5pc3RyYXRpdmUuICBUaGlzIGNvbnRhY3QgaGFuZGxlcyBhZG1pbmlzdHJhdGl2 ZSBtYXR0ZXJzIGZvcg0KPiAgICAgICAgIHRoaXMgZG9tYWluLg0KPiANCj4gICAgNi4gICBsZWdh bC4gIFRoaXMgZW50cnkgZGVhbHMgd2l0aCBsZWdhbCBpc3N1ZXMgZm9yIHRoaXMgZG9tYWluLg0K PiANCj4gICAgNy4gICB6b25lLiAgVGhpcyBlbnRyeSBjb250cm9scyB0aGUgRE5TIHpvbmUgaW5m b3JtYXRpb24uDQo+IA0KPiAgICA4LiAgIGFidXNlLiAgVGhpcyBlbnRyeSBhY2NlcHRzIGFidXNl IGlzc3Vlcy4NCj4gDQo+ICAgIDkuICAgc2VjdXJpdHkuICBUaGlzIGVudHJ5IGFjY2VwdHMgc2Vj dXJpdHkgaXNzdWVzLg0KDQpXaHkgaGF2ZSB0aGUgYXR0cmlidXRlIHZhbHVlcyBiZWVuIGNob3Nl biB0byBkaWZmZXIgZnJvbSB0aG9zZSBkZWZpbmVkIGluIElSSVMtRFJFRz8NCg0KPiAgICAxMC4g IGRvbWFpbk93bmVyLiAgVGhpcyBsaXN0cyB0aGUgb3duZXIgb2YgdGhlIGRvbWFpbi4NCg0KVGhp cyBkb2Vzbid0IGFwcGVhciBpbiBSRkMgMzk4Mi4gIEhvdyBpcyB0aGUgIm93bmVyIiBkaWZmZXJl bnQgZnJvbSB0aGUgInJlZ2lzdHJhbnQiPw0KDQo+ICAgIDExLiAgaXBBZGRyZXNzT3duZXIuICBU aGlzIGVudHJ5IGlkZW50aWZpZXMgdGhlIGFzc2lnbmVlIG9mIHRoZSBJUA0KPiAgICAgICAgIGFk ZHJlc3Mgc3BhY2UuDQoNCldoaWNoIElQIGFkZHJlc3Mgc3BhY2U/DQoNCj4gICAgMTIuICBob3N0 aW5nUHJvdmlkZXIuICBUaGlzIGNvbnRhY3QgaXMgdGhlIGhvc3RpbmcgcHJvdmlkZXIgb2YgdGhp cw0KPiAgICAgICAgIGRvbWFpbi4NCg0KQXQgYmVzdCwgdGhpcyBzaG91bGQgYmUgX2FfIHByb3Zp ZGVyLCBub3QgX3RoZV8uDQoNCj4gNC45LjMuICBTeXN0ZW1TdGF0dXMgYXR0cmlidXRlDQo+IA0K PiAgICBSRVFVSVJFRC4gIEVOVU0uICBUaGUgU3lzdGVtU3RhdHVzIGF0dHJpYnV0ZSBhc3Nlc3Nl cyBhIGRvbWFpbidzDQo+ICAgIGludm9sdmVtZW50IGluIHRoaXMgZXZlbnQuDQoNCkRvbWFpbnMg YXJlIGVsZW1lbnRzIGluIGEgbmFtZSBzcGFjZSwgbm90IGFjdGluZyBwYXJ0aWVzLiAgSG93IGNh biBhIGRvbWFpbiBiZSAiaW52b2x2ZWQiIGluIGFueXRoaW5nPyAgVGhlIElFVEYgc2hvdWxkIHJl c2lzdCB0aGUgdGVtcHRhdGlvbiB0byBzdGFuZGFyZGl6ZSBjb2xsb3F1aWFsIGFidXNlIG9mIHRo ZSBtZWFuaW5nIG9mICJkb21haW4iLg0KDQo+ICAgIDEuICBzcG9vZmVkLiAgVGhpcyBkb21haW4g b3Igc3lzdGVtIGRpZCBub3QgcGFydGljaXBhdGUgaW4gdGhpcw0KPiAgICAgICAgZXZlbnQsIGJ1 dCBpdHMgYWRkcmVzcyBzcGFjZSBvciBETlMgbmFtZSB3YXMgZm9yZ2VkLg0KDQpJdCdzIGp1c3Qg aWRlbnRpZmllcnMsIGJ1dCAic3Bvb2ZlZCIgYW5kICJmb3JnZWQiIGFwcGVhciB0byBtZSBhcyBk aWZmZXJlbnQgc2NlbmFyaW9zLg0KDQo+IDQuOS40LiAgRG9tYWluU3RhdHVzIGF0dHJpYnV0ZQ0K PiANCj4gICAgRU5VTS4gIFRoZSBEb21haW5TdGF0dXMgYXR0cmlidXRlIGRlc2NyaWJlcyB0aGUg cmVnaXN0cnkgc3RhdHVzIG9mIGENCj4gICAgZG9tYWluIGF0IHRoZSB0aW1lIG9mIHRoZSByZXBv cnQuICBUaGUgYmVsb3cgZW51bWVyYXRlZCBsaXN0IGlzIHRha2VuDQo+ICAgIHZlcmJvc2UgZnJv bSB0aGUgJ2RvbWFpblN0YXR1c1R5cGUnIG9mIHRoZSBFeHRlbnNpYmxlIFByb3Zpc2lvbmluZw0K PiAgICBQcm90b2NvbFtSRkM0OTMzXSBhbmQgIkRvbWFpbiBSZWdpc3RyeSBWZXJzaW9uIDIgZm9y IHRoZSBJbnRlcm5ldA0KPiAgICBSZWdpc3RyeSBJbmZvcm1hdGlvbiBTZXJ2aWNlIiBpbnRlcm5l dC1kcmFmdCBbQ1JJU1BdLg0KDQpOSVQ6IG5vIGxvbmdlciBhbiAiaW50ZXJuZXQtZHJhZnQiLg0K DQo+IDQuOS43LjEuMS4gIE5hbWUgZWxlbWVudA0KPiANCj4gICAgT25lIFNUUklORywgcmVwcmVz ZW50aW5nIHRoZSBXSU5ET1dTIE9wZXJhdGluZyBTeXN0ZW0gUmVnaXN0cnkgS2V5DQo+ICAgIE5h bWUuDQoNCk91Y2g7ICBzaG91bGRuJ3QgdGhlIGRvY3VtZW50IHRoZW4gYXQgbGVhc3QgaGF2ZSBh IHJlZmVyZW5jZSB0byBzdWNoIEtleSBOYW1lcycgc3ludGF4Pw0KQmV0dGVyIHlldCwgbm8gT1Mg d291bGQgYmUgcHJlZmVycmVkIG92ZXIgb3RoZXJzIGFuZCB0aGlzIGJlIHJlZGVmaW5lZCBhcyAi dmVuZG9yIHNwZWNpZmljIGtleSIgb3Igc2ltaWxhci4NCg0KPiA0LjE3LiAgRW1haWxSZWNvcmQg ZWxlbWVudA0KPiANCj4gICAgRXh0ZW5zaW9ucyBhcmUgYWxzbyBtYWRlIHRvIHRoZSBpb2RlZjpJ bmNpZGVudC5FdmVudERhdGEgZWxlbWVudCB0bw0KPiAgICBpbmNsdWRlIHRoZSBhY3R1YWwgZW1h aWwgbWVzc2FnZSByZWNlaXZlZCBpbiBwaGlzaGluZyBsdXJlIG9yDQo+ICAgIHdpZGVzcHJlYWQg c3BhbSBlbWFpbHMuICBUaGUgYWJpbGl0eSB0byByZXBvcnQgc3BhbSBpcyBpbmNsdWRlZA0KPiAg ICB3aXRoaW4gYSBQaHJhdWRSZXBvcnQgdG8gc3VwcG9ydCBleGNoYW5naW5nIGluZm9ybWF0aW9u IGFib3V0IGxhcmdlLQ0KPiAgICBzY2FsZSBzcGFtIGFjdGl2aXRpZXMgcmVsYXRlZCB0byBwaGlz aGluZywgbm90IG5lY2Vzc2FyaWx5IGEgc2luZ2xlDQo+ICAgIHNwYW0gbWVzc2FnZSB0byBhIHVz ZXIuICBBcyBzdWNoIHRoZSBzcGFtIHJlcG9ydGluZyBtZWNoYW5pc20gd2FzIG5vdA0KPiAgICBk ZXNpZ25lZCB0byBtaW5pbWl6ZSBvdmVyaGVhZCBhbmQgcHJvY2Vzc2luZywgYnV0IHRvIHN1cHBv cnQgb3RoZXINCj4gICAgd2lkZWx5LXVzZWQgc3BhbSByZXBvcnRpbmcgZm9ybWF0cyBzdWNoIGFz IHRoZSBNQUFXRydzIEFidXNlDQo+ICAgIFJlcG9ydGluZyBGb3JtYXQgW0FSRl0uDQo+IA0KPiAg ICBSZXBvcnRpbmcgb2YgdGhlIGFjdHVhbCBtYWlsIG1lc3NhZ2UgaXMgc3VwcG9ydGVkIGJ5IGNo b29zaW5nIG9uZSBvZg0KPiAgICB0aHJlZSBtZXRob2RzLiAgRmlyc3QsIGFuIEFSRiBtZXNzYWdl IG1heSBiZSBpbmNsdWRlZC4gIFNlY29uZCwgdGhlDQo+ICAgIG1lc3NhZ2UgbWF5IGJlIGluY2x1 ZGVkIGFzIG9uZSBsYXJnZSBzdHJpbmcuICBUaGlyZCwgdGhlIGhlYWRlciBhbmQNCj4gICAgYm9k eSBjb21wb25lbnRzIG1heSBiZSBkaXNzZWN0ZWQgYW5kIGluY2x1ZGVkIGFzIGEgc2VyaWVzIG9m IHN0cmluZ3MuDQoNClsuLi5dDQoNCj4gNC4xNy4yLjIuICBBUkZUZXh0DQo+IA0KPiAgICBaZXJv IG9yIG9uZSB2YWx1ZSBvZiBTVFJJTkcuICBUaGUgTWVzc2FnaW5nIEFudGktQWJ1c2UgV29ya2lu ZyBHcm91cA0KPiAgICAoTUFBV0cpIGRlZmluZWQgYSBmb3JtYXQgZm9yIHNlbmRpbmcgYWJ1c2Ug YW5kIGxpc3QgY29udHJvbCB0cmFmZmljDQo+ICAgIHRvIG90aGVyIHBhcnRpZXMuICBTaW5jZSBt YW55IG9mIHRoZXNlIHJlcG9ydHMgd2lsbCBnZXQgaW50ZWdyYXRlZA0KPiAgICBpbnRvIGluY2lk ZW50IHByb2Nlc3NlcywgdGhlIHJhdyBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IFtBUkZdIG1heSBi ZQ0KPiAgICBpbnNlcnRlZCBpbnRvIHRoaXMgZWxlbWVudC4NCg0KVGhpcyBzZWVtcyB0byBzdWdn ZXN0IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUgIkFidXNlIFJlcG9ydGluZyBGb3JtYXQi LCBidXQgdGhlIFtBUkZdIHJlZmVyZW5jZSBpcyBpbmZvcm1hdGl2ZSBvbmx5IGFuZCwgbW9yZSBp bXBvcnRhbnRseSwgaXMgTUFBV0cgZWxpZ2libGUgZm9yIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGF0 IGFsbD8NCg0KPiBBcHBlbmRpeCBCLiAgRXhhbXBsZSBWaXJ1cyBSZXBvcnQNCg0KVGhlIGV4YW1w bGVzIGluIHRoaXMgYXBwZW5kaXggY29udGFpbnMgbG90cyBvZiBub24tUkZDMjYwNiBkb21haW4g bmFtZXMgYW5kIG5vbi1yZXNlcnZlZCBJUCBhZGRyZXNzZXMuDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG5zLWRpciBtYWlsaW5nIGxpc3QNCmRucy1k aXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zLWRp cg0K ------_=_NextPart_001_01C90688.6AFCE40A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir ------_=_NextPart_001_01C90688.6AFCE40A-- From dns-dir-bounces@ietf.org Mon Aug 25 07:09:42 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50EF28C1F6; Mon, 25 Aug 2008 07:09:42 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBE73A706B for ; Mon, 25 Aug 2008 07:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VclrlMBkWUpm for ; Mon, 25 Aug 2008 07:09:40 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 818283A7025 for ; Mon, 25 Aug 2008 07:09:39 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KXckd-0002Zf-Kp; Mon, 25 Aug 2008 16:08:59 +0200 Received: from localhost by x27.adm.denic.de with local id 1KXcjE-0005Bo-94; Mon, 25 Aug 2008 16:07:32 +0200 Date: Mon, 25 Aug 2008 16:07:32 +0200 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20080825140732.GD3425@x27.adm.denic.de> References: <20080825074459.GB28428@x27.adm.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hello Dan, > I am working to sort out the DISCUSS (show stoppers) from COMMENT > (nice-to-have, nits) issues. It would be useful if you can indicate what > you believe are the show stoppers in your review (attached) to make sure > I do not miss anything critical. further below I have marked what I consider substantial. Some terminology issues might also be important but could probably be fixed with just another editing round. I'd not say the individual questions raised are "show stoppers", but in total, several clarifications could improve the document. > > Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, > > and Other Crimeware > > draft-cain-post-inch-phishingextns-05 > > > > 3.3. Correctness of Fraud Activity Reports > > > > The Fraud Activity Report MUST pass XML validation using the schema > > defined in [RFC5070] and the extensions defined in > > > > of this document. > > This headline should be renamed "Syntactical Correctness ..." because it could otherwise be perdevied to deal with the validation of the report content. > > > 4.5. FraudType attribute > > > 5. dnsspoof. This choice does not have a related FraudParameter. > > This is used for a spoofed DNS (e.g., malware changes localhost > > file so visits to www.example.com go to another IP address > > chosen by the fraudster). > > DNS spoofing is usually to involve forged DNS responses, not manipulating the resolution path. It could be argued that in the case described here, DNS doesn't even get used. > > > 4.9.2. DomainData element > > > > Zero or more element values. The DomainData element describes the > > registration, delegation, and control of a domain used to source the > > lure. Capturing the domain data is very useful when investigating or > > correlating events. > > It is unclear to me what "domain used to source the lure" means. Is it the header or envelope From address of an email? > > > The structure of a DomainData element is as follows: > > > > +--------------------+ > > | DomainData | > > +--------------------+ > > | |<>----------[ Name ] > > | |<>--(0..1)--[ DateDomainWasChecked ] > > | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] > > | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] > > | |<>--(0..*)--[ Nameservers ] > > | |<>--(0..*)--[ DNSRecord ] > > | |<>--(0..*)--[ DomainContacts ] > > +--------------------+ > > > > Figure 4.3 The DomainData element > [...] > > 4.9.2.1. Name > > > > REQUIRED. One value of iodef:MLStringType [RFC5070], Section 2.4]. > > The Name element is the domain name used in this event. > > How is usage defined here? Also, judging from the following, if the authors believe that the domain name should be modified to just cover the "registry level", they should make that explicit: > If "www.example.com" was "used", would "www.example.com" or just "example.com" appear in the report? Substantive clarification needed. > > 4.9.2.6. DNSRecord element > > > > Zero or more values. This element allows the reporter to duplicate > > the DNS record data as defined by [RFC1034], and returned by the DNS. > > Including this information allows for tracking, trending, and > > identification of the very transient DNS mapping and structure of > > crimeware domains. > > > > +----------------+ > > | DNSRecord | > > +----------------+ > > | |<>--(1..1)--[ owner ] > > | |<>--(1..1)--[ type ] > > | |<>--(0..1)--[ class ] > > | |<>--(0..1)--[ ttl ] > > | |<>--(1..1)--[ rdata ] > > +----------------+ > > > > Figure 4.4 The DomainContacts element > > I wonder why we do not already have an XML schema describing DNS RRs. > > > 4.9.2.6.1. owner element > > > > REQUIRED. One String Value. This element identifies the superior > > node in the DNS hierarchy. > > "Superior node" is either a wrong description (Is "example.com" superior to "www.example.com"?) or an outright misunderstanding of what a "DNS owner name" means. > > > 4.9.2.6.3. class element > > > > Zero or one value of a STRING. This field contains one value from > > the IANA DNS Domain System Class Registry. The value will be the two > > character representation of class, instead of a decimal number to > > ease data entry from standard DNS tools. The default value for this > > field is "IN" to note the Internet. > > Not being an XML expert this still seems to be in conflict with the schema defined later, which makes this mandatory. Also I'm not sure why and how anything else but "IN" would come into play. > > > 4.9.2.7.1. SameDomainContact > > > > REQUIRED. One iodef:DNSNAME. The SameDomainContact element is > > populated with a domain name if the contact information for this > > domain is identical to that name in this or another report. > > Implementors are cautioned to only use this element when the domain > > contact data returned by the registrar is identical. > > This tacitly assumes a "thin registry" model; s/registrar/registrar or registry/; > > > 4.9.2.7.2.1. Role attribute > > > > REQUIRED. ENUM. The role attribute is extended from the iodef:role- > > ext attribute with values identified in [CRISP]. The role-ext > > value > > The reference is broken. Also, the protocol's name is IRIS, not CRISP. > > > of the role attribute should be used, with the role-ext attribute > > value chosen from one of the following values: > > > > 1. registrant. This identified Contact is the domain registrant. > > > > 2. registrar. This contact identifies the registrar of this > > domain. > > > > 3. billing. This entry is the billing or financial contact. > > > > 4. technical. This contact deals with technical issues. > > > > 5. administrative. This contact handles administrative matters for > > this domain. > > > > 6. legal. This entry deals with legal issues for this domain. > > > > 7. zone. This entry controls the DNS zone information. > > > > 8. abuse. This entry accepts abuse issues. > > > > 9. security. This entry accepts security issues. > > Why have the attribute values been chosen to differ from those defined in IRIS-DREG? > > > 10. domainOwner. This lists the owner of the domain. > > This doesn't appear in RFC 3982. How is the "owner" different from the "registrant"? Even though the scheme seems to already be used, the duplication is confusing from a DNS perspective and should be either explained or eliminated. (substantive) > > > 11. ipAddressOwner. This entry identifies the assignee of the IP > > address space. > > Which IP address space? > > > 12. hostingProvider. This contact is the hosting provider of this > > domain. > > At best, this should be _a_ provider, not _the_. > > > 4.9.3. SystemStatus attribute > > > > REQUIRED. ENUM. The SystemStatus attribute assesses a domain's > > involvement in this event. > > Domains are elements in a name space, not acting parties. How can a domain be "involved" in anything? The IETF should resist the temptation to standardize colloquial abuse of the meaning of "domain". > > > 1. spoofed. This domain or system did not participate in this > > event, but its address space or DNS name was forged. > > It's just identifiers, but "spoofed" and "forged" appear to me as different scenarios. > > > 4.9.4. DomainStatus attribute > > > > ENUM. The DomainStatus attribute describes the registry status of a > > domain at the time of the report. The below enumerated list is taken > > verbose from the 'domainStatusType' of the Extensible Provisioning > > Protocol[RFC4933] and "Domain Registry Version 2 for the Internet > > Registry Information Service" internet-draft [CRISP]. > > NIT: no longer an "internet-draft". > > > 4.9.7.1.1. Name element > > > > One STRING, representing the WINDOWS Operating System Registry Key > > Name. > > Ouch; shouldn't the document then at least have a reference to such Key Names' syntax? > Better yet, no OS would be preferred over others and this be redefined as "vendor specific key" or similar. Substantive IMHO. > > 4.17. EmailRecord element > > > > Extensions are also made to the iodef:Incident.EventData element to > > include the actual email message received in phishing lure or > > widespread spam emails. The ability to report spam is included > > within a PhraudReport to support exchanging information about large- > > scale spam activities related to phishing, not necessarily a single > > spam message to a user. As such the spam reporting mechanism was not > > designed to minimize overhead and processing, but to support other > > widely-used spam reporting formats such as the MAAWG's Abuse > > Reporting Format [ARF]. > > > > Reporting of the actual mail message is supported by choosing one of > > three methods. First, an ARF message may be included. Second, the > > message may be included as one large string. Third, the header and > > body components may be dissected and included as a series of strings. > > [...] > > > 4.17.2.2. ARFText > > > > Zero or one value of STRING. The Messaging Anti-Abuse Working Group > > (MAAWG) defined a format for sending abuse and list control traffic > > to other parties. Since many of these reports will get integrated > > into incident processes, the raw Abuse Reporting Format [ARF] may be > > inserted into this element. > > This seems to suggest a normative reference to the "Abuse Reporting Format", but the [ARF] reference is informative only and, more importantly, is MAAWG eligible for normative references at all? Substantive. > > > Appendix B. Example Virus Report > > The examples in this appendix contains lots of non-RFC2606 domain names and non-reserved IP addresses. Regards, Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 26 07:04:43 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B933A6C75; Tue, 26 Aug 2008 07:04:43 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595463A6C67 for ; Tue, 26 Aug 2008 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGlol+3NdSMj for ; Tue, 26 Aug 2008 07:04:36 -0700 (PDT) Received: from cliffie.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id C1A0D3A6B74 for ; Tue, 26 Aug 2008 07:04:36 -0700 (PDT) Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id AD59713668D; Tue, 26 Aug 2008 10:04:02 -0400 (EDT) Received: from dul1mcmlarson-l1.verisignlabs.com (dul1mcmlarson-l1.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id A6360242163; Tue, 26 Aug 2008 10:04:02 -0400 (EDT) Date: Tue, 26 Aug 2008 10:03:43 -0400 From: Matt Larson To: Peter Koch Message-ID: <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> <20080821155656.GC6169@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080821155656.GC6169@unknown.office.denic.de> User-Agent: Mutt/1.5.11 Cc: IETF DNS Directorate Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Peter, On Thu, 21 Aug 2008, Peter Koch wrote: > I've set up another doodle poll at > to choose between September, 1st and 8th. It says 2 pm - 3 pm, that is > UTC (and 1600-1700 Paris local). Next time I'll try the new timezone support. > > Just for completeness, here are the next "regular" call dates: > > Monday, 6 October 2008 > Monday, 3 November 2008 > Monday,17 November 2008 [Lunch meeting @IETF73] > Monday, 1 December 2008 > Monday, 5 January 2009 Is the time always 1400-1500 UTC and therefore subject to changing by an hour when daylight savings time/summer time ends? Or is it always relative to Paris local/CET? Matt _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Aug 26 08:50:50 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D33028C1A4; Tue, 26 Aug 2008 08:50:50 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEA028C1CB for ; Tue, 26 Aug 2008 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_50=0.001, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+deGxX2hQdk for ; Tue, 26 Aug 2008 08:50:47 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 95B5128C1C7 for ; Tue, 26 Aug 2008 08:50:47 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KY0oh-0000Iu-Va; Tue, 26 Aug 2008 17:50:48 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id DA67D7F1131; Tue, 26 Aug 2008 17:50:47 +0200 (CEST) Date: Tue, 26 Aug 2008 17:50:47 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20080826155047.GA13135@unknown.office.denic.de> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> <20080821155656.GC6169@unknown.office.denic.de> <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi Matt, > Is the time always 1400-1500 UTC and therefore subject to changing by > an hour when daylight savings time/summer time ends? Or is it always > relative to Paris local/CET? the conclusion in Dublin, as I read it, was to always refer to Paris local time, so the UTC start time will change and depending on the differrent north american and european daylight saving time schedules the offset might change, as well. I'll double check before sending out the invitations. For the poll "1st vs 8th" there's a preference fot the 8th, but we haven't heard from the ADs yet. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 05:43:32 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003733A680C; Wed, 27 Aug 2008 05:43:31 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB40C3A67A3 for ; Wed, 27 Aug 2008 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuqYMPN4IYcM for ; Wed, 27 Aug 2008 05:43:29 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 778823A680C for ; Wed, 27 Aug 2008 05:43:29 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7RChEjq020555 for ; Wed, 27 Aug 2008 08:43:14 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7RChDSU214138 for ; Wed, 27 Aug 2008 08:43:13 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7RChDI2029558 for ; Wed, 27 Aug 2008 08:43:13 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-49-173-1.mts.ibm.com [9.49.173.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7RCh7vG029165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Aug 2008 08:43:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m7RCh4GA013966 for ; Wed, 27 Aug 2008 08:43:06 -0400 Message-Id: <200808271243.m7RCh4GA013966@cichlid.raleigh.ibm.com> To: IETF DNS Directorate In-reply-to: <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> <20080821155656.GC6169@unknown.office.denic.de> <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> Comments: In-reply-to Matt Larson message dated "Tue, 26 Aug 2008 10:03:43 -0400." Date: Wed, 27 Aug 2008 08:43:04 -0400 From: Thomas Narten Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > Is the time always 1400-1500 UTC and therefore subject to changing by > an hour when daylight savings time/summer time ends? Or is it always > relative to Paris local/CET? Can we please stick with something stable and predictable and easy to put into a recurring calendar entry? Like UTC? Please don't make me have to think about when DST changes in various parts of the world. Thomas _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 14:46:44 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC473A6843; Wed, 27 Aug 2008 14:46:44 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961F13A635F for ; Wed, 27 Aug 2008 14:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.584 X-Spam-Level: X-Spam-Status: No, score=0.584 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HkLOBsCTkWN for ; Wed, 27 Aug 2008 14:46:40 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 93D6C3A69B2 for ; Wed, 27 Aug 2008 14:46:39 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLkWnT072243 for ; Wed, 27 Aug 2008 17:46:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272146.m7RLkWnT072243@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:45:00 -0400 To: "dns directorate" From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-andrews-dnsext-expire-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is the first of a batch of Early warnings, hopefully I will be able to start sending these directly from now on. Olafur >Count: 28 >Network Working Group M. Andrews >Internet-Draft ISC >Intended status: Standards Track August 25, 2008 >Expires: February 26, 2009 > EDNS EXPIRE OPTION > draft-andrews-dnsext-expire-00 > > Abstract > Provide a method for slave DNS servers to honour the SOA EXPIRE field > as if they were always transferring from the master, even when using > other slaves to perform indirect transfers and refresh queries. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 14:48:51 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3F83A69B2; Wed, 27 Aug 2008 14:48:51 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2713A6A75 for ; Wed, 27 Aug 2008 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=1.720, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dXrz+e4oOFH for ; Wed, 27 Aug 2008 14:48:50 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1A9A93A6AB0 for ; Wed, 27 Aug 2008 14:48:49 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLmZMk072276 for ; Wed, 27 Aug 2008 17:48:35 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272148.m7RLmZMk072276@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:46:54 -0400 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-kerr-dnsop-edns0-penetration-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > >Count: 42 >Network Working Group S. Kerr >Internet-Draft J. Abley >Intended status: Informational Afilias Canada >Expires: January 29, 2009 July 28, 2008 > EDNS0 Support in Authority Servers on 27 July 2008 > draft-kerr-dnsop-edns0-penetration-00 > > Abstract > This memo documents the methodology and results of an experiment > which tested the availability of the DNS Extension Mechanism (EDNS0) > on a large set of authority-only nameservers. The experiment was > conducted in the bar during the IETF 72 meeting on 27 July 2008. > > The results of this experiment suggest that EDNS0 deployment is > extensive: it was found that 94.4% of non-defective authority-only > servers are EDNS0-capable. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 14:50:55 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3EC3A69E9; Wed, 27 Aug 2008 14:50:55 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A892E3A69B2 for ; Wed, 27 Aug 2008 14:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZA72rUbxszv for ; Wed, 27 Aug 2008 14:50:52 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7507D3A6407 for ; Wed, 27 Aug 2008 14:50:52 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLodPb072308 for ; Wed, 27 Aug 2008 17:50:39 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272150.m7RLodPb072308@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:48:53 -0400 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-wijngaards-dnsext-resolver-side-mitigation-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > > >Count: 19 >DNS Extensions Working Group W. Wijngaards >Internet-Draft NLnet Labs >Intended status: Informational August 25, 2008 >Expires: February 26, 2009 > Resolver side mitigations > draft-wijngaards-dnsext-resolver-side-mitigation-00 > > Abstract > Describes a set of mitigations that stop the known Kaminsky > variations, for which only resolver side deployment is necessary. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:02 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA82A28C248; Wed, 27 Aug 2008 15:08:02 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EC028C240 for ; Wed, 27 Aug 2008 15:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUGY4WNJhmNX for ; Wed, 27 Aug 2008 15:08:01 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 023B528C1FC for ; Wed, 27 Aug 2008 15:08:00 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLmZMq072276 for ; Wed, 27 Aug 2008 17:48:36 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272148.m7RLmZMq072276@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:48:07 -0400 To: dns-dir@ietf.org From: ogud@ogud.com (by way of Olafur Gudmundsson ) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Early warning: draft-sakane-dhc-dhcpv6-kdc-option-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Count: 18 INTERNET-DRAFT S. Sakane Intended Status: Informational Y. Akisada Expires: February 21, 2009 K. Kamada Yokogawa Electric Corp. August 20, 2008 Key Distribution Center Address Option for DHCPv6 draft-sakane-dhc-dhcpv6-kdc-option-01.txt Abstract This document defines a new DHCPv6 option to convey a realm of Kerberos and IPv6 addresses of a KDC of that realm. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:03 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA6728C25E; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83EA28C252 for ; Wed, 27 Aug 2008 15:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CtTREHMiMAi for ; Wed, 27 Aug 2008 15:08:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0FBE028C1FC for ; Wed, 27 Aug 2008 15:08:01 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLkWnX072243 for ; Wed, 27 Aug 2008 17:46:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272146.m7RLkWnX072243@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:45:54 -0400 To: "dns directorate" From: ogud@ogud.com (by way of Olafur Gudmundsson ) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Early warning: draft-hubert-ulevitch-edns-ping-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Count: 39 DNS Extensions (DNSEXT) A. Hubert Internet-Draft Netherlabs Computer Consulting BV. Intended status: Standards Track D. Ulevitch Expires: February 18, 2009 EveryDNS August 17, 2008 EDNS Option for performing a data PING draft-hubert-ulevitch-edns-ping-00.txt Abstract For various reasons, it may be desireable to ask a remote nameserver to add certain data to the response to a query. This document describes an EDNS option that implements such behaviour. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:03 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C651B28C270; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7324028C25D for ; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ2X-kN7iUi4 for ; Wed, 27 Aug 2008 15:08:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9573328C241 for ; Wed, 27 Aug 2008 15:08:02 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLkWnV072243 for ; Wed, 27 Aug 2008 17:46:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272146.m7RLkWnV072243@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:45:26 -0400 To: "dns directorate" From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-endo-v6ops-dnsproxy-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > > >Count: 206 >Network Working Group M. Endo >Internet-Draft H. Miyata >Intended status: Informational Yokogawa Electric Corp. >Expires: February 8, 2009 August 7, 2008 > Translator Friendly DNS Proxy > draft-endo-v6ops-dnsproxy-00.txt > > Abstract > This document describes the DNS Proxy that is separated from NAT-PT > [RFC2766]. NAT-PT was designed to work with DNS Application Level > Gateway. However [RFC4966] pointed out DNS related issues, and > [RFC2766] was changed to historical state. This document attempts to > DNS Proxy specification, removing dependency on NAT-PT as well as > resolving problems pointed in [RFC4966]. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:04 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D001D28C252; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426BF28C213 for ; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg+FjZeb9AHR for ; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2023828C1FC for ; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLkWnZ072243 for ; Wed, 27 Aug 2008 17:46:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272146.m7RLkWnZ072243@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:46:27 -0400 To: "dns directorate" From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-ietf-dnsop-name-server-management-reqs-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > >Count: 49 >DNSOP W. Hardaker >Internet-Draft Sparta, Inc. >Intended status: Informational August 25, 2008 >Expires: February 26, 2009 > Requirements for Management of Name Servers for the DNS > draft-ietf-dnsop-name-server-management-reqs-00.txt > > Abstract > Management of name servers for the Domain Name Service (DNS) has > traditionally been done using vendor-specific monitoring, > configuration and control methods. Although some service monitoring > platforms can test the functionality of the DNS itself there is not a > interoperable way to manage (monitor, control and configure) the > internal aspects of a name server itself. > > This document discusses the requirements of a management system for > DNS name servers. A management solution that is designed to manage > the DNS can use this document as a shopping list of needed features. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:04 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D997B28C27D; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D23428C213 for ; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OoULl8mX6DC for ; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A13A728C241 for ; Wed, 27 Aug 2008 15:08:03 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLmZMs072276 for ; Wed, 27 Aug 2008 17:48:36 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272148.m7RLmZMs072276@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:48:29 -0400 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-tewari-nfsv4-federated-fs-protocol-03.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > > >Count: 11 >Network Working Group D. Ellard >Internet-Draft C. Everhart >Intended status: Standards Track NetApp, Inc. >Expires: February 6, 2009 R. Tewari > M. Naik > IBM Almaden > August 5, 2008 > NSDB Protocol for Federated Filesystems > draft-tewari-nfsv4-federated-fs-protocol-03.txt > > Abstract > This document describes a file system federation protocol that > enables file access and namespace traversal across collections of > independently administered fileservers. The protocol specifies a set > of interfaces by which fileservers and collections of fileservers > with different administrators can form a fileserver federation that > provides a namespace composed of the filesystems physically hosted on > and exported by the constituent fileservers. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:05 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E515328C241; Wed, 27 Aug 2008 15:08:05 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F52328C1FC for ; Wed, 27 Aug 2008 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYx6WZIFbilr for ; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2C5AA28C276 for ; Wed, 27 Aug 2008 15:08:04 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLmZMm072276 for ; Wed, 27 Aug 2008 17:48:35 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272148.m7RLmZMm072276@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:47:18 -0400 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-otis-dkim-adsp-sec-issues-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > >Count: 21 >DKIM Working Group D. Otis >Internet-Draft Trend Micro, NSSG >Intended status: Standards Track August 18, 2008 >Expires: February 19, 2009 > DKIM Author Domain Signing Practices (ADSP) Security Issues > draft-otis-dkim-adsp-sec-issues-01 > > Abstract > The proposed [I-D.ietf-dkim-ssp] defines DNS records that advertise > the extent to which a domain employs [RFC4871] to sign [RFC2822] > messages, and defines how other hosts can access these > advertisements. Its laudable goal is to allow domains control over > the use of the From header field. When a message is not adequately > signed, advertised assertions, referenced by a domain in the From > header field, assist in resolving the message's intended disposition. > > However, [I-D.ietf-dkim-ssp] fails to discern that restricted > identities imposed upon remote signing agents, require additional > control be afforded the domain, irrespective of the domain's > advertised practices. [I-D.ietf-dkim-ssp] employs a flawed two-stage _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Aug 27 15:08:07 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F3D28C25E; Wed, 27 Aug 2008 15:08:07 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8373928C24F for ; Wed, 27 Aug 2008 15:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfEbkDRkd5Yg for ; Wed, 27 Aug 2008 15:08:01 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7CF5928C23D for ; Wed, 27 Aug 2008 15:08:01 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7RLmZMo072276 for ; Wed, 27 Aug 2008 17:48:35 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808272148.m7RLmZMo072276@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 17:47:41 -0400 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Fwd: Early warning: draft-reid-dnsext-aleatoric-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org >Count: 33 >DNSEXT J. Reid >Internet-Draft RTFM Ltd >Intended status: Standards Track August 6, 2008 >Expires: February 7, 2009 > A DNS Resource Record for Additional Entropy > > > Abstract > A scheme to defend against cache poisoning attacks against the Domain > Name System (DNS) by predicting the ID and source port number of > outgoing queries is described in this draft. It proposes a new > resource record to provide a mechanism to introduce additional > entropy into DNS queries. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Aug 28 05:46:32 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6AFE28C1C8; Thu, 28 Aug 2008 05:46:32 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4CC28C0E9 for ; Thu, 28 Aug 2008 05:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bCfF5umTamW for ; Thu, 28 Aug 2008 05:46:29 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 25DA43A6C1C for ; Thu, 28 Aug 2008 05:46:28 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KYgtB-00054t-Ta; Thu, 28 Aug 2008 14:46:13 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id CC8F17F29DF; Thu, 28 Aug 2008 14:46:13 +0200 (CEST) Date: Thu, 28 Aug 2008 14:46:13 +0200 From: Peter Koch To: Thomas Narten Message-ID: <20080828124613.GH14541@unknown.office.denic.de> References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> <20080821155656.GC6169@unknown.office.denic.de> <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> <200808271243.m7RCh4GA013966@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808271243.m7RCh4GA013966@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.4.2.1i Cc: IETF DNS Directorate Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, Aug 27, 2008 at 08:43:04AM -0400, Thomas Narten wrote: [meeting based on 1600 Paris local time] > Can we please stick with something stable and predictable and > easy to put into a recurring calendar entry? Like UTC? Please don't > make me have to think about when DST changes in various parts of the > world. I'd like to add that to the upcoming meeting's agenda. Speaking of which, those who haven't voted yet, please visit , so we know we meet on 1st or 8th of September. As a practical matter, some calendars allow to use a remote timezone for scheduling (recurring) events. The calendar will take care of Paris' DST change then. But see above. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Fri Aug 29 05:22:42 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478BF3A697B; Fri, 29 Aug 2008 05:22:42 -0700 (PDT) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1E03A67F9 for ; Fri, 29 Aug 2008 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaBIT4WJwqB1 for ; Fri, 29 Aug 2008 05:22:40 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 971F23A695E for ; Fri, 29 Aug 2008 05:22:37 -0700 (PDT) Received: from home.liman.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id m7TCMcxg011948 for ; Fri, 29 Aug 2008 14:22:38 +0200 (MEST) Received: from zaptop.autonomica.net (zaptop.autonomica.net [192.71.80.71]) by home.liman.net (8.13.8/8.13.8) with ESMTP id m7TCMb2b012487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 29 Aug 2008 14:22:38 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id m7TCMaZj003250 for ; Fri, 29 Aug 2008 14:22:38 +0200 (CEST) To: IETF DNS Directorate References: <20080819181713.GN1740@unknown.office.denic.de> <200808201313.m7KDDQUM022984@cichlid.raleigh.ibm.com> <20080821150229.GF988@dul1mcmlarson-l1.verisignlabs.com> <20080821155656.GC6169@unknown.office.denic.de> <20080826140343.GA5970@dul1mcmlarson-l1.verisignlabs.com> <200808271243.m7RCh4GA013966@cichlid.raleigh.ibm.com> <20080828124613.GH14541@unknown.office.denic.de> From: Lars-Johan Liman Date: Fri, 29 Aug 2008 14:22:36 +0200 In-Reply-To: <20080828124613.GH14541@unknown.office.denic.de> (Peter Koch's message of "Thu\, 28 Aug 2008 14\:46\:13 +0200") Message-ID: <22tzd4ggdv.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Subject: Re: [dns-dir] Meeting/TelCo 2008-09-01 conference logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Are we reaching some kind of consensus on the date? My DLC (domestic logistics centre) needs to know ... ;-) Cheers, /Liman _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir