From dns-dir-bounces@ietf.org Sun Jan 4 00:21:07 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869733A6A14; Sun, 4 Jan 2009 00:21:07 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13233A6897; Sun, 4 Jan 2009 00:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 cDKJ72zhPmGZ; Sun, 4 Jan 2009 00:21:04 -0800 (PST) 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 530113A690B; Sun, 4 Jan 2009 00:21:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,324,1228107600"; d="scan'208";a="156564253" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 04 Jan 2009 03:20:51 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jan 2009 03:20:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jan 2009 09:20:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for January 8, 2009 Telechat Thread-Index: Acls/3fkWSY+fmb4Q3mGo5xPppPqgABQqpBQ From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for January 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 1/8 IESG telechat. Please send me comments or questions about the relevant documents until Wednesday 1/7 COB. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary S 2.1 WG Submissions 2.1.1 New Item o draft-ietf-isis-wg-extlsp-05.txt Simplified Extension of LSP Space for IS-IS (Proposed Standard) - 1 of 3 Token: Ross Callon o draft-ietf-sip-session-policy-framework-05.txt A Framework for Session Initiation Protocol (SIP) Session Policies (Proposed Standard) - 2 of 3 Token: Cullen Jennings o draft-ietf-idr-rfc3392bis-03.txt Capabilities Advertisement with BGP-4 (Proposed Standard) - 3 of 3 Token: David Ward 2.1.2 Returning Item o draft-ietf-smime-3851bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Proposed Standard) - 1 of 2 Token: Tim Polk o draft-ietf-smime-3850bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling (Proposed Standard) - 2 of 2 Token: Tim Polk 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item o draft-housley-iesg-rfc3932bis-06.txt IESG Procedures for Handling of Independent and IRTF Stream Submissions (BCP) - 1 of 1 Note: Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html Token: Jari Arkko 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-tls-des-idea-02.txt DES and IDEA Cipher Suites for Transport Layer Security (TLS) (Informational) - 1 of 2 Token: Tim Polk o draft-ietf-ippm-delay-var-as-01.txt Packet Delay Variation Applicability Statement (Informational) - 2 of 2 Token: Lars Eggert 3.1.2 Returning Item o draft-ietf-pim-rpf-vector-06.txt The RPF Vector TLV (Informational) - 1 of 1 Token: David Ward 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-dasgupta-ccamp-path-comp-analysis-02.txt Performance Analysis of Inter-Domain Path Computation Methodologies (Informational) - 1 of 3 Token: Ross Callon o draft-raj-dhc-tftp-addr-option-04.txt VoIP Configuration Server Address Option (Informational) - 2 of 3 Token: Jari Arkko o draft-korhonen-mip4-service-07.txt Service Selection for Mobile IPv4 (Informational) - 3 of 3 Token: Jari Arkko 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 NONE 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 o Message Organization (morg) - 1 of 1 Token: Chris Newman 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Network Configuration (netconf) - 1 of 2 Token: Dan Romascanu o IP Performance Metrics (ippm) - 2 of 2 Token: Lars Eggert _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sun Jan 4 00:26:56 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DAD3A6897; Sun, 4 Jan 2009 00:26:56 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B213A6806; Sun, 4 Jan 2009 00:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 wl3cRdwTms6K; Sun, 4 Jan 2009 00:26:54 -0800 (PST) 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 3234C3A67E2; Sun, 4 Jan 2009 00:26:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,324,1228107600"; d="scan'208";a="156564401" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 04 Jan 2009 03:26:41 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jan 2009 03:26:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jan 2009 09:26:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-korhonen-mip4-service-07.txt to Informational RFC Thread-Index: Aclt3U+zt4eXanQ8Sva5G2u+oaXsnQAaHMMQ From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" Subject: [dns-dir] FW: Evaluation: draft-korhonen-mip4-service-07.txt to Informational RFC X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-korhonen-mip4-service-05.txt Technical Summary This document describes a Service Selection extension for both conventional Mobile IPv4 and Proxy Mobile IPv4 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding update procedure. The service selection may affect home agent routing decisions, Qos and policy treatment of service related IP flows in the home agent and also Home Address assignment policies. Working Group Summary This document is an individual submission. The document was presented in MIP4 WG meetings. The document was proposed to be a WG work item. However, the decision of adoption as a WG work item got postponed due time schedule challenges with the current MIP4 WG charter and dependencies with external Standardization Development Organizations. Document Quality There are no publicly known implementations yet. There is certain level of interest from 3GPP Release-8 Evolved Packet Core work. The document has been used in 3GPP TS 24.304 as a part of their MIP4 based trusted non-3GPP access interworking solution. Personnel The responsible Area Director is Jari Arkko. RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sun Jan 4 09:26:38 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751AB28C0E4; Sun, 4 Jan 2009 09:26:38 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DBC3A687C; Sun, 4 Jan 2009 09:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 ZK2zqe8DPscl; Sun, 4 Jan 2009 09:26:36 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BC32E3A67A8; Sun, 4 Jan 2009 09:26:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,328,1228107600"; d="scan'208";a="133033464" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Jan 2009 12:26:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Jan 2009 12:26:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jan 2009 18:26:14 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: PRELIMINARY Agenda and Package for January 8, 2009 Telechat Thread-Index: AcludLPmlwiUNodgR/W2/HwppEVifgAAEhuA References: From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" , ops-dir@ietf.org, IETF DNS Directorate Subject: Re: [dns-dir] [OPS-DIR] FW: PRELIMINARY Agenda and Package for January 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Sunday, January 04, 2009 4:00 PM > To: Romascanu, Dan (Dan) > Cc: IETF DNS Directorate; ops-dir@ietf.org; > aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: Re: [OPS-DIR] FW: PRELIMINARY Agenda and Package for > January 8, 2009 Telechat > > > Hi Dan, > > Is it possible to send us the proposed charter text for > netconf and ippm? I don't have any particular concerns about > rechartering these groups, but I would be willing to look > over the text. > > Margaret > Here you go: -------------- Message ORGanization (morg) ------------------------------------------ Last Modified: 2008-12-11 Current Status: Proposed Working Group Chair(s): Randall Gellens (co-chair TBD) Applications Area Directors: Chris Newman Lisa Dusseault Application Area Advisor: Chris Newman Mailing Lists: General Discussion: morg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/morg Archive: http://www.ietf.org/mail-archive/web/morg/current/maillist.html Description: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. ==== --------------------------------- Network Configuration (netconf) ================================ Last Modified: 2008-12-16 Additional information is available at tools.ietf.org/wg/netconf Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Goals and Milestones: Done Working Group formed Done Submit initial Netconf Protocol draft Done Submit initial Netconf over (transport-TBD) draft Done Begin Working Group Last Call for the Netconf Protocol draft Done Begin Working Group Last Call for the Netconf over (transport-TBD) draft Done Submit final version of the Netconf Protocol draft to the IESG Done Submit final version of the Netconf over SOAP draft to the IESG Done Submit final version of the Netconf over BEEP draft to the IESG Done Submit final version of the Netconf over SSH draft to the IESG Done Update charter Done Submit first version of NETCONF Notifications document Done Begin WGLC of NETCONF Notifications document Done Submit final version of NETCONF Notifications document to IESG for consideration as Proposed Standard Done -00 draft for fine Grain Locking Done -00 draft for NETCONF over TLS Done -00 draft for NETCONF Monitoring Done -00 draft for Schema Advertisement Done Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 N.A. WG Last Call on Schema Advertisement after IETF72 Schema Advertisement has been merged into Monitoring Done WG Last Call on NETCONF over TLS after IETF72 Done Netconf over TLS to IESG for consideration as Proposed Standards Dec 2008 WG Last Call on Fine Grain Locking after IETF73 Dec 2008 Send Partial Locking to IESG for consideration as Proposed Standards Jan 2009 Initial WG draft for with-defaults capability Feb 2009 Initial WG draft for rfc4741bis Mar 2009 WG Last Call on NETCONF Monitoring after IETF73 Apr 2009 WG Last Call on rfc4741bis Apr 2009 WG Last Call on with-defaults Jun 2009 rfc4741bis to IESG for considerations as Proposed Standard Jun 2009 with-defaults capability to IESG for considerations as Proposed Standard ------------------------------- IP Performance Metrics (ippm) -------------------------------------------- Last Modified: 2008-12-19 Status: Active Working Group Additional information is available at tools.ietf.org/wg/ippm Chair(s): Matthew Zekauskas [matt@internet2.edu] Henk Uijterwaal [henk@ripe.net] Transport Area Director(s): Magnus Westerlund magnus.westerlund@ericsson.com] Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: Lars Eggert [lars.eggert@nokia.com] Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/index.html Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. It will be guided by applicable IESG documents in this area. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. ------------------------ _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 5 11:30:19 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0775E28C0FE; Mon, 5 Jan 2009 11:30:19 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBAE3A6A3A for ; Mon, 5 Jan 2009 11:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 wG1LvwHhPk7E for ; Mon, 5 Jan 2009 11:30:16 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 35F9C3A6A30 for ; Mon, 5 Jan 2009 11:30:15 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n05JU27R006542 for ; Mon, 5 Jan 2009 14:30:02 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 5 Jan 2009 14:30:02 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090105_193002_028664.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-klensin-rfc5321-numbered-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: , 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 Count: 20 Network Working Group J. Klensin Internet-Draft December 14, 2008 Obsoletes: 5321 (if approved) Intended status: Standards Track Simple Mail Transfer Protocol draft-klensin-rfc5321-numbered-00.txt Abstract 20 This document is a specification of the basic protocol for Internet 21 electronic mail transport. It consolidates, updates, and clarifies 22 several previous documents, making all or parts of most of them 23 obsolete. It covers the SMTP extension mechanisms and best practices 24 for the contemporary Internet, but does not provide details about 25 particular extensions. Although SMTP was designed as a mail 26 transport and delivery protocol, this specification also contains 27 information that is important to its use as a "mail submission" 28 protocol for "split-UA" (User Agent) mail reading systems and mobile 29 environments. 56 58 Internet-Draft RFC5321-Numbered Dec 2008 _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 5 11:30:21 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1425128C119; Mon, 5 Jan 2009 11:30:21 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5087A28C118 for ; Mon, 5 Jan 2009 11:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 d0Pxs-5YFmWd for ; Mon, 5 Jan 2009 11:30:18 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 418FB3A6A30 for ; Mon, 5 Jan 2009 11:30:18 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n05JU4tU006686 for ; Mon, 5 Jan 2009 14:30:04 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 5 Jan 2009 14:30:04 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090105_193004_040508.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-eai-dsnbis-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: , 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 Count: 17 Network Working Group C. Newman Internet-Draft Sun Microsystems Obsoletes: 5337 (if approved) A. Melnikov, Ed. Updates: 3461,3462,3464,3798 Isode Ltd (if approved) December 16, 2008 Intended status: Experimental Expires: June 19, 2009 Internationalized Delivery Status and Disposition Notifications draft-ietf-eai-dsnbis-00.txt Abstract Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 5 11:43:52 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E633A692A; Mon, 5 Jan 2009 11:43:52 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572023A6994 for ; Mon, 5 Jan 2009 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 97eGPlIpjBBx for ; Mon, 5 Jan 2009 11:43:50 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8A8903A68E1 for ; Mon, 5 Jan 2009 11:43:50 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n05JU6n3006841 for ; Mon, 5 Jan 2009 14:30:06 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 5 Jan 2009 14:30:06 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090105_193006_028834.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-behave-turn-uri-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: , 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 Count: 30 Network Working Group M. Petit-Huguenin Internet-Draft (Unaffiliated) Intended status: Standards Track December 21, 2008 Expires: June 24, 2009 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers draft-ietf-behave-turn-uri-00 Abstract This document defines two URI schemes and the resolution mechanism to convert these URIs to a list of server transport addresses that can _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 5 11:43:53 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045E13A6A0B; Mon, 5 Jan 2009 11:43:53 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9493A6994 for ; Mon, 5 Jan 2009 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 wOgWXNxJ0c+A for ; Mon, 5 Jan 2009 11:43:51 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 15BFE3A692A for ; Mon, 5 Jan 2009 11:43:50 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n05JU3EX006591 for ; Mon, 5 Jan 2009 14:30:03 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 5 Jan 2009 14:30:03 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090105_193003_091974.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-templin-autoconf-dhcp-23.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: , 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 Count: 14 Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational December 15, 2008 Expires: June 18, 2009 Virtual Enterprise Traversal (VET) draft-templin-autoconf-dhcp-23.txt Abstract Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Nodes in enterprise networks must have a way to automatically provision IP addresses/prefixes and other information, and must also support post- autoconfiguration operations even for highly-dynamic networks. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 5 11:43:54 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1002328C0FE; Mon, 5 Jan 2009 11:43:54 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AEB3A692A for ; Mon, 5 Jan 2009 11:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 wD6FMhvmGJY0 for ; Mon, 5 Jan 2009 11:43:51 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 96B3D3A68E1 for ; Mon, 5 Jan 2009 11:43:51 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n05JU2ct006556 for ; Mon, 5 Jan 2009 14:30:02 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 5 Jan 2009 14:30:02 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090105_193002_053993.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-melnikov-eai-rfc5337bis-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: , 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 Count: 17 Network Working Group C. Newman Internet-Draft Sun Microsystems Obsoletes: 5337 (if approved) A. Melnikov, Ed. Updates: 3461,3462,3464,3798 Isode Ltd (if approved) December 15, 2008 Intended status: Experimental Expires: June 18, 2009 Internationalized Delivery Status and Disposition Notifications draft-melnikov-eai-rfc5337bis-00.txt Abstract Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Jan 6 11:30:17 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF363A6900; Tue, 6 Jan 2009 11:30:17 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E553A6900 for ; Tue, 6 Jan 2009 11:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 F-pTdtTTHyFy for ; Tue, 6 Jan 2009 11:30:15 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8C7633A6872 for ; Tue, 6 Jan 2009 11:30:15 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n06JU1tA037939 for ; Tue, 6 Jan 2009 14:30:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 6 Jan 2009 14:30:01 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090106_193001_006859.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-dnsproxy-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: , 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 Count: 94 DNSEXT R. Bellis Internet-Draft Nominet UK Intended status: BCP January 6, 2009 Expires: July 10, 2009 DNS Proxy Implementation Guidelines draft-ietf-dnsext-dnsproxy-01 Abstract This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Jan 7 10:43:25 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8863A6A86; Wed, 7 Jan 2009 10:43:25 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1463F28C0F4 for ; Sun, 4 Jan 2009 06:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 u29rOYW9JODF for ; Sun, 4 Jan 2009 06:00:52 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id F2CAA28C0E4 for ; Sun, 4 Jan 2009 06:00:51 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id zRpu1a00416AWCUA3Rzg0H; Sun, 04 Jan 2009 13:59:40 +0000 Received: from [10.36.0.45] ([76.119.58.152]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id zRzc1a0023H3vh08SRzd0Y; Sun, 04 Jan 2009 13:59:40 +0000 Message-Id: From: Margaret Wasserman To: "Romascanu, Dan (Dan)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 4 Jan 2009 08:59:33 -0500 References: X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Wed, 07 Jan 2009 10:43:24 -0800 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" , ops-dir@ietf.org, IETF DNS Directorate Subject: Re: [dns-dir] [OPS-DIR] FW: PRELIMINARY Agenda and Package for January 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hi Dan, Is it possible to send us the proposed charter text for netconf and ippm? I don't have any particular concerns about rechartering these groups, but I would be willing to look over the text. Margaret On Jan 4, 2009, at 3:20 AM, Romascanu, Dan (Dan) wrote: > Please find below the preliminary agenda of the 1/8 IESG telechat. > Please send me comments or questions about the relevant documents > until > Wednesday 1/7 COB. > > Thanks and Regards, > > Dan > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of > IESG Secretary > S > > 2.1 WG Submissions > 2.1.1 New Item > o draft-ietf-isis-wg-extlsp-05.txt > Simplified Extension of LSP Space for IS-IS (Proposed Standard) - 1 > of > 3 > Token: Ross Callon > o draft-ietf-sip-session-policy-framework-05.txt > A Framework for Session Initiation Protocol (SIP) Session Policies > (Proposed Standard) - 2 of 3 > Token: Cullen Jennings > o draft-ietf-idr-rfc3392bis-03.txt > Capabilities Advertisement with BGP-4 (Proposed Standard) - 3 of 3 > Token: David Ward > > 2.1.2 Returning Item > o draft-ietf-smime-3851bis-08.txt > Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 > Message > Specification (Proposed Standard) - 1 of 2 > Token: Tim Polk > o draft-ietf-smime-3850bis-08.txt > Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 > Certificate Handling (Proposed Standard) - 2 of 2 > Token: Tim Polk > > > 2.2 Individual Submissions > 2.2.1 New Item > NONE > 2.2.2 Returning Item > o draft-housley-iesg-rfc3932bis-06.txt > IESG Procedures for Handling of Independent and IRTF Stream > Submissions > (BCP) - 1 of 1 > Note: Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html > Token: Jari Arkko > > > 3. Document Actions > > 3.1 WG Submissions > Reviews should focus on these questions: "Is this document a > reasonable > contribution to the area of Internet engineering which it > covers? If > not, what changes would make it so?" > > 3.1.1 New Item > o draft-ietf-tls-des-idea-02.txt > DES and IDEA Cipher Suites for Transport Layer Security (TLS) > (Informational) - 1 of 2 > Token: Tim Polk > o draft-ietf-ippm-delay-var-as-01.txt > Packet Delay Variation Applicability Statement (Informational) - 2 > of > 2 > Token: Lars Eggert > > 3.1.2 Returning Item > o draft-ietf-pim-rpf-vector-06.txt > The RPF Vector TLV (Informational) - 1 of 1 > Token: David Ward > > > 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-dasgupta-ccamp-path-comp-analysis-02.txt > Performance Analysis of Inter-Domain Path Computation Methodologies > (Informational) - 1 of 3 > Token: Ross Callon > o draft-raj-dhc-tftp-addr-option-04.txt > VoIP Configuration Server Address Option (Informational) - 2 of 3 > Token: Jari Arkko > o draft-korhonen-mip4-service-07.txt > Service Selection for Mobile IPv4 (Informational) - 3 of 3 > Token: Jari Arkko > > 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 > NONE > 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 > o Message Organization (morg) - 1 of 1 > Token: Chris Newman > 4.2 WG Rechartering > 4.2.1 Under evaluation for IETF Review > o Network Configuration (netconf) - 1 of 2 > Token: Dan Romascanu > o IP Performance Metrics (ippm) - 2 of 2 > Token: Lars Eggert > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 8 08:45:48 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09563A6ACE; Thu, 8 Jan 2009 08:45:48 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DB93A6ACE for ; Thu, 8 Jan 2009 08:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIfotqAcPJGc for ; Thu, 8 Jan 2009 08:45:45 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E9C593A6A31 for ; Thu, 8 Jan 2009 08:45:44 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n08GjSxb066348; Thu, 8 Jan 2009 11:45:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200901081645.n08GjSxb066348@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Jan 2009 11:44:21 -0500 To: "Romascanu, Dan (Dan)" , "IETF DNS Directorate" From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for January 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0223665272==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --===============0223665272== Content-Type: multipart/alternative; boundary="=====================_274173039==.ALT" --=====================_274173039==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed None of the documents are on the DNS early warning list. Olafur At 03:20 04/01/2009, Romascanu, Dan (Dan) wrote: >Please find below the preliminary agenda of the 1/8 IESG telechat. >Please send me comments or questions about the relevant documents until >Wednesday 1/7 COB. > >Thanks and Regards, > >Dan > > >-----Original Message----- >From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of >IESG Secretary >S > >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-isis-wg-extlsp-05.txt > Simplified Extension of LSP Space for IS-IS (Proposed Standard) - 1 >of >3 > Token: Ross Callon > o draft-ietf-sip-session-policy-framework-05.txt > A Framework for Session Initiation Protocol (SIP) Session Policies > (Proposed Standard) - 2 of 3 > Token: Cullen Jennings > o draft-ietf-idr-rfc3392bis-03.txt > Capabilities Advertisement with BGP-4 (Proposed Standard) - 3 of 3 > Token: David Ward > >2.1.2 Returning Item > o draft-ietf-smime-3851bis-08.txt > Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 >Message > Specification (Proposed Standard) - 1 of 2 > Token: Tim Polk > o draft-ietf-smime-3850bis-08.txt > Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 > Certificate Handling (Proposed Standard) - 2 of 2 > Token: Tim Polk > > >2.2 Individual Submissions >2.2.1 New Item >NONE >2.2.2 Returning Item > o draft-housley-iesg-rfc3932bis-06.txt > IESG Procedures for Handling of Independent and IRTF Stream >Submissions > (BCP) - 1 of 1 > Note: Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html > Token: Jari Arkko > > >3. Document Actions > >3.1 WG Submissions > Reviews should focus on these questions: "Is this document a >reasonable > contribution to the area of Internet engineering which it >covers? If > not, what changes would make it so?" > >3.1.1 New Item > o draft-ietf-tls-des-idea-02.txt > DES and IDEA Cipher Suites for Transport Layer Security (TLS) > (Informational) - 1 of 2 > Token: Tim Polk > o draft-ietf-ippm-delay-var-as-01.txt > Packet Delay Variation Applicability Statement (Informational) - 2 >of >2 > Token: Lars Eggert > >3.1.2 Returning Item > o draft-ietf-pim-rpf-vector-06.txt > The RPF Vector TLV (Informational) - 1 of 1 > Token: David Ward > > >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-dasgupta-ccamp-path-comp-analysis-02.txt > Performance Analysis of Inter-Domain Path Computation Methodologies > (Informational) - 1 of 3 > Token: Ross Callon > o draft-raj-dhc-tftp-addr-option-04.txt > VoIP Configuration Server Address Option (Informational) - 2 of 3 > Token: Jari Arkko > o draft-korhonen-mip4-service-07.txt > Service Selection for Mobile IPv4 (Informational) - 3 of 3 > Token: Jari Arkko > >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 >NONE >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 > o Message Organization (morg) - 1 of 1 > Token: Chris Newman >4.2 WG Rechartering >4.2.1 Under evaluation for IETF Review > o Network Configuration (netconf) - 1 of 2 > Token: Dan Romascanu > o IP Performance Metrics (ippm) - 2 of 2 > Token: Lars Eggert > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir --=====================_274173039==.ALT Content-Type: text/html; charset="us-ascii" None of the documents are on the DNS early warning list.

        Olafur


At 03:20 04/01/2009, Romascanu, Dan (Dan) wrote:
Please find below the preliminary agenda of the 1/8 IESG telechat.
Please send me comments or questions about the relevant documents until
Wednesday 1/7 COB.

Thanks and Regards,

Dan


-----Original Message-----
From: iesg-bounces@ietf.org [ mailto:iesg-bounces@ietf.org] On Behalf Of
IESG Secretary
S

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-isis-wg-extlsp-05.txt
    Simplified Extension of LSP Space for IS-IS (Proposed Standard) - 1
of
3
    Token: Ross Callon
  o draft-ietf-sip-session-policy-framework-05.txt
    A Framework for Session Initiation Protocol (SIP) Session Policies
    (Proposed Standard) - 2 of 3
    Token: Cullen Jennings
  o draft-ietf-idr-rfc3392bis-03.txt
    Capabilities Advertisement with BGP-4 (Proposed Standard) - 3 of 3
    Token: David Ward

2.1.2 Returning Item
  o draft-ietf-smime-3851bis-08.txt
    Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message
    Specification (Proposed Standard) - 1 of 2
    Token: Tim Polk
  o draft-ietf-smime-3850bis-08.txt
    Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
    Certificate Handling (Proposed Standard) - 2 of 2
    Token: Tim Polk


2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
  o draft-housley-iesg-rfc3932bis-06.txt
    IESG Procedures for Handling of Independent and IRTF Stream
Submissions
    (BCP) - 1 of 1
    Note: Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html
    Token: Jari Arkko


3. Document Actions

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

3.1.1 New Item
  o draft-ietf-tls-des-idea-02.txt
    DES and IDEA Cipher Suites for Transport Layer Security (TLS)
    (Informational) - 1 of 2
    Token: Tim Polk
  o draft-ietf-ippm-delay-var-as-01.txt
    Packet Delay Variation Applicability Statement (Informational) - 2
of
2
    Token: Lars Eggert

3.1.2 Returning Item
  o draft-ietf-pim-rpf-vector-06.txt
    The RPF Vector TLV (Informational) - 1 of 1
    Token: David Ward


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-dasgupta-ccamp-path-comp-analysis-02.txt
    Performance Analysis of Inter-Domain Path Computation Methodologies
    (Informational) - 1 of 3
    Token: Ross Callon
  o draft-raj-dhc-tftp-addr-option-04.txt
    VoIP Configuration Server Address Option (Informational) - 2 of 3
    Token: Jari Arkko
  o draft-korhonen-mip4-service-07.txt
    Service Selection for Mobile IPv4 (Informational) - 3 of 3
    Token: Jari Arkko

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
        <X>, but this does not prevent publishing; 3) The IESG thinks
        that publication is harmful to work in WG <X> and recommends
        not publishing at this time; 4) The IESG thinks that this
        document violates the IETF procedures for <X> 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
NONE
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
  o Message Organization (morg) - 1 of 1
    Token: Chris Newman
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
  o Network Configuration (netconf) - 1 of 2
    Token: Dan Romascanu
  o IP Performance Metrics (ippm) - 2 of 2
    Token: Lars Eggert


_______________________________________________
dns-dir mailing list
dns-dir@ietf.org
https://www.ietf.org/mailman/listinfo/dns-dir
--=====================_274173039==.ALT-- --===============0223665272== 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 --===============0223665272==-- From dns-dir-bounces@ietf.org Thu Jan 8 11:30:18 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F5E3A6AAA; Thu, 8 Jan 2009 11:30:18 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E853A6AA4 for ; Thu, 8 Jan 2009 11:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 R2-ppDLd2Os2 for ; Thu, 8 Jan 2009 11:30:16 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D672D3A69BD for ; Thu, 8 Jan 2009 11:30:15 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n08JU14Y067582 for ; Thu, 8 Jan 2009 14:30:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 8 Jan 2009 14:30:01 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090108_193001_045656.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-otis-auth-header-sec-issues-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: , 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 Count: 13 Individual D. Otis Internet-Draft Trend Micro, NSSG Intended status: Informational January 07, 2009 Expires: July 11, 2009 Authentication-Results Header Field Security Issues draft-otis-auth-header-sec-issues-00 Abstract The proposed [I-D.kucherawy-sender-auth-header] defines a header field used to capture email verification results of border _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Fri Jan 9 01:25:57 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F053A69BD; Fri, 9 Jan 2009 01:25:57 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9463A69BC; Fri, 9 Jan 2009 01:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 iIzHbDlRKZb4; Fri, 9 Jan 2009 01:25:55 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4610E3A67BD; Fri, 9 Jan 2009 01:25:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,238,1231131600"; d="scan'208";a="133563260" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Jan 2009 04:25:35 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jan 2009 04:25:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 10:25:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for January 15, 2009 Telechat Thread-Index: Aclx5ekBFge10dt9RXaIDY0r/3RPJQAVVytA From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for January 15, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 1/15 IESG telechat. Please send all comments and concerns related to the documents in review until Wednesday 1/14 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2.1 WG Submissions 2.1.1 New Item o draft-ietf-pce-of-06.txt Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (Proposed Standard) - 1 of 3 Token: Ross Callon o draft-ietf-pce-dste-02.txt Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol (Proposed Standard) - 2 of 3 Token: Ross Callon o draft-ietf-sieve-managesieve-06.txt A Protocol for Remotely Managing Sieve Scripts (Proposed Standard) - 3 of 3 Token: Lisa Dusseault 2.1.2 Returning Item o draft-ietf-dkim-ssp-08.txt DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (Proposed Standard) - 1 of 1 Note: Document shepherd is Stephen Farrell (stephen.farrell@cs.tcd.ie) Token: Pasi Eronen 2.2 Individual Submissions 2.2.1 New Item o draft-hoffman-dac-vbr-05.txt Vouch By Reference (Proposed Standard) - 1 of 1 Token: Russ Housley 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-ospf-manet-mdr-04.txt MANET Extension of OSPF using CDS Flooding (Experimental) - 1 of 3 Token: David Ward o draft-ietf-ospf-manet-mpr-03.txt OSPF MPR Extension for Ad Hoc Networks (Experimental) - 2 of 3 Token: David Ward o draft-ietf-ospf-manet-or-01.txt Extensions to OSPF to Support Mobile Ad Hoc Networking (Experimental) - 3 of 3 Token: David Ward _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Fri Jan 9 05:38:13 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFCC3A6B20; Fri, 9 Jan 2009 05:38:13 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44543A6B1E for ; Fri, 9 Jan 2009 05:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 vk8BliYfHMSz for ; Fri, 9 Jan 2009 05:38:12 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id F0DED3A686E for ; Fri, 9 Jan 2009 05:38:11 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n09DaWnC006236 for ; Fri, 9 Jan 2009 06:36:32 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n09DbvZ1204810 for ; Fri, 9 Jan 2009 06:37:57 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n09DbvlO024950 for ; Fri, 9 Jan 2009 06:37:57 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-4.mts.ibm.com [9.65.234.4]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n09DbtGl024930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 06:37:57 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n09DbtNb015147 for ; Fri, 9 Jan 2009 08:37:55 -0500 Message-Id: <200901091337.n09DbtNb015147@cichlid.raleigh.ibm.com> To: dns directorate Date: Fri, 09 Jan 2009 08:37:55 -0500 From: Thomas Narten Subject: [dns-dir] Google's IPv6 plans 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 http://www.google.com/intl/en/ipv6/ The interesting point is that they will return AAAA records for DNS queries (like www.google.com) if the requesting IP address is "approved", i.e., is known to have good IPv6 connectivity. They are trying to solve a real problem (don't put AAAA into the DNS if it diminishes service to existing customers), but they are doing so in a way that arguably takes two-faced DNS to another level, and further blurs the notion of a single global name space. Thomas _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sat Jan 10 11:30:18 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54A928C1B7; Sat, 10 Jan 2009 11:30:18 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E9428C1B7 for ; Sat, 10 Jan 2009 11:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 w120sBLKqyy8 for ; Sat, 10 Jan 2009 11:30:16 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 92CF528C14C for ; Sat, 10 Jan 2009 11:30:16 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0AJU1nJ096657 for ; Sat, 10 Jan 2009 14:30:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 10 Jan 2009 14:30:01 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090110_193001_029081.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-hammer-discovery-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: , 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 Count: 12 Network Working Group E. Hammer-Lahav Internet-Draft Yahoo! Intended status: Informational January 9, 2009 Expires: July 13, 2009 HTTP-based Resource Descriptor Discovery draft-hammer-discovery-00 Abstract This memo describes an HTTP-based process for obtaining information about a resource identified by a URI. The 'information about a _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 15 11:30:19 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED10E3A69EB; Thu, 15 Jan 2009 11:30:19 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897CB3A68A1 for ; Thu, 15 Jan 2009 11:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 UDYDLAHCpHBS for ; Thu, 15 Jan 2009 11:30:17 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 972403A69EB for ; Thu, 15 Jan 2009 11:30:17 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0FJU1NN050912 for ; Thu, 15 Jan 2009 14:30:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 15 Jan 2009 14:30:01 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090115_193001_096971.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-zhang-keyword-ddds-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: , 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 Count: 41 Network Working Group G. Zhang Internet-Draft X. Lee Intended status: Standards Track CNNIC Expires: July 19, 2009 January 15, 2009 The keyword to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(Keyword) draft-zhang-keyword-ddds-00.txt Abstract This memo discusses the use of the Domain Name System(DNS) for storage of Keyword to URI mapping. More specifically, how DNS can be used for identifying URIs associated with one Keyword. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sun Jan 18 03:58:46 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43723A68E8; Sun, 18 Jan 2009 03:58:46 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4553A68F6 for ; Sun, 18 Jan 2009 03:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 zQuwnNl5lhJ3 for ; Sun, 18 Jan 2009 03:58:45 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 227513A6B4F for ; Sun, 18 Jan 2009 03:58:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,283,1231131600"; d="scan'208";a="148999749" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 18 Jan 2009 06:58:28 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jan 2009 06:58:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 12:58:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about draft-hoffman-dac-vbr Thread-Index: Acl3324zgnwomvuzRsm1Luiiz5gK1wBhIX4g From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" Cc: Cullen Jennings Subject: [dns-dir] FW: Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Anybody in DNS-DIR looking at this I-D? Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, January 16, 2009 3:36 PM To: IESG IESG Subject: Question about draft-hoffman-dac-vbr Is there a DNS and Sec Review of draft-hoffman-dac-vbr draft somewhere? _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Jan 20 01:16:45 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331773A6B8A; Tue, 20 Jan 2009 01:16:45 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB15D3A6B8A for ; Tue, 20 Jan 2009 01:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 aWo6NnrrhX1I for ; Tue, 20 Jan 2009 01:16:44 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D6EC53A6B19 for ; Tue, 20 Jan 2009 01:16:43 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D365D19871F; Tue, 20 Jan 2009 11:16:26 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9DDB01986E2; Tue, 20 Jan 2009 11:16:26 +0200 (EET) Message-ID: <4975962D.4090305@piuha.net> Date: Tue, 20 Jan 2009 11:15:25 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Thomas Narten References: <200901091337.n09DbtNb015147@cichlid.raleigh.ibm.com> In-Reply-To: <200901091337.n09DbtNb015147@cichlid.raleigh.ibm.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: dns directorate Subject: Re: [dns-dir] Google's IPv6 plans 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 Yeah. This is in use in Free.fr, I think. I agree with the points you are making, but my understanding is that not only is this done for IPv6's sake, but its already being done for other reasons, like localization. Jari Thomas Narten wrote: > http://www.google.com/intl/en/ipv6/ > > The interesting point is that they will return AAAA records for DNS > queries (like www.google.com) if the requesting IP address is > "approved", i.e., is known to have good IPv6 connectivity. > > They are trying to solve a real problem (don't put AAAA into the DNS > if it diminishes service to existing customers), but they are doing so > in a way that arguably takes two-faced DNS to another level, and > further blurs the notion of a single global name space. > > Thomas > _______________________________________________ > 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 Jan 20 06:30:13 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E093A6BF7; Tue, 20 Jan 2009 06:30:13 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDED3A6BC7 for ; Tue, 20 Jan 2009 06:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 OghMHvgrc8rV for ; Tue, 20 Jan 2009 06:30:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 83ED53A6BF3 for ; Tue, 20 Jan 2009 06:30:10 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BE5A82FE9556 for ; Tue, 20 Jan 2009 14:29:51 +0000 (UTC) Date: Tue, 20 Jan 2009 09:29:50 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090120142949.GD4036@shinkuro.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] FW: Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Sun, Jan 18, 2009 at 12:58:19PM +0100, Romascanu, Dan (Dan) wrote: > Anybody in DNS-DIR looking at this I-D? I haven't done. When do you need it? I can try to schedule some time for it this week. I haven't been doing my share, so it's my turn, I think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Jan 20 11:30:21 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663C528C0E9; Tue, 20 Jan 2009 11:30:21 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BAA3A6BEB for ; Tue, 20 Jan 2009 11:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 k-V8ULhMvrPd for ; Tue, 20 Jan 2009 11:30:18 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6692D3A6B91 for ; Tue, 20 Jan 2009 11:30:18 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0KJU0EB013009 for ; Tue, 20 Jan 2009 14:30:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Jan 2009 14:30:00 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090120_193000_085352.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ponomarev-hip-hit2ip-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: , 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 Count: 17 Host Identity Protocol O. Ponomarev Internet-Draft A. Gurtov Intended status: Experimental Helsinki Institute for Information Expires: July 24, 2009 Technology January 20, 2009 Using DNS as an Access Protocol for Mapping Host Identitity Tags to IP addresses draft-ponomarev-hip-hit2ip-00 Abstract This document proposes a mechanism to access and manage Host Identity Tag (HIT) to IP address mappings using the Domain Name System (DNS). _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Jan 21 06:18:13 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24ED73A6B45; Wed, 21 Jan 2009 06:18:13 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE693A694F for ; Wed, 21 Jan 2009 06:18:11 -0800 (PST) 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 WPfc-GxDzu3H for ; Wed, 21 Jan 2009 06:18:09 -0800 (PST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 2A33D3A6B45 for ; Wed, 21 Jan 2009 06:18:08 -0800 (PST) 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 n0LEHkvC000398; Wed, 21 Jan 2009 15:17:46 +0100 (MET) Received: from zaptop.autonomica.net (zaptop.autonomica.se [192.71.80.71]) by home.liman.net (8.13.8/8.13.8) with ESMTP id n0LEHh6i004904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jan 2009 15:17:44 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id n0LEHsnP022096; Wed, 21 Jan 2009 15:17:54 +0100 (CET) To: "Romascanu\, Dan \(Dan\)" References: From: Lars-Johan Liman Date: Wed, 21 Jan 2009 15:17:53 +0100 In-Reply-To: (Dan Romascanu's message of "Sun\, 18 Jan 2009 12\:58\:19 +0100") Message-ID: <221vuwkajy.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Cc: Cullen Jennings , IETF DNS Directorate Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org dromasca@avaya.com: > Anybody in DNS-DIR looking at this I-D? = I got a ping from =D3lafur to look att it, and I did so yesterday. I sent a bunch of comments off to the side for sanity check, but I haven't heard back, so here are my comments unchecked by any functional brain: I took myself through this document, and I must say that without fundamental knowledge in modern mailology, more specifically sender authentication, it seems like "dancing around the issue but never getting there". There is lots of talk of "certify the owner" and "valitdation of the identity" and stuff, but little explanation of the overall process going from A to B. I would like to see something that starts with "mail going out here" and ends with "and by validating that signature, the authenticity can be established. QED.". I saw two cases of "X MUST/SHOULD be Y; and if X _isn't_ Y, the result is undefined.". To me, that is a recipe for misunderstanding, incompatible implementations, and quarrel about interpretation of the spec. I also cannot wrap my brain around the concept that some third party could "vouch" for e-mail coming out of someones laptop - if it's of a certain type - and what if it isn't? It me took all through to the "Changes" section before I fully realized that sender domain authentication is a strict prerequisite for this, and I still don't fully comprehend the value it would add (although I saw in the IETF tools document tracker that Chris Newman really likes it, so it can't be all bad ... ;-), but never mind, that's not the task at hand. ;-) Looking at the DNS parts of this, a few things caught my eye, and I would at least like to make sure they are lifted up for closer inspection. 1) TXT record. Again! Needs to be fixed, unless they can provide a _REALLY_ good explanation why TXT creates a better overall architecture compared to defining a new record type. (Speed of deployment has very little to do with good architecture in my world, and usually means the opposite.) 2) It seems to make use of DNS "because it's there", rather than because it's the optimal database mechanism for this, but that said, it does fit ... for some not too negative value of "fit". 3) It combines 3 semantically different entities in the lookup domain name. You seem to have a) The sender domain, b) The separator "_vouch", and c) The service locator. While that strikes me as kind of "not how DNS was originally intended to be used", at least the service locator is "to the right" (closer to the root), which means that the client can actually make good use of DNS caching, and they avoid hitting the higher DNS echelons (root, TLD, ...) with subsequent queries. The servers that will be hammered, will be the servers of the "vouching service", which is as it should be. Basically, it's not worse than any DNS based RBL list alreay in use. 4) The DNS language is pretty sloppy, and needs to go through "boot camp with a DNS sergeant". ;-) I note that there is no information about how one goes from "the service locator" to the actual IP address of the vouching service DNS server. It's "a list of domain names of certification providers that the sender asserts will vouch for this particular message." (sect 4.) Aha? And how do I use these "domain names"? Is the service locator to be interpreted as a lookup key for an A record? An AAAA record? An SRV record? (If the latter, what are the other parameters?) Or, do I pass it through a NAPTR to obtain ... what? I would like to see that process described in a more formal way. 5) I notice that the document doesn't mention DNSSEC at all, which may be intentional. It could be that they don't want to force people into using DNSSEC (I can fully respect that), of that this is intended to be an alternative to using DNSSEC, but this really seems like an application where DNSSEC could actually be of some use, and I would at least like to see a discussion section on that. 6) In sec 5, par 9, the authors assert that the choice of the separator label "_vouch" leads to "There will never be any accidental overlap with a valid domain name." That is not only incorrect from a DNS perspective, it is bad terminology, and also a questionable statement, even if you take the language aside. "will never" are strong words, and however unlikely, it is _possible_ that the underscore will be made koscher in host names (which is what they mean) in a distant future. 7) At the end of section 5. we have one of the two "unspeifieds" mentioned above: "If more than one TXT record exists at a name from a VBR record, the reults are unspecified." Why is that? Why not specify "considered it to be an error - ignore it!" or "concatenate them and treat them as one record", or at least something well defined? On the non-DNS side, there are also questions in section 7: "Senders SHOULD use DKIM (and MAY use DomainKeys, SPF, or SenderID)...". That little "and" in the parenthesis - is that "DKIM _and_ any of the following" or is it really "DKIM _or_ any of the following"? (It may be obvious to a native English speaker, but it's not to me. ;-) ... and in 7.1, where it's required that the VBR header lines be put "immediately below the corresponding DKIM-Signature header field". What if you have competing such requirements from other mail sub-protocols? To be frank, since this is a Standards Track document, my view is that it needs some "shaping up". I don't necessarily disapprove of the basic idea, but I want more information to be able to judge better, and I want better DNS language. ... and a different record type than TXT. :-) My assessment is that this exact document isn't ready for publication, but may become so in a future revision, given more and wider review. All text above is subject to the caveat that I may have missed som vital point, due to limited understanding of the e-mail related side of the document. ;-) Cheers, /Liman #---------------------------------------------------------------------- # There are 10 kinds of people in the world. Those who understand # binary numbers, and those who don't. #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail/SIP/Jabber: liman@autonomica.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Autonomica AB, Stockholm ! http://www.autonomica.se/ #---------------------------------------------------------------------- _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 22 04:16:45 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D8528C16F; Thu, 22 Jan 2009 04:16:45 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F62728C165 for ; Thu, 22 Jan 2009 04:16:44 -0800 (PST) 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 VVQaD1qzfd3W for ; Thu, 22 Jan 2009 04:16:43 -0800 (PST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id BBF3028C17B for ; Thu, 22 Jan 2009 04:16:20 -0800 (PST) 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 n0MCFpq6004575; Thu, 22 Jan 2009 13:15:51 +0100 (MET) Received: from zaptop.autonomica.net (host-78-64-7-72.homerun.telia.com [78.64.7.72]) by home.liman.net (8.13.8/8.13.8) with ESMTP id n0MCFnUi002875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 13:15:50 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id n0MCG1qe028002; Thu, 22 Jan 2009 13:16:03 +0100 (CET) To: "Romascanu\, Dan \(Dan\)" References: <221vuwkajy.fsf@zaptop.autonomica.net> From: Lars-Johan Liman Date: Thu, 22 Jan 2009 13:16:01 +0100 In-Reply-To: <221vuwkajy.fsf@zaptop.autonomica.net> (Lars-Johan Liman's message of "Wed\, 21 Jan 2009 15\:17\:53 +0100") Message-ID: <22zlhj4jum.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Cc: Cullen Jennings , "paul.hoffman@domain-assurance.org IETF DNS Directorate" Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hmmm. Lesson learned: people forward your messages outside the intended audience without asking you. I'll be more careful with my formulations in the future. More importantly (and in this case I don't know what to blame: stress, fatigue, the headache I had at the time, or that someone might have added som unsuitable substance to my evening tea?): in my piece about the above draft I wrote: liman@autonomica.se: > 4) The DNS language is pretty sloppy, and needs to go through "boot > camp with a DNS sergeant". ;-) I note that there is no > information about how one goes from "the service locator" to the > actual IP address of the vouching service DNS server. It's "a > list of domain names of certification providers that the sender > asserts will vouch for this particular message." (sect 4.) Aha? > And how do I use these "domain names"? Is the service locator to > be interpreted as a lookup key for an A record? An AAAA record? > An SRV record? (If the latter, what are the other parameters?) > Or, do I pass it through a NAPTR to obtain ... what? I would like > to see that process described in a more formal way. 03.00 AM this morning ("sleepless in Stockholm?") it suddenly struck me: This comment from me is just plain wrong and totally out of place! The domain name in question is part of the normal lookup string, and is treated like any other domain name, for which finding the name servers is a well defined process. I don't know how I managed to even _find_ such a totally wrong end of the stick, but obviously I did and got a sturdy hold of it. Would you all please disregard the comment above. The text in the draft is actually quite OK, for any normal brain which is not as derailed as mine. Paul, my deepest and most sincere apologies for the text above. It is just plain wrong, and just proves your point that I should have contacted you in the process. You would have put me on a better track. With the above insight, my most important remaining technical objection is the use of the TXT record, and there Paul and I have reached the point where we agree do disagree. Cheers, /Liman _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 22 04:25:52 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1B33A6B74; Thu, 22 Jan 2009 04:25:52 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E8328C140 for ; Thu, 22 Jan 2009 04:25:50 -0800 (PST) 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 37idaljVfF4b for ; Thu, 22 Jan 2009 04:25:49 -0800 (PST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 479A73A6B73 for ; Thu, 22 Jan 2009 04:25:49 -0800 (PST) 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 n0MCPVdc011969 for ; Thu, 22 Jan 2009 13:25:31 +0100 (MET) Received: from zaptop.autonomica.net (host-78-64-7-72.homerun.telia.com [78.64.7.72]) by home.liman.net (8.13.8/8.13.8) with ESMTP id n0MCPU6r023379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Jan 2009 13:25:30 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id n0MCPkso028138 for ; Thu, 22 Jan 2009 13:25:46 +0100 (CET) To: IETF DNS Directorate References: <221vuwkajy.fsf@zaptop.autonomica.net> From: Lars-Johan Liman Date: Thu, 22 Jan 2009 13:25:46 +0100 In-Reply-To: <221vuwkajy.fsf@zaptop.autonomica.net> (Lars-Johan Liman's message of "Wed\, 21 Jan 2009 15\:17\:53 +0100") Message-ID: <22ab9j4jed.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Embarrasing ... :-( ... and someone should have told me that the document already _had_ been looked at by dns-dir people. I need to take it slower and be more careful when I do this type of work. Remind me if I forget that in the future. Too much stress, too much fatigue ... :-( /Liman _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 22 05:36:06 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40EB3A6886; Thu, 22 Jan 2009 05:36:06 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C8A3A6886 for ; Thu, 22 Jan 2009 05:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 y+V11lfculQY for ; Thu, 22 Jan 2009 05:36:05 -0800 (PST) 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 DBDE53A685B for ; Thu, 22 Jan 2009 05:36:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,306,1231131600"; d="scan'208";a="158668495" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jan 2009 08:35:47 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jan 2009 08:35:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 14:35:45 +0100 Message-ID: In-Reply-To: <22zlhj4jum.fsf@zaptop.autonomica.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Question about draft-hoffman-dac-vbr Thread-Index: Acl8izJ05H8HhpBNRpusEnkFwLd2+QACmbKA References: <221vuwkajy.fsf@zaptop.autonomica.net> <22zlhj4jum.fsf@zaptop.autonomica.net> From: "Romascanu, Dan (Dan)" To: "Lars-Johan Liman" Cc: Cullen Jennings , Russ Housley , "paul.hoffman@domain-assurance.org IETF DNS Directorate" Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi Liman, Do not take it too tough. People make sometimes errors in good faith and if caught in time no harm happened and we just learn something new. Expect such comments to be forwarded - in most of the cases filtered by one or other of the Area Directors. In this case I had forwarded your comments almost as is, because the document is on the agenda of the IESG telechat one week from today and I wanted the author to have the time to assess your comments and respond back. Regards, Dan > -----Original Message----- > From: Lars-Johan Liman [mailto:liman@autonomica.se] > Sent: Thursday, January 22, 2009 2:16 PM > To: Romascanu, Dan (Dan) > Cc: Cullen Jennings; paul.hoffman@domain-assurance.org IETF > DNS Directorate > Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr > > Hmmm. > > Lesson learned: people forward your messages outside the > intended audience without asking you. I'll be more careful > with my formulations in the future. > > More importantly (and in this case I don't know what to > blame: stress, fatigue, the headache I had at the time, or > that someone might have added som unsuitable substance to my > evening tea?): in my piece about the above draft I wrote: > > liman@autonomica.se: > > 4) The DNS language is pretty sloppy, and needs to go through "boot > > camp with a DNS sergeant". ;-) I note that there is no > > information about how one goes from "the service locator" to the > > actual IP address of the vouching service DNS server. It's "a > > list of domain names of certification providers that the sender > > asserts will vouch for this particular message." (sect 4.) Aha? > > And how do I use these "domain names"? Is the service locator to > > be interpreted as a lookup key for an A record? An AAAA record? > > An SRV record? (If the latter, what are the other parameters?) > > Or, do I pass it through a NAPTR to obtain ... what? I would like > > to see that process described in a more formal way. > > 03.00 AM this morning ("sleepless in Stockholm?") it suddenly struck > me: This comment from me is just plain wrong and totally out of place! > The domain name in question is part of the normal lookup > string, and is treated like any other domain name, for which > finding the name servers is a well defined process. I don't > know how I managed to even _find_ such a totally wrong end of > the stick, but obviously I did and got a sturdy hold of it. > > Would you all please disregard the comment above. The text in > the draft is actually quite OK, for any normal brain which is > not as derailed as mine. > > Paul, my deepest and most sincere apologies for the text > above. It is just plain wrong, and just proves your point > that I should have contacted you in the process. You would > have put me on a better track. > > With the above insight, my most important remaining technical > objection is the use of the TXT record, and there Paul and I > have reached the point where we agree do disagree. > > Cheers, > /Liman > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 22 10:08:57 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329F328C25A; Thu, 22 Jan 2009 10:08:57 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEB728C256 for ; Thu, 22 Jan 2009 10:08:56 -0800 (PST) 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 poXuxEDOzyk7 for ; Thu, 22 Jan 2009 10:08:56 -0800 (PST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id A612B28C25A for ; Thu, 22 Jan 2009 10:08:55 -0800 (PST) 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 n0MI8Aaf028294; Thu, 22 Jan 2009 19:08:10 +0100 (MET) Received: from zaptop.autonomica.net (host-90-235-37-119.mobileonline.telia.com [90.235.37.119]) by home.liman.net (8.13.8/8.13.8) with ESMTP id n0MI85o5023275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 19:08:08 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id n0MI88hc000406; Thu, 22 Jan 2009 19:08:12 +0100 (CET) To: "Romascanu\, Dan \(Dan\)" References: <221vuwkajy.fsf@zaptop.autonomica.net> <22zlhj4jum.fsf@zaptop.autonomica.net> From: Lars-Johan Liman Date: Thu, 22 Jan 2009 19:08:08 +0100 In-Reply-To: (Dan Romascanu's message of "Thu\, 22 Jan 2009 14\:35\:45 +0100") Message-ID: <22bptz1aev.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Cc: Cullen Jennings , Russ Housley , "paul.hoffman@domain-assurance.org IETF DNS Directorate" Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi! dromasca@avaya.com: > Hi Liman, > Do not take it too tough. People make sometimes errors in good faith and > if caught in time no harm happened and we just learn something new. It is also a depressing lesson on how my perception is affected by factors like lack of sleep and stress. Maybe the impact wasn't disastrous from a process standpoint, but I've created a lot of extra work - especially for Paul and friends, but also for others (you included) - and also a lot of emotional distress. It's nothing to be proud of. It amazingly hard to adhere to the old rule that the old "postmaster" at the Royal Institute of Technology tried to teach me: Never write e-mail when you're in a state of affect ... (or whatever the appropriate translation is). > Expect such comments to be forwarded - in most of the cases filtered by > one or other of the Area Directors. In this case I had forwarded your > comments almost as is, because the document is on the agenda of the IESG > telechat one week from today and I wanted the author to have the time to > assess your comments and respond back. Yes, I understand that, and I believe the time pressure was one of the key factors. I should have realized that ... :-( Well, well ... Regards, /Liman _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 22 11:30:22 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EB728C0FC; Thu, 22 Jan 2009 11:30:22 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5BA3A6A86 for ; Thu, 22 Jan 2009 11:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 ZASGAMtRbpHh for ; Thu, 22 Jan 2009 11:30:20 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DA1AC3A6960 for ; Thu, 22 Jan 2009 11:30:19 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0MJU1vA047333 for ; Thu, 22 Jan 2009 14:30:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 22 Jan 2009 14:30:01 -0500 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090122_193001_012212.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-roll-protocols-survey-04.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: , 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 Count: 11 Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational A. Tavakoli Expires: July 24, 2009 S. Dawson-Haggerty UC Berkeley January 20, 2009 Overview of Existing Routing Protocols for Low Power and Lossy Networks draft-ietf-roll-protocols-survey-04 Abstract Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks has novel requirements that existing protocols may not address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. From this survey it examines whether existing and mature IETF protocols can be used without modification in these networks, or whether further work is necessary. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Mon Jan 26 10:50:33 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E833A69CD; Mon, 26 Jan 2009 10:50:33 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE7C3A69CD for ; Mon, 26 Jan 2009 10:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.617, 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 C2+GdXnJKjky for ; Mon, 26 Jan 2009 10:50:31 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 0AC283A6996 for ; Mon, 26 Jan 2009 10:50:31 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LRWXE-00074z-5k; Mon, 26 Jan 2009 19:50:12 +0100 Received: from localhost by x27.adm.denic.de with local id 1LRWUd-0005o9-Mz; Mon, 26 Jan 2009 19:47:31 +0100 Date: Mon, 26 Jan 2009 19:47:31 +0100 From: Peter Koch To: dns-dir@ietf.org Message-ID: <20090126184731.GF29109@x27.adm.denic.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [dns-dir] DNS Directorate Conf Call? 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, our next conf call is scheduled for the upcoming Monday, 2nd February, 1500 UTC. We have had a few discussions on the list and some open reviews. However, I know that a couple of us will be at the Global DNS Risk Symposium in Atlanta next week and likely unavailable for the call. Pending express needs of our ADs I'd like to suggest we skip the call and schedule one definitely on 2nd March, just before the IETF. Please let me know whether that's OK or whether we should try to draft an agenda for next week still. Best regards, Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 29 11:20:33 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11D03A682B; Thu, 29 Jan 2009 11:20:33 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9B93A682B for ; Thu, 29 Jan 2009 11:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 iMehq+qBgRMi for ; Thu, 29 Jan 2009 11:20:31 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9248C3A67AC for ; Thu, 29 Jan 2009 11:20:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,346,1231131600"; d="scan'208";a="135546769" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Jan 2009 14:20:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Jan 2009 14:20:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jan 2009 20:19:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-hoffman-dac-vbr thread-index: AcmCRI8HzaQ0h6joQbiSq4uF1fnLMAAAJ4Tw From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: DISCUSS: draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Liman, DNS-DIR, I am holding a DISCUSS on the issues related to draft-hoffman-dac-vbr. Can you please asses whether your review comments were addressed, and what critical items - if any - were left out in Paul's response? Thanks and Regards, Dan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@domain-assurance.org] Sent: Thursday, January 29, 2009 9:05 PM To: Romascanu, Dan (Dan); iesg@ietf.org Cc: arvel.hathcock@altn.com; john.levine@domain-assurance.org Subject: RE: DISCUSS: draft-hoffman-dac-vbr At 7:50 PM +0100 1/29/09, Romascanu, Dan (Dan) wrote: >There has been quite a lot of traffic on this. Can you send again the >response that you consider being the 'official' answer (may be more >than >one) so that we make sure the DNS-DIR has seen it? > To: Russ Housley From: Paul Hoffman Subject: Re: FW: [dns-dir] Question about draft-hoffman-dac-vbr Cc: John Levine , Arvel Hathcock Bcc: X-Attachments: >Please generate a response to this review. Done. This is approved by both my co-authors as well. You may pass it to the IESG. I also spoke with Liman and we have agreed to disagree on the TXT record issue. He did not know why the DNS-DIR review was not requested earlier, nor why Peter Koch did not bring it to the DNS-DIR when we spoke with him probably a year ago about the document. ===================================================================== >I took myself through this document, and I must say that without fundamental knowledge in modern mailology, more specifically sender authentication, it seems like "dancing around the issue but never getting there". There is lots of talk of "certify the owner" and "valitdation of the identity" and stuff, but little explanation of the overall process going from A to B. I would like to see something that starts with "mail going out here" and ends with "and by validating that signature, the authenticity can be established. QED.". The document purposely doesn't do that because different mail systems will do the certification at different times. For example, some mail systems would do this between the time a message is received and when it is put in the user's mail store; others would do it when reading the file from the mail store but before displaying it to the user. The timing truly doesn't matter to the protocol: what matters is that it is done using the steps given in the document. We carefully designed VBR so it can be used in conjunction with any of the widely used domain authentication schemes, so it can be applied at or after the time the authentication scheme is evaluated. Note that VBR does not provide authentication; that is the job of the underlying authentication scheme. It provides certification, which is a different thing. >I saw two cases of "X MUST/SHOULD be Y; and if X _isn't_ Y, the result is undefined.". To me, that is a recipe for misunderstanding, incompatible implementations, and quarrel about interpretation of the spec. These are both good catches. The first says this: All of the VBR-Info header fields in a single message MUST have identical mc= values. The semantics of a message with non-identical mc= categories are undefined. We agree that this could lead to incompatible implementations. The last sentence can be dropped. The second says this: If more than one TXT record exists at a name from a VBR record, the results are unspecified. We agree that this could lead to incompatible implementations. The sentence can be changed to: The VBR record MUST have only one TXT record. >I also cannot wrap my brain around the concept that some third party >could "vouch" for e-mail coming out of someones laptop - if it's of a >certain type - and what if it isn't? It me took all through to the >"Changes" section before I fully realized that sender domain >authentication is a strict prerequisite for this, and I still don't >fully comprehend the value it would add (although I saw in the IETF >tools document tracker that Chris Newman really likes it, so it can't >be all bad ... ;-), but never mind, that's not the task at hand. ;-) Vouching services will have different business models for how they assure people that their vouching is worthwhile. That is definitely out of scope for this document. Some models are like the ones we see today with Return Path and Constant Contact; others will spring up, such as trade groups vouching for their members. Another example might be that the bank regulator in a country (such as the FDIC in the US) might choose to vouch for the banks that it oversees. We do not expect that every email user will want to use one or more vouching services, just that, if they do, there should be a single interoperable protocol. >Looking at the DNS parts of this, a few things caught my eye, and I would at least like to make sure they are lifted up for closer inspection. > >1) TXT record. Again! Needs to be fixed, unless they can provide a > _REALLY_ good explanation why TXT creates a better overall > architecture compared to defining a new record type. (Speed of > deployment has very little to do with good architecture in my > world, and usually means the opposite.) We have been through this many times. The use case here is exactly the same as for DKIM. The underscore used on the _vouch label prevents there from being any possibility of collision with TXT records for actual domain names. The paragraph near the end of section 5 ("Verifiers MUST then check...") deals with the issue of wildcards and TXT records. >2) It seems to make use of DNS "because it's there", rather than > because it's the optimal database mechanism for this, but that > said, it does fit ... for some not too negative value of "fit". We don't understand this objection at all. As stated throughout the document, VBR is for vouching for mail from a *domain name*. The lookups are based on a domain name, and the responses are small single replies. DNS seems like a perfect fit for that. >3) It combines 3 semantically different entities in the lookup domain > name. You seem to have > > a) The sender domain, > b) The separator "_vouch", and > c) The service locator. > > While that strikes me as kind of "not how DNS was originally > intended to be used", at least the service locator is "to the > right" (closer to the root), which means that the client can > actually make good use of DNS caching, and they avoid hitting the > higher DNS echelons (root, TLD, ...) with subsequent queries. The > servers that will be hammered, will be the servers of the "vouching > service", which is as it should be. Basically, it's not worse than > any DNS based RBL list alreay in use. We designed VBR the way we did because we knew that similar designs had acceptable DNS characteristics. There is no "service locator": there's just the domain name of the vouching service. >4) The DNS language is pretty sloppy, and needs to go through "boot > camp with a DNS sergeant". ;-) We asked for such input during the development of the document, and we heard no comments from the sergeants who said they would review it other than a disagreement about TXT records. >I note that there is no information > about how one goes from "the service locator" to the actual IP > address of the vouching service DNS server. It's "a list of domain > names of certification providers that the sender asserts will vouch > for this particular message." (sect 4.) Aha? And how do I use these > "domain names"? Is the service locator to be interpreted as a > lookup key for an A record? An AAAA record? An SRV record? (If the > latter, what are the other parameters?) Or, do I pass it through a > NAPTR to obtain ... what? I would like to see that process > described in a more formal way. The document says that the string queried is a domain name, and that the domain name is queried for a TXT record. If it would help, we can add "The recipient looks up the domain name in the DNS in the exact same manner it looks up all other domain names." The protocol is agnostic to whether A or AAAA records are returned. >From his comment, we think that Liman maybe supposed that there had to be some way to auto-discover vouching services. There is deliberately no intention that vouching services can be found automatically. VBR is about reputation, and the mail system's management has to decide for itself what vouching service(s) it wants to use. One uses a vouching service that one trusts, not just "one that is there". >5) I notice that the document doesn't mention DNSSEC at all, which may > be intentional. It could be that they don't want to force people > into using DNSSEC (I can fully respect that), of that this is > intended to be an alternative to using DNSSEC, but this really > seems like an application where DNSSEC could actually be of some > use, and I would at least like to see a discussion section on that. The protocol is agnostic to DNSSEC. There is no more reason to force a user to use DNSSEC for this protocol than for any other protocol. DNSSEC would indeed be of some use, just as it would be for any other protocol. >6) In sec 5, par 9, the authors assert that the choice of the > separator label "_vouch" leads to "There will never be any > accidental overlap with a valid domain name." That is not only > incorrect from a DNS perspective, it is bad terminology, and also a > questionable statement, even if you take the language aside. "will > never" are strong words, and however unlikely, it is _possible_ > that the underscore will be made koscher in host names (which is > what they mean) in a distant future. We can change "valid domain name" to "currently-valid domain name" or "host names". _vouch is indeed a valid domain name, which is why we use it in the DNS. >7) At the end of section 5. we have one of the two "unspeifieds" > mentioned above: "If more than one TXT record exists at a name from > a VBR record, the reults are unspecified." Why is that? Why not > specify "considered it to be an error - ignore it!" or "concatenate > them and treat them as one record", or at least something well > defined? Agree; see above. >On the non-DNS side, there are also questions in section 7: "Senders >SHOULD use DKIM (and MAY use DomainKeys, SPF, or SenderID)...". That >little "and" in the parenthesis - is that "DKIM _and_ any of the >following" or is it really "DKIM _or_ any of the following"? (It may be >obvious to a native English speaker, but it's not to me. ;-) We truly meant "and". >... and in 7.1, where it's required that the VBR header lines be put "immediately below the corresponding DKIM-Signature header field". What if you have competing such requirements from other mail sub-protocols? It is not required, it is recommended. The exact words are: o The VBR-Info header field SHOULD be added in the header immediately below the corresponding DKIM-Signature header field. >To be frank, since this is a Standards Track document, my view is that it needs some "shaping up". I don't necessarily disapprove of the basic idea, but I want more information to be able to judge better, and I want better DNS language. We hope the changes and explanations above cover all the issues. >... and a different record type than TXT. :-) We see no difference between the use in VBR and other standards-track documents. We looked at the objections to re-use of TXT carefully and found that none of them apply to VBR, given the way we purposely designed the protocol. >My assessment is that this exact document isn't ready for publication, but may become so in a future revision, given more and wider review. This document was informally reviewed by a WG (DKIM), by a group of vendors with a great deal of technical knowledge (the Domain Assurance Council), and went through a four-week IETF Last Call that generated review. We are not sure what more we could have asked. --Paul Hoffman, Director --Domain Assurance Council _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 29 11:40:45 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FD028C0E0; Thu, 29 Jan 2009 11:40:45 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639DD3A6939 for ; Thu, 29 Jan 2009 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.794, 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 qEMORQHpEsaO for ; Thu, 29 Jan 2009 11:40:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9CB3F3A683D for ; Thu, 29 Jan 2009 11:40:42 -0800 (PST) Received: from crankycanuck.ca (CPE00212980eb9c-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.217.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EC45A2FEA3D8 for ; Thu, 29 Jan 2009 19:40:21 +0000 (UTC) Date: Thu, 29 Jan 2009 14:40:20 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090129194020.GK38339@shinkuro.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] FW: DISCUSS: draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Hi, On Thu, Jan 29, 2009 at 08:19:52PM +0100, Romascanu, Dan (Dan) wrote: > > The second says this: > > If more than one TXT record exists at a name from a VBR record, the > results are unspecified. > > We agree that this could lead to incompatible implementations. The > sentence can be changed to: > > The VBR record MUST have only one TXT record. The above gets exactly to the reasons why some of us are uneasy with TXT records: I have no idea how to enforce the above rule in any zone, and there's nothing about TXT records that can ensure there'll be only one such TXT record. So what happens if there is more than one TXT record? The results are still unspecified; the document just doesn't say so any more. That said, > We have been through this many times. The use case here is exactly the > same as for DKIM. The underscore used on the _vouch label prevents there > from being any possibility of collision with TXT records for actual > domain names. The paragraph near the end of section 5 ("Verifiers MUST > then check...") deals with the issue of wildcards and TXT records. we've already given in on the brain-dead approach of using TXT records for DKIM. So I guess we're stuck with it here. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Jan 29 11:46:45 2009 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3E43A683D; Thu, 29 Jan 2009 11:46:45 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CDC3A680B for ; Thu, 29 Jan 2009 11:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=4.175, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3WY0rXbH6uz for ; Thu, 29 Jan 2009 11:46:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7E0483A6832 for ; Thu, 29 Jan 2009 11:46:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,346,1231113600"; d="sig'?scan'208";a="32339819" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2009 19:46:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0TJkNMZ020525; Thu, 29 Jan 2009 20:46:23 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0TJkNn0022930; Thu, 29 Jan 2009 19:46:23 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 20:46:23 +0100 Received: from [192.168.1.17] ([10.61.92.60]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 20:46:23 +0100 Message-Id: <939702A3-78B1-4A6F-8DE2-39ACA4A2A67E@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Andrew Sullivan In-Reply-To: <20090129194020.GK38339@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 29 Jan 2009 20:46:22 +0100 References: <20090129194020.GK38339@shinkuro.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Jan 2009 19:46:23.0415 (UTC) FILETIME=[43D76470:01C9824A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1999; t=1233258383; x=1234122383; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dns-dir]=20FW=3A=20DISCUSS=3A=20draft- hoffman-dac-vbr |Sender:=20; bh=Jta3lzoH8n5JD9Qf4E2HE+oNKf2jvRkIX9hdw6aXMVg=; b=Lmo4EzTB4MlvnBacaLZRabqgAe5MaakhA+k5cVMe4arDlBpZOA6y3ANzoi aqvv+xEl2s1skDndqOlktdZOh7ZX8kT9p+5reYmjmel93giLA7qVOAGChDSZ 2frFpFxuuP; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: dns-dir@ietf.org Subject: Re: [dns-dir] FW: DISCUSS: draft-hoffman-dac-vbr X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0330466665==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0330466665== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-79--599371855" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-79--599371855 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 29 jan 2009, at 20.40, Andrew Sullivan wrote: >> The VBR record MUST have only one TXT record. > > The above gets exactly to the reasons why some of us are uneasy with > TXT records: I have no idea how to enforce the above rule in any zone, > and there's nothing about TXT records that can ensure there'll be only > one such TXT record. So what happens if there is more than one TXT > record? The results are still unspecified; the document just doesn't > say so any more. That said, > >> We have been through this many times. The use case here is exactly >> the >> same as for DKIM. The underscore used on the _vouch label prevents >> there >> from being any possibility of collision with TXT records for actual >> domain names. The paragraph near the end of section 5 ("Verifiers >> MUST >> then check...") deals with the issue of wildcards and TXT records. > > we've already given in on the brain-dead approach of using TXT records > for DKIM. So I guess we're stuck with it here. I am not happy either, as people know, with the prefix-related TXT records. One day you have a TXT record that by definition MUST have the same owner as another RR. And if that RR is also of type TXT, then you have a problem. Two TXT with same owner. Patrik P.S. I see movement on the IAB draft on TXT records... --Apple-Mail-79--599371855 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJggeOvHlR2X0luNwRAqgKAJ0Uti7iUWJZOy+VwUkgZH+aiLR3cACglMRz U7iBLwEx4QoeLr8xk1ZYkLw= =ctiG -----END PGP SIGNATURE----- --Apple-Mail-79--599371855-- --===============0330466665== 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 --===============0330466665==--