From dromasca@avaya.com Mon Jan 3 09:38:15 2011 Return-Path: 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 5EE263A69BE; Mon, 3 Jan 2011 09:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 PlS+riidTsld; Mon, 3 Jan 2011 09:38:12 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E113E3A69BA; Mon, 3 Jan 2011 09:37:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEqYIU2HCzI1/2dsb2JhbACkNHOlFwKWUYVKBI47 X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="257785447" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jan 2011 12:40:05 -0500 X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="576242021" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jan 2011 12:40:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2011 18:39:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 6, 2011 IESG Teleconference Thread-Index: Acuod8MjL0F3J88wRM6ifhfUcvMqaQC9SukQ From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the January 6, 2011 IESG Teleconference 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: , X-List-Received-Date: Mon, 03 Jan 2011 17:38:15 -0000 Please find below the preliminary agenda of the 1/6 telechat. Please send me your questions, comments and concerns before 1/5 COB.=20 Thanks and Regards, Dan 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-pkix-ocspagility-09 OCSP Algorithm Agility (Proposed Standard) Note: Stephen Kent is the document shepherd Token: Tim Polk o draft-ietf-httpstate-cookie-20 HTTP State Management Mechanism (Proposed Standard) Note: Jeff Hodges (chair of the HTTPSTATE WG) is the document shepherd. Token: Peter Saint-Andre Was deferred by Tim Polk on 2010-12-15 o draft-ietf-pim-group-rp-mapping-08 PIM Group-to-RP Mapping (Proposed Standard) Note: Mike McBride is the document shepherd (mmcbride@cisco.com). Token: Adrian Farrel o draft-ietf-roll-trickle-06 The Trickle Algorithm (Proposed Standard) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel Was deferred by Lars Eggert on 2010-12-16 o draft-ietf-pwe3-oam-msg-map-14 Pseudowire (PW) OAM Message Mapping (Proposed Standard) Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd. Token: Stewart Bryant o draft-ietf-avt-rtcp-port-for-ssm-04 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions (Proposed Standard) Note: The document shepherd for this document is Keith Drage (keith.drage@alcatel-lucent.com). Token: Robert Sparks o draft-ietf-avt-rtp-cnames-03 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (Proposed Standard) Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd. Token: Robert Sparks o draft-ietf-dnsext-5395bis-02 Domain Name System (DNS) IANA Considerations (BCP) Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-avt-srtp-big-aes-05 The use of AES-192 and AES-256 in Secure RTP (Proposed Standard) Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-mpls-ldp-upstream-09 MPLS Upstream Label Assignment for LDP (Proposed Standard) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel 2.2 Individual Submissions 2.2.1 New Items o draft-cdmi-mediatypes-06 Cloud Data Management Interface (CDMI) Media Types (Proposed Standard) Token: Peter Saint-Andre o draft-melnikov-mailserver-uri-to-historic-00 Moving mailserver: URI scheme to historic (Proposed Standard) Token: Peter Saint-Andre o draft-kucherawy-authres-vbr-01 Authentication-Results Registration For Vouch By Reference Results (Proposed Standard) Note: Barry Leiba is the document shepherd. Token: Alexey Melnikov 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-sieve-autoreply-03 Sieve Email Filtering: Use of Presence Information with Auto Responder functionality (Informational) Note: The Document Shepherd is Cyrus Daboo. Token: Peter Saint-Andre o draft-ietf-ecrit-lost-servicelistboundary-05 LoST Service List Boundary Extension (Experimental) Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd. Token: Robert Sparks o draft-ietf-ipfix-anon-05 IP Flow Anonymisation Support (Experimental) Note: Nevil Brownlee is the Document Shepherd Token: Dan Romascanu Was deferred by Tim Polk on 2010-12-15 o draft-ietf-v6ops-tunnel-security-concerns-04 Security Concerns With IP Tunneling (Informational) Note: Joel Jaeggli (joelja@bogus.com) v6ops wg cochair is the document shepherd. Token: Ron Bonica o draft-ietf-roll-security-framework-03 A Security Framework for Routing over Low Power and Lossy Networks (Informational) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-v6ops-tunnel-loops-01 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (Informational) Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd. Token: Ron Bonica 3.1.2 Returning Items o draft-ietf-l2vpn-vpls-bridge-interop-06 VPLS Interoperability with CE Bridges (Informational) Note: Shane Amante is the document shepherd. Token: Stewart Bryant o draft-ietf-mpls-tp-oam-framework-10 Operations, Administration and Maintenance Framework for MPLS- based Transport Networks (Informational) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-mpls-tp-uni-nni-02 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (Informational) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-loreto-http-bidirectional-05 Known issues and best practices for the Use of Long Polling and Streaming in Bidirectional HTTP (Informational) Note: Martin Thomson is the document shepherd. Token: Alexey Melnikov o draft-turner-md5-seccon-update-08 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (Informational) Note: Sean Turner (turners@ieca.com) is the document shepherd. Token: Alexey Melnikov o draft-turner-md2-to-historic-10 MD2 to Historic Status (Informational) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Robert Sparks o draft-turner-md4-to-historic-10 MD4 to Historic Status (Informational) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Robert Sparks 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items o draft-zorn-radius-keywrap-17 Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational) Token: Dan Romascanu o draft-irtf-mobopts-mpa-framework-08 A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization (Informational) Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd. Token: Jari Arkko o draft-templin-iron-16 The Internet Routing Overlay Network (IRON) (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Audio/Video Transport Payloads (payload) Token: Robert o Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Token: Robert o Audio/Video Transport Core Maintenence (avtcore) Token: Robert o Audio/Video Transport Extensions (avtext) Token: Robert 4.1.2 Proposed for Approval o ControLling mUltiple streams for TElepresence (clue) Token: Gonzalo From ogud@ogud.com Sun Jan 9 11:37:54 2011 Return-Path: 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 1937B3A6830 for ; Sun, 9 Jan 2011 11:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QFBSSFGRC3Ce for ; Sun, 9 Jan 2011 11:37:53 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 316DD3A6806 for ; Sun, 9 Jan 2011 11:37:49 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p09Je0TV019304 for ; Sun, 9 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sun, 9 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110109_194000_085789.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-watson-cdni-use-cases-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: , X-List-Received-Date: Sun, 09 Jan 2011 19:37:54 -0000 Count: 19 Network Working Group G. Watson Internet-Draft BT Intended status: Experimental January 6, 2011 Expires: July 10, 2011 CDN Interconnect Use Cases draft-watson-cdni-use-cases-00 Abstract [draft-jenkins-cdni-problem-statement] outlines the problem space for CDN Interconnection within the IETF. This documents provides a complimentary set of technical use cases for how CDNs may be interconnected. The goal of this document is to outline real world use-cases for CDN Interconnect, for the IETF, with the intention of supporting the case for formation of a Working Group which would work on the definition of standardised, interoperable methods of Interconnecting CDNs. The goal of this document is NOT to define the technical solutions to be used. The intent of this document is to outline a set of technical use cases. While the technical use cases may be influenced by business- related and other non-technical factors, this document does not attempt to detail any non-technical aspects of CDN Interconnect. From dromasca@avaya.com Wed Jan 12 03:18:45 2011 Return-Path: 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 324F23A6A63; Wed, 12 Jan 2011 03:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bZfALfZr-3Px; Wed, 12 Jan 2011 03:18:44 -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 2E3723A6B0E; Wed, 12 Jan 2011 03:18:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIcLU2HCzI1/2dsb2JhbACkPnOlZAKWWoVMBI5K X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="227147833" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jan 2011 06:21:00 -0500 X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="581297989" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2011 06:20:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 12:20:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Audio/Video Transport Core Maintenence (avtcore) Thread-Index: Acuxv6ms2XE4wpE0RtuZJW5oP96tuAAirCZg From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: WG Review: Audio/Video Transport Core Maintenence (avtcore) 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: , X-List-Received-Date: Wed, 12 Jan 2011 11:18:45 -0000 This is the first in a series of four messages announcing the review for four IETF Working Groups. Note that these WGs are not completely new, but rather the split of the current AVT (Audio/Video Transport) WG in the RAI Area.=20 Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, January 11, 2011 8:43 PM To: new-work@ietf.org Subject: WG Review: Audio/Video Transport Core Maintenence (avtcore)=20 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 Audio/Video Transport Core Maintenence (avtcore) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity.=20 The AVTCORE working group is chartered to maintain the core RTP/RTCP protocols and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Dec 2010 Submit Guideline for Choosing RTCP CNAME as Proposed Standard Dec 2010 Submit use of AES-192 and AES-256 in Secure RTP for Proposed=20 Standard Dec 2010 Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Dec 2010 Submit Real-Time Transport Control Protocol (RTCP) in Overlay=20 Multicast for Proposed Standard Feb 2011 Submit Monitoring Architecture for RTP for Informational Feb 2011 Guidelines for the use of Variable Bit Rate Audio with Secure=20 RTP as informational (or possibly BCP) Apr 2011 Submit in band keying mechanism for SRTP draft for Proposed=20 Standard Apr 2011 Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 RTCP indication for retransmission suppression as proposed=20 standard Sep 2011 Encryption of Header Extensions in the Secure Real-Time=20 Transport Protocol (SRTP) for Proposed Standard From dromasca@avaya.com Wed Jan 12 03:18:46 2011 Return-Path: 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 61C403A6B23; Wed, 12 Jan 2011 03:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vEzSWRMZVjgw; Wed, 12 Jan 2011 03:18:45 -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 7ABEB3A6A5F; Wed, 12 Jan 2011 03:18:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIcLU2HCzI1/2dsb2JhbACkPnOlZAKWWoVMBI5K X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="227147835" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jan 2011 06:21:01 -0500 X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="581297995" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2011 06:21:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 12:20:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Audio/Video Transport Extensions (avtext) Thread-Index: AcuxwBfjEEYDB454S2WKDtnt5TSVfgAiq0JA From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: WG Review: Audio/Video Transport Extensions (avtext) 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: , X-List-Received-Date: Wed, 12 Jan 2011 11:18:46 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, January 11, 2011 8:46 PM To: new-work@ietf.org Subject: WG Review: Audio/Video Transport Extensions (avtext)=20 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 Audio/Video Transport Extensions (avtext) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group.=20 The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Dec 2010 Submit Considerations for RAMS Scenarios for Informational Oct 2011 Submit RTP Header extension for mixer to client audio level=20 indication as Proposed Standard Oct 2011 Submit RTP Header extension for client to mixer audio level=20 indication as proposed standard Dec 2011 Submit Support for multiple clock rates in an RTP session for=20 Proposed Standard Dec 2011 Submit SRTP Store-and-Forward Use Cases and Requirements for=20 Informational Dec 2011 Submit Use of the Secure Real-time Transport Protocol (SRTP)=20 in Store-and-Forward Applications for Proposed Standard From dromasca@avaya.com Wed Jan 12 03:19:16 2011 Return-Path: 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 8A6893A6B10; Wed, 12 Jan 2011 03:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fyLlbU-iGLgW; Wed, 12 Jan 2011 03:19:15 -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 B58BA3A6B0E; Wed, 12 Jan 2011 03:19:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIcLU3GmAcF/2dsb2JhbACkPnOlZAKWWoVMBI5K X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="227147908" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jan 2011 06:21:32 -0500 X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="569398335" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jan 2011 06:21:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 12:21:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Audio/Video Transport Payloads (payload) Thread-Index: AcuxvqEkRbDU/1H+SyGAlUpKw3fDjAAjCv6A From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: WG Review: Audio/Video Transport Payloads (payload) 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: , X-List-Received-Date: Wed, 12 Jan 2011 11:19:16 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, January 11, 2011 8:35 PM To: new-work@ietf.org Subject: WG Review: Audio/Video Transport Payloads (payload)=20 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 Audio/Video Transport Payloads (payload) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format"=20 (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Dec 2010 Submit RTP Payload Format for MIDI for Proposed Standard Feb 2011 Submit How to Write an RTP Payload Format for Informational Feb 2011 Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for=20 Proposed Standard Mar 2011 Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Mar 2011 Submit RTP Payload Format for Enhanced Variable Rate=20 Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Mar 2011 Submit RTP Payload Format for Bluetooth's SBC audio codec for=20 Proposed Standard Apr 2011 Submit RTP Payload Format for MPEG2-TS preamble for Proposed=20 Standard Apr 2011 Submit RTP Payload Format for DV (IEC 61834) Video for=20 Proposed Standard Apr 2011 Submit RTP Payload Format for the iSAC codec for Proposed=20 Standard Apr 2011 Submit RTP profile for the carriage of SMPTE 336M data for=20 Proposed Standard Jun 2011 Submit RTP Payload Format for MVC Video for Proposed Standard From dromasca@avaya.com Wed Jan 12 03:19:46 2011 Return-Path: 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 7ECBD3A6A5F; Wed, 12 Jan 2011 03:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xlU-Yba7idgo; Wed, 12 Jan 2011 03:19:45 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0297C3A6B10; Wed, 12 Jan 2011 03:19:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIcLU3GmAcF/2dsb2JhbACkPnOlZAKWWoJ1glcEjko X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="259211509" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jan 2011 06:22:04 -0500 X-IronPort-AV: E=Sophos;i="4.60,312,1291611600"; d="scan'208";a="569398468" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jan 2011 06:22:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 12:21:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Thread-Index: AcuxvwtCiKy7IsiIT8e4vKMgHPx5pgAi9zuw From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Wed, 12 Jan 2011 11:19:46 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, January 11, 2011 8:38 PM To: new-work@ietf.org Subject: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock)=20 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 Metric Blocks for use with RTCP's Extended Report Framework (xrblock) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new metrics. The group will follow the guidelines established in RFC5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the RTPCORE working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric=20 Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric=20 Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric=20 Reporting Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric=20 Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric=20 Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of=20 Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting =20 From dromasca@avaya.com Wed Jan 12 06:55:41 2011 Return-Path: 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 923F228C126; Wed, 12 Jan 2011 06:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NgVGMetBMe5O; Wed, 12 Jan 2011 06:55:40 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0F17928C108; Wed, 12 Jan 2011 06:55:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIJQLU2HCzI1/2dsb2JhbACkPnOlcQKWMYVMBI5K X-IronPort-AV: E=Sophos;i="4.60,313,1291611600"; d="scan'208";a="259245157" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jan 2011 09:57:58 -0500 X-IronPort-AV: E=Sophos;i="4.60,313,1291611600"; d="scan'208";a="581402771" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2011 09:57:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2011 15:57:51 +0100 Message-ID: In-Reply-To: <824DCB12-4FC5-4573-A698-4887CD5D1785@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: WG Review: Audio/Video Transport Core Maintenence (avtcore) Thread-Index: AcuyYCkgdJJjgJY4QlaPzPohsstWvAACG2CQ References: <824DCB12-4FC5-4573-A698-4887CD5D1785@americafree.tv> From: "Romascanu, Dan (Dan)" To: "Marshall Eubanks" Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Audio/Video Transport Core Maintenence (avtcore) 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: , X-List-Received-Date: Wed, 12 Jan 2011 14:55:41 -0000 Marshall, Addressing all these questions seems to me valid - as the IESG will need to make a decision at the next telechat and input is appreciated. You may also want to read into the archives of AVT for the discussions that led to the proposal to split the WG - as some of these questions may have already been addressed and discussed. =20 Dan =20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: Wednesday, January 12, 2011 3:54 PM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; IETF DNS Directorate;=20 > aaa-doctors@ietf.org; mib-doctors@ietf.org; YANG Doctors > Subject: Re: [OPS-DIR] FW: WG Review: Audio/Video Transport=20 > Core Maintenence (avtcore) >=20 >=20 > On Jan 12, 2011, at 6:20 AM, Romascanu, Dan (Dan) wrote: >=20 > > This is the first in a series of four messages announcing=20 > the review=20 > > for four IETF Working Groups. Note that these WGs are not=20 > completely=20 > > new, but rather the split of the current AVT (Audio/Video=20 > Transport)=20 > > WG in the RAI Area. >=20 > Dear Dan; >=20 > In this case, what exactly is being reviewed : >=20 > The desirability of splitting AVT ? >=20 > The fault lines along which the split is being done ? >=20 > The detailed charters of each new group & the energy=20 > available to do each of the pieces ? >=20 > In particular, 3 of the 4 seem like a fairly routine split of=20 > AVT, while the fourth (XRBLOCK) seems like new work, and so=20 > it seems to me should be evaluated differently. >=20 > Regards > Marshall >=20 >=20 > >=20 > > Dan > >=20 > >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]=20 > On Behalf=20 > > Of IESG Secretary > > Sent: Tuesday, January 11, 2011 8:43 PM > > To: new-work@ietf.org > > Subject: WG Review: Audio/Video Transport Core Maintenence (avtcore) > >=20 > > A new IETF working group has been proposed in the Real-Time=20 > > Applications and Infrastructure Area. The IESG has not made any=20 > > determination as yet. > > The following draft charter was submitted, and is provided for=20 > > informational purposes only. Please send your comments to the IESG=20 > > mailing > > list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 > >=20 > > Audio/Video Transport Core Maintenence (avtcore) > > ------------------------------------------- > > Current Status: Proposed Working Group Last modified: 2010-12-03 > >=20 > > Chairs: TBD > >=20 > > Real-Time Applications and Infrastructure Area Directors: > > Gonzalo Camarillo Robert Sparks=20 > > > >=20 > > Real-Time Applications and Infrastructure Area Advisor: > > Robert Sparks > >=20 > > Mailing Lists: TBD > >=20 > > Description of Working Group: > >=20 > > The Real-time Transport Protocol, RTP, along with its associated=20 > > profiles and payload formats provides for real-time transmission of=20 > > audio and video over unicast and multicast transports. RTP=20 > itself has=20 > > been shepherded to Full Standard. Its associated profiles,=20 > extensions,=20 > > and payload formats are currently at various levels of standards=20 > > maturity. > >=20 > > The AVTCORE working group is chartered to maintain the core=20 > RTP/RTCP=20 > > protocols and the AVP, SAVP, AVPF, and SAVPF profiles. The=20 > group will=20 > > provide architectural guidance for extending the protocols and=20 > > guidelines for their proper use. While other working groups may be=20 > > chartered to work on application-specific extensions to the=20 > protocols,=20 > > extensions that are generally applicable will be developed=20 > in AVTCORE. > >=20 > > The AVTCORE working group will coordinate closely with the Security=20 > > Area while working on maintenance and enhancements to the=20 > SRTP Profile. > >=20 > > In addition to the milestones called out below, the AVTCORE working=20 > > group's initial tasks will include completing any remaining work=20 > > identified in those drafts from the AVT working group=20 > already in IESG=20 > > Evaluation, with the exception of the Rapid Acquisition of=20 > Multicast=20 > > RTP sessions, which will complete in the AVTEXT working group. > >=20 > > Goals and Milestones: > > Dec 2010 Submit Guideline for Choosing RTCP CNAME as Proposed=20 > > Standard Dec 2010 Submit use of AES-192 and AES-256 in=20 > Secure RTP for Proposed > > Standard > > Dec 2010 Submit Port Mapping Between Unicast and Multicast RTP=20 > > Sessions > >=20 > > for Proposed Standard > > Dec 2010 Submit Real-Time Transport Control Protocol=20 > (RTCP) in Overlay=20 > > Multicast for Proposed Standard Feb 2011 Submit=20 > Monitoring=20 > > Architecture for RTP for Informational Feb 2011 Guidelines for the=20 > > use of Variable Bit Rate Audio with Secure > > RTP as informational (or possibly BCP) Apr 2011 Submit in=20 > > band keying mechanism for SRTP draft for Proposed > > Standard > > Apr 2011 Submit Explicit Congestion Notification (ECN) for=20 > RTP over=20 > > UDP > >=20 > > for Proposed Standard > > May 2011 RTCP indication for retransmission suppression as=20 > proposed=20 > > standard > > Sep 2011 Encryption of Header Extensions in the Secure Real-Time=20 > > Transport Protocol (SRTP) for Proposed Standard > >=20 > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > >=20 >=20 >=20 From ogud@ogud.com Wed Jan 12 11:37:41 2011 Return-Path: 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 DA7F23A6B3B for ; Wed, 12 Jan 2011 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Xg3CPOx9xgT3 for ; Wed, 12 Jan 2011 11:37:41 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D457A3A6ACC for ; Wed, 12 Jan 2011 11:37:40 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0CJe0lm047790 for ; Wed, 12 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 12 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110112_194000_070043.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-dnsext-ecdsa-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: , X-List-Received-Date: Wed, 12 Jan 2011 19:37:41 -0000 Count: 33 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Informational W. Wijngaards Expires: July 13, 2011 NLnet Labs January 9, 2011 Elliptic Curve DSA for DNSSEC draft-ietf-dnsext-ecdsa-00 Abstract This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. From dromasca@avaya.com Thu Jan 13 02:38:06 2011 Return-Path: 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 1A2173A6B60; Thu, 13 Jan 2011 02:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x4fQu8sRMe4c; Thu, 13 Jan 2011 02:38:05 -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 0A8F83A6A17; Thu, 13 Jan 2011 02:38:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABNlLk3GmAcF/2dsb2JhbACkRnOmDAKWQ4J1glcEjkw X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="227321823" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2011 05:40:24 -0500 X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="569809095" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jan 2011 05:40:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 11:39:58 +0100 Message-ID: In-Reply-To: <4D2EBFD5.4030006@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Thread-Index: AcuzAUJoyaTYsSjfRgWyqFsI1KM1twADNg/Q References: <4D2EBFD5.4030006@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Thu, 13 Jan 2011 10:38:06 -0000 Hard to refer it in the charter as long as the RFC is not published.=20 Dan =20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Thursday, January 13, 2011 11:03 AM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; IETF DNS Directorate;=20 > aaa-doctors@ietf.org; mib-doctors@ietf.org; YANG Doctors > Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use=20 > with RTCP's Extended Report Framework (xrblock) >=20 > Dan, >=20 > This one would be a good candidate for the PMOL guidelines. > Not sure if PMOL should be mentioned in the charter though... >=20 > Regards, Benoit. > > > > > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]=20 > On Behalf=20 > > Of IESG Secretary > > Sent: Tuesday, January 11, 2011 8:38 PM > > To: new-work@ietf.org > > Subject: WG Review: Metric Blocks for use with RTCP's=20 > Extended Report=20 > > Framework (xrblock) > > > > A new IETF working group has been proposed in the Real-Time=20 > > Applications and Infrastructure Area. The IESG has not made any=20 > > determination as yet. > > The following draft charter was submitted, and is provided for=20 > > informational purposes only. Please send your comments to the IESG=20 > > mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. > > > > Metric Blocks for use with RTCP's Extended Report Framework=20 > (xrblock) > > ------------------------------------------- > > Current Status: Proposed Working Group Last modified: 2010-12-03 > > > > Chairs: TBD > > > > Real-Time Applications and Infrastructure Area Directors: > > Gonzalo Camarillo > > Robert Sparks > > > > Real-Time Applications and Infrastructure Area Advisor: > > Robert Sparks > > > > Mailing Lists: TBD > > > > Description of Working Group: > > > > RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)"=20 > established=20 > > a framework to allow new information to be conveyed in RTCP,=20 > > supplementing the original report blocks defined in RFC=20 > 3550, "RTP: A=20 > > Transport Protocol for Real-Time Applications". > > > > The XRBLOCK working group is chartered to work within this=20 > framework,=20 > > evaluating proposals for report block definitions containing new=20 > > metrics. The group will follow the guidelines established=20 > in RFC5968,=20 > > "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP=20 > > Monitoring Architecture being developed in the RTPCORE=20 > working group. > > > > Goals and Milestones: > > > > Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar=20 > > 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric > > Reporting > > Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric > > Reporting > > Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric > > Reporting > > Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun > > 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep=20 > > 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting=20 > > Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric > > Reporting > > Sep 2011 Submit RTCP XR Report Block for Packet Delay=20 > Variation Metric > > Reporting > > Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of > > Discarded Packets > > Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting=20 > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir >=20 >=20 From tme@americafree.tv Wed Jan 12 05:51:39 2011 Return-Path: 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 6384B3A6B27; Wed, 12 Jan 2011 05:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5Mr2rzFdnh6d; Wed, 12 Jan 2011 05:51:35 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 653513A6A36; Wed, 12 Jan 2011 05:51:35 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id AF5929A2C399; Wed, 12 Jan 2011 08:53:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Wed, 12 Jan 2011 08:53:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <824DCB12-4FC5-4573-A698-4887CD5D1785@americafree.tv> References: To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 13 Jan 2011 02:41:32 -0800 Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Audio/Video Transport Core Maintenence (avtcore) 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: , X-List-Received-Date: Wed, 12 Jan 2011 13:51:39 -0000 On Jan 12, 2011, at 6:20 AM, Romascanu, Dan (Dan) wrote: > This is the first in a series of four messages announcing the review = for > four IETF Working Groups. Note that these WGs are not completely new, > but rather the split of the current AVT (Audio/Video Transport) WG in > the RAI Area.=20 Dear Dan; In this case, what exactly is being reviewed : The desirability of splitting AVT ? The fault lines along which the split is being done ? The detailed charters of each new group & the energy available to do = each of the pieces ? In particular, 3 of the 4 seem like a fairly routine split of AVT, while = the fourth (XRBLOCK) seems like new work, and so it seems to me should be evaluated differently. Regards Marshall >=20 > Dan >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of > IESG Secretary > Sent: Tuesday, January 11, 2011 8:43 PM > To: new-work@ietf.org > Subject: WG Review: Audio/Video Transport Core Maintenence (avtcore)=20= >=20 > A new IETF working group has been proposed in the Real-Time = Applications > and Infrastructure Area. The IESG has not made any determination as > yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing > list (iesg@ietf.org) by Tuesday, January 18, 2011. =20 >=20 > Audio/Video Transport Core Maintenence (avtcore) > ------------------------------------------- > Current Status: Proposed Working Group > Last modified: 2010-12-03 >=20 > Chairs: TBD >=20 > Real-Time Applications and Infrastructure Area Directors: > Gonzalo Camarillo > Robert Sparks >=20 > Real-Time Applications and Infrastructure Area Advisor: > Robert Sparks >=20 > Mailing Lists: TBD >=20 > Description of Working Group: >=20 > The Real-time Transport Protocol, RTP, along with its associated > profiles and payload formats provides for real-time transmission of > audio and video over unicast and multicast transports. RTP itself has > been shepherded to Full Standard. Its associated profiles, extensions, > and payload formats are currently at various levels of standards > maturity.=20 >=20 > The AVTCORE working group is chartered to maintain the core RTP/RTCP > protocols and the AVP, SAVP, AVPF, and SAVPF profiles. The group will > provide architectural guidance for extending the protocols and > guidelines for their proper use. While other working groups may be > chartered to work on application-specific extensions to the protocols, > extensions that are generally applicable will be developed in AVTCORE. >=20 > The AVTCORE working group will coordinate closely with the Security = Area > while working on maintenance and enhancements to the SRTP Profile. >=20 > In addition to the milestones called out below, the AVTCORE working > group's initial tasks will include completing any remaining work > identified in those drafts from the AVT working group already in IESG > Evaluation, with the exception of the Rapid Acquisition of Multicast = RTP > sessions, which will complete in the AVTEXT working group. >=20 > Goals and Milestones: > Dec 2010 Submit Guideline for Choosing RTCP CNAME as Proposed = Standard > Dec 2010 Submit use of AES-192 and AES-256 in Secure RTP for Proposed=20= > Standard > Dec 2010 Submit Port Mapping Between Unicast and Multicast RTP = Sessions >=20 > for Proposed Standard > Dec 2010 Submit Real-Time Transport Control Protocol (RTCP) in = Overlay=20 > Multicast for Proposed Standard Feb 2011 Submit Monitoring > Architecture for RTP for Informational Feb 2011 Guidelines for the = use > of Variable Bit Rate Audio with Secure=20 > RTP as informational (or possibly BCP) Apr 2011 Submit in > band keying mechanism for SRTP draft for Proposed=20 > Standard > Apr 2011 Submit Explicit Congestion Notification (ECN) for RTP over = UDP >=20 > for Proposed Standard > May 2011 RTCP indication for retransmission suppression as proposed=20= > standard > Sep 2011 Encryption of Header Extensions in the Secure Real-Time=20 > Transport Protocol (SRTP) for Proposed Standard >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 From bclaise@cisco.com Thu Jan 13 01:08:32 2011 Return-Path: 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 0B1A13A6AB7; Thu, 13 Jan 2011 01:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 WwQf1ajd60C8; Thu, 13 Jan 2011 01:08:31 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id DC9F33A6AB3; Thu, 13 Jan 2011 01:08:30 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0D93Lfi015195; Thu, 13 Jan 2011 10:03:21 +0100 (CET) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0D93HC4008156; Thu, 13 Jan 2011 10:03:17 +0100 (CET) Message-ID: <4D2EBFD5.4030006@cisco.com> Date: Thu, 13 Jan 2011 10:03:17 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Jan 2011 02:41:32 -0800 Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Thu, 13 Jan 2011 09:08:32 -0000 Dan, This one would be a good candidate for the PMOL guidelines. Not sure if PMOL should be mentioned in the charter though... Regards, Benoit. > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > IESG Secretary > Sent: Tuesday, January 11, 2011 8:38 PM > To: new-work@ietf.org > Subject: WG Review: Metric Blocks for use with RTCP's Extended Report > Framework (xrblock) > > A new IETF working group has been proposed in the Real-Time Applications > and Infrastructure Area. The IESG has not made any determination as > yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing > list (iesg@ietf.org) by Tuesday, January 18, 2011. > > Metric Blocks for use with RTCP's Extended Report Framework (xrblock) > ------------------------------------------- > Current Status: Proposed Working Group > Last modified: 2010-12-03 > > Chairs: TBD > > Real-Time Applications and Infrastructure Area Directors: > Gonzalo Camarillo > Robert Sparks > > Real-Time Applications and Infrastructure Area Advisor: > Robert Sparks > > Mailing Lists: TBD > > Description of Working Group: > > RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a > framework to allow new information to be conveyed in RTCP, supplementing > the original report blocks defined in RFC 3550, "RTP: A Transport > Protocol for Real-Time Applications". > > The XRBLOCK working group is chartered to work within this framework, > evaluating proposals for report block definitions containing new > metrics. The group will follow the guidelines established in RFC5968, > "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP > Monitoring Architecture being developed in the RTPCORE working group. > > Goals and Milestones: > > Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar 2011 > Submit RTCP XR Report Block for Burst/Gap Discard metric > Reporting > Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric > Reporting > Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric > Reporting > Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun > 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 > Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 > Submit RTCP XR Report Block for Loss Concealment metric > Reporting > Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric > Reporting > Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of > Discarded Packets > Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir From dromasca@avaya.com Thu Jan 13 07:56:22 2011 Return-Path: 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 37AB228C115; Thu, 13 Jan 2011 07:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nD9Xudu5NipU; Thu, 13 Jan 2011 07:56:20 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E4C7E28C112; Thu, 13 Jan 2011 07:56:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABOwLk2HCzI1/2dsb2JhbACkSHOmVgKWLYJ1glcEjkw X-IronPort-AV: E=Sophos;i="4.60,318,1291611600"; d="scan'208";a="54190514" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Jan 2011 10:56:49 -0500 X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="581916016" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2011 10:56:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 16:55:57 +0100 Message-ID: In-Reply-To: <4D2EF504.20700@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Thread-Index: AcuzIPQWsMl6GLHySiGezcgTxba5mgAGSg+w References: <4D2EBFD5.4030006@cisco.com> <4D2EF504.20700@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Thu, 13 Jan 2011 15:56:22 -0000 Actually this may be a good idea. You can make this comment to the IESG as the charter is in public external review. It will draw more attention to the PMOL guidelines which is not a bad thing either.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Thursday, January 13, 2011 2:50 PM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; IETF DNS Directorate;=20 > aaa-doctors@ietf.org; mib-doctors@ietf.org; YANG Doctors > Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use=20 > with RTCP's Extended Report Framework (xrblock) >=20 > Dan, >=20 > Understood. Btw, interestingly, I was working on the PMOL=20 > framework this morning. The IETF last-call is not that far. > However, I was thinking of a generic sentence that will point=20 > to PMOL without mentioning it. > Something such as: "The definition of performance metrics=20 > should be consistent with the existing common practice in the IETF" >=20 > Regards, Benoit. > > Hard to refer it in the charter as long as the RFC is not published. > > > > Dan > > > > > >> -----Original Message----- > >> From: Benoit Claise [mailto:bclaise@cisco.com] > >> Sent: Thursday, January 13, 2011 11:03 AM > >> To: Romascanu, Dan (Dan) > >> Cc: ops-dir@ietf.org; IETF DNS Directorate; aaa-doctors@ietf.org;=20 > >> mib-doctors@ietf.org; YANG Doctors > >> Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use with=20 > >> RTCP's Extended Report Framework (xrblock) > >> > >> Dan, > >> > >> This one would be a good candidate for the PMOL guidelines. > >> Not sure if PMOL should be mentioned in the charter though... > >> > >> Regards, Benoit. > >>> > >>> -----Original Message----- > >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] > >> On Behalf > >>> Of IESG Secretary > >>> Sent: Tuesday, January 11, 2011 8:38 PM > >>> To: new-work@ietf.org > >>> Subject: WG Review: Metric Blocks for use with RTCP's > >> Extended Report > >>> Framework (xrblock) > >>> > >>> A new IETF working group has been proposed in the Real-Time=20 > >>> Applications and Infrastructure Area. The IESG has not made any=20 > >>> determination as yet. > >>> The following draft charter was submitted, and is provided for=20 > >>> informational purposes only. Please send your comments to=20 > the IESG=20 > >>> mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. > >>> > >>> Metric Blocks for use with RTCP's Extended Report Framework > >> (xrblock) > >>> ------------------------------------------- > >>> Current Status: Proposed Working Group Last modified: 2010-12-03 > >>> > >>> Chairs: TBD > >>> > >>> Real-Time Applications and Infrastructure Area Directors: > >>> Gonzalo Camarillo > >>> Robert Sparks > >>> > >>> Real-Time Applications and Infrastructure Area Advisor: > >>> Robert Sparks > >>> > >>> Mailing Lists: TBD > >>> > >>> Description of Working Group: > >>> > >>> RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" > >> established > >>> a framework to allow new information to be conveyed in RTCP,=20 > >>> supplementing the original report blocks defined in RFC > >> 3550, "RTP: A > >>> Transport Protocol for Real-Time Applications". > >>> > >>> The XRBLOCK working group is chartered to work within this > >> framework, > >>> evaluating proposals for report block definitions containing new=20 > >>> metrics. The group will follow the guidelines established > >> in RFC5968, > >>> "Guidelines for Extending the RTP Control Protocol=20 > (RTCP)" and RTP=20 > >>> Monitoring Architecture being developed in the RTPCORE > >> working group. > >>> Goals and Milestones: > >>> > >>> Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar > >>> 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric > >>> Reporting > >>> Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric > >>> Reporting > >>> Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric > >>> Reporting > >>> Jun 2011 Submit RTCP XR Report Block for Delay metric=20 > Reporting Jun > >>> 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep > >>> 2011 Submit RTCP XR Report Block for Jitter Buffer Metric=20 > Reporting=20 > >>> Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric > >>> Reporting > >>> Sep 2011 Submit RTCP XR Report Block for Packet Delay > >> Variation Metric > >>> Reporting > >>> Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of > >>> Discarded Packets > >>> Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting=20 > >>> _______________________________________________ > >>> OPS-DIR mailing list > >>> OPS-DIR@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ops-dir > >> >=20 >=20 From bclaise@cisco.com Thu Jan 13 04:55:24 2011 Return-Path: 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 BEFA73A6B79; Thu, 13 Jan 2011 04:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 LZ+xlGx7VmtY; Thu, 13 Jan 2011 04:55:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 83ADD3A6B76; Thu, 13 Jan 2011 04:55:23 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DCoDmh003918; Thu, 13 Jan 2011 13:50:13 +0100 (CET) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DCoCQR006846; Thu, 13 Jan 2011 13:50:12 +0100 (CET) Message-ID: <4D2EF504.20700@cisco.com> Date: Thu, 13 Jan 2011 13:50:12 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4D2EBFD5.4030006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Jan 2011 08:14:00 -0800 Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Thu, 13 Jan 2011 12:55:24 -0000 Dan, Understood. Btw, interestingly, I was working on the PMOL framework this morning. The IETF last-call is not that far. However, I was thinking of a generic sentence that will point to PMOL without mentioning it. Something such as: "The definition of performance metrics should be consistent with the existing common practice in the IETF" Regards, Benoit. > Hard to refer it in the charter as long as the RFC is not published. > > Dan > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Thursday, January 13, 2011 11:03 AM >> To: Romascanu, Dan (Dan) >> Cc: ops-dir@ietf.org; IETF DNS Directorate; >> aaa-doctors@ietf.org; mib-doctors@ietf.org; YANG Doctors >> Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use >> with RTCP's Extended Report Framework (xrblock) >> >> Dan, >> >> This one would be a good candidate for the PMOL guidelines. >> Not sure if PMOL should be mentioned in the charter though... >> >> Regards, Benoit. >>> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] >> On Behalf >>> Of IESG Secretary >>> Sent: Tuesday, January 11, 2011 8:38 PM >>> To: new-work@ietf.org >>> Subject: WG Review: Metric Blocks for use with RTCP's >> Extended Report >>> Framework (xrblock) >>> >>> A new IETF working group has been proposed in the Real-Time >>> Applications and Infrastructure Area. The IESG has not made any >>> determination as yet. >>> The following draft charter was submitted, and is provided for >>> informational purposes only. Please send your comments to the IESG >>> mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. >>> >>> Metric Blocks for use with RTCP's Extended Report Framework >> (xrblock) >>> ------------------------------------------- >>> Current Status: Proposed Working Group Last modified: 2010-12-03 >>> >>> Chairs: TBD >>> >>> Real-Time Applications and Infrastructure Area Directors: >>> Gonzalo Camarillo >>> Robert Sparks >>> >>> Real-Time Applications and Infrastructure Area Advisor: >>> Robert Sparks >>> >>> Mailing Lists: TBD >>> >>> Description of Working Group: >>> >>> RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" >> established >>> a framework to allow new information to be conveyed in RTCP, >>> supplementing the original report blocks defined in RFC >> 3550, "RTP: A >>> Transport Protocol for Real-Time Applications". >>> >>> The XRBLOCK working group is chartered to work within this >> framework, >>> evaluating proposals for report block definitions containing new >>> metrics. The group will follow the guidelines established >> in RFC5968, >>> "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP >>> Monitoring Architecture being developed in the RTPCORE >> working group. >>> Goals and Milestones: >>> >>> Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar >>> 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric >>> Reporting >>> Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric >>> Reporting >>> Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric >>> Reporting >>> Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun >>> 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep >>> 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting >>> Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric >>> Reporting >>> Sep 2011 Submit RTCP XR Report Block for Packet Delay >> Variation Metric >>> Reporting >>> Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of >>> Discarded Packets >>> Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting >>> _______________________________________________ >>> OPS-DIR mailing list >>> OPS-DIR@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-dir >> From ogud@ogud.com Thu Jan 13 11:37:39 2011 Return-Path: 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 61ABD28C11B for ; Thu, 13 Jan 2011 11:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sb3Zp6Mi8zVm for ; Thu, 13 Jan 2011 11:37:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 758703A6A6E for ; Thu, 13 Jan 2011 11:37:38 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0DJe162056557 for ; Thu, 13 Jan 2011 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 13 Jan 2011 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110113_194001_067716.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-bertrand-cdni-use-cases-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: , X-List-Received-Date: Thu, 13 Jan 2011 19:37:39 -0000 Count: 24 Internet Engineering Task Force G. Bertrand Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange Expires: July 17, 2011 January 13, 2011 Use Cases for Content Distribution Network Interconnection draft-bertrand-cdni-use-cases-00 Abstract This document depicts use cases for content delivery network (CDN) interconnection based on Orange experiments. The use cases are divided in the two following categories. Category 1 use cases present situations that require a footprint extension for existing CDNs. Category 2 use cases include additional situations where CDN interconnection would be desirable in a longer term. From dromasca@avaya.com Fri Jan 14 01:59:01 2011 Return-Path: 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 C63CA3A69EF; Fri, 14 Jan 2011 01:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1OAfff5Q38CU; Fri, 14 Jan 2011 01:59:00 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E96403A6A0D; Fri, 14 Jan 2011 01:58:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADOtL02HCzI1/2dsb2JhbACWD45Hc6chApYngniCVwSOUoJc X-IronPort-AV: E=Sophos;i="4.60,322,1291611600"; d="scan'208";a="54322182" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 14 Jan 2011 05:01:24 -0500 X-IronPort-AV: E=Sophos;i="4.60,322,1291611600"; d="scan'208";a="582265683" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jan 2011 05:00:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 11:00:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 20, 2011 IESG Teleconference. Thread-Index: AcuzdLcSWZoHBRyXQSyYSDR7IV7PMAAXHzJA From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the January 20, 2011 IESG Teleconference. 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: , X-List-Received-Date: Fri, 14 Jan 2011 09:59:01 -0000 Please find below the preliminary agenda of the 1/20 IESG telechat. Please send me your comments, questions and concerns about the documents and WG charters brought up for approval before 1/19 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-mmusic-image-attributes-10 Negotiation of Generic Image Attributes in SDP (Proposed Standard) Note: Tom Taylor (tom111.taylor@bell.net) is the Document Shepherd. Token: Robert Sparks o draft-ietf-xmpp-3921bis-19 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard) Note: Joe Hildebrand (jhildebr@cisco.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-pwe3-oam-msg-map-14 Pseudowire (PW) OAM Message Mapping (Proposed Standard) Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd. Token: Stewart Bryant Was deferred by Tim Polk on 2011-01-06 o draft-ietf-ltans-xmlers-10 Extensible Markup Language Evidence Record Syntax (Proposed Standard) Note: Carl Wallace is the document sheperd Token: Tim Polk o draft-ietf-sipcore-keep-11 Indication of support for keep-alive (Proposed Standard) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Robert Sparks o draft-ietf-martini-gin-12 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) (Proposed Standard) Note: Bernard Aboba (Bernard_Aboba@hotmail.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-multimob-pmipv6-base-solution-07 Base Deployment for Multicast Listener Support in PMIPv6 Domains (BCP) Note: Behcet Sarikaya (sarikaya@ieee.org) is the document shepherd. Token: Jari Arkko o draft-ietf-roll-routing-metrics-14 Routing Metrics used for Path Calculation in Low Power and Lossy Networks (Proposed Standard) Note: David Culler (culler@eecs.berkeley.edu) is the document shepherd. Token: Adrian Farrel o draft-ietf-6lowpan-hc-13 Compression Format for IPv6 Datagrams in 6LoWPAN Networks (Proposed Standard) Note: The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann(cabo@tzi.org). Token: Ralph Droms o draft-ietf-isis-layer2-09 Extensions to IS-IS for Layer-2 Systems (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-isis-trill-04 TRILL Use of IS-IS (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-ccamp-gmpls-g-694-lambda-labels-11 Generalized Labels for Lambda-Switching Capable Label Switching Routers (Proposed Standard) Note: Lou Berger (lberger@labn.net) is the document shepherd. Token: Adrian Farrel o draft-ietf-l3vpn-mvpn-infra-addrs-02 IPv4 and IPv6 Infrastructure Addresses in Multicast-VPN Routes (Proposed Standard) Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the document shepherd. Token: Stewart Bryant 2.1.2 Returning Items o draft-ietf-tls-rfc4347-bis-04 Datagram Transport Layer Security version 1.2 (Proposed Standard) Note: Joe Salowey (jsalowey@cisco.com) is the document Shepherd. Token: Sean Turner 2.2 Individual Submissions 2.2.1 New Items o draft-saintandre-tls-server-id-check-14 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (BCP) Note: There is an open question on whether this document should be a BCP or PS. As the shepherding AD I don't have a strong opinion either way. Token: Alexey Melnikov o draft-schaad-smime-algorithm-attribute-04 Signer Info Algorithm Protection Attribute (Proposed Standard) Note: Jim Schaad (ietf@augustcellars.com) is the Document Shepherd. Token: Sean Turner 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-sipcore-sec-flows-07 Example call flows using Session Initiation Protocol (SIP) security mechanisms (Informational) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-roll-security-framework-04 A Security Framework for Routing over Low Power and Lossy Networks (Informational) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-mpls-tp-uni-nni-03 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (Informational) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-mptcp-threat-07 Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses (Informational) Note: Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the document shepherd. Token: Lars Eggert o draft-ietf-mptcp-architecture-04 Architectural Guidelines for Multipath TCP Development (Informational) Note: Philip Eardley (philip.eardley@bt.com) is the Document Shepherd. Token: Lars Eggert 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-merrick-jms-uri-10 URI Scheme for Java(tm) Message Service 1.0 (Informational) Token: Alexey Melnikov o draft-nsri-tls-aria-01 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational) Note: Woo-Hwan Kim (whkim5@ensec.re.kr) is the document shepherd Token: Sean Turner o draft-schaad-smime-hash-experiment-04 Experiment: Hash functions with parameters in CMS and S/MIME (Experimental) Note: Jim Schaad (ietf@augustcellars.com) is the document shepherd. Token: Sean Turner 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-zorn-radius-keywrap-18 Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational) Token: Dan Romascanu Was deferred by Russ Housley on 2011-01-05 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Light-Weight Implementation Guidance (lwig) Token: Jari 4.1.2 Proposed for Approval o Audio/Video Transport Payloads (payload) Token: Robert o Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Token: Robert o Audio/Video Transport Core Maintenence (avtcore) Token: Robert o Audio/Video Transport Extensions (avtext) Token: Robert 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Mobility EXTensions for IPv6 (mext) Token: Jari From acmorton@att.com Thu Jan 13 08:19:41 2011 Return-Path: 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 2BE933A69ED; Thu, 13 Jan 2011 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 x3v0JKeo84ZO; Thu, 13 Jan 2011 08:19:39 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id D01E83A6B33; Thu, 13 Jan 2011 08:19:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1294935706!39170224!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 26268 invoked from network); 13 Jan 2011 16:21:58 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jan 2011 16:21:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0DGLsKE020271; Thu, 13 Jan 2011 11:21:54 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0DGLoRY020197; Thu, 13 Jan 2011 11:21:50 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0DGLSwE002221; Thu, 13 Jan 2011 11:21:28 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0DGLPAC002152; Thu, 13 Jan 2011 11:21:25 -0500 Message-Id: <201101131621.p0DGLPAC002152@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110113162124gw1004lk1ve>; Thu, 13 Jan 2011 16:21:24 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Jan 2011 11:21:55 -0500 To: "Romascanu, Dan (Dan)" , "Benoit Claise" From: Al Morton In-Reply-To: References: <4D2EBFD5.4030006@cisco.com> <4D2EF504.20700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 14 Jan 2011 08:35:04 -0800 Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, IETF DNS Directorate , YANG Doctors Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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: , X-List-Received-Date: Thu, 13 Jan 2011 16:19:41 -0000 I think some of the RTCP metrics are only defined in a general way, using other standards with more detail as references (when available). I haven't combed the entire crop of RTCP extension drafts, but this was certainly true in some of them, and in RFC 3611, RTCP-XR. I support the comment, in any case, Al At 10:55 AM 1/13/2011, Romascanu, Dan (Dan) wrote: >Actually this may be a good idea. You can make this comment to the IESG >as the charter is in public external review. It will draw more attention >to the PMOL guidelines which is not a bad thing either. > >Thanks and Regards, > >Dan > > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Thursday, January 13, 2011 2:50 PM > > To: Romascanu, Dan (Dan) > > Cc: ops-dir@ietf.org; IETF DNS Directorate; > > aaa-doctors@ietf.org; mib-doctors@ietf.org; YANG Doctors > > Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use > > with RTCP's Extended Report Framework (xrblock) > > > > Dan, > > > > Understood. Btw, interestingly, I was working on the PMOL > > framework this morning. The IETF last-call is not that far. > > However, I was thinking of a generic sentence that will point > > to PMOL without mentioning it. > > Something such as: "The definition of performance metrics > > should be consistent with the existing common practice in the IETF" > > > > Regards, Benoit. > > > Hard to refer it in the charter as long as the RFC is not published. > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: Benoit Claise [mailto:bclaise@cisco.com] > > >> Sent: Thursday, January 13, 2011 11:03 AM > > >> To: Romascanu, Dan (Dan) > > >> Cc: ops-dir@ietf.org; IETF DNS Directorate; aaa-doctors@ietf.org; > > >> mib-doctors@ietf.org; YANG Doctors > > >> Subject: Re: [OPS-DIR] FW: WG Review: Metric Blocks for use with > > >> RTCP's Extended Report Framework (xrblock) > > >> > > >> Dan, > > >> > > >> This one would be a good candidate for the PMOL guidelines. > > >> Not sure if PMOL should be mentioned in the charter though... > > >> > > >> Regards, Benoit. > > >>> > > >>> -----Original Message----- > > >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] > > >> On Behalf > > >>> Of IESG Secretary > > >>> Sent: Tuesday, January 11, 2011 8:38 PM > > >>> To: new-work@ietf.org > > >>> Subject: WG Review: Metric Blocks for use with RTCP's > > >> Extended Report > > >>> Framework (xrblock) > > >>> > > >>> A new IETF working group has been proposed in the Real-Time > > >>> Applications and Infrastructure Area. The IESG has not made any > > >>> determination as yet. > > >>> The following draft charter was submitted, and is provided for > > >>> informational purposes only. Please send your comments to > > the IESG > > >>> mailing list (iesg@ietf.org) by Tuesday, January 18, 2011. > > >>> > > >>> Metric Blocks for use with RTCP's Extended Report Framework > > >> (xrblock) > > >>> ------------------------------------------- > > >>> Current Status: Proposed Working Group Last modified: 2010-12-03 > > >>> > > >>> Chairs: TBD > > >>> > > >>> Real-Time Applications and Infrastructure Area Directors: > > >>> Gonzalo Camarillo > > >>> Robert Sparks > > >>> > > >>> Real-Time Applications and Infrastructure Area Advisor: > > >>> Robert Sparks > > >>> > > >>> Mailing Lists: TBD > > >>> > > >>> Description of Working Group: > > >>> > > >>> RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" > > >> established > > >>> a framework to allow new information to be conveyed in RTCP, > > >>> supplementing the original report blocks defined in RFC > > >> 3550, "RTP: A > > >>> Transport Protocol for Real-Time Applications". > > >>> > > >>> The XRBLOCK working group is chartered to work within this > > >> framework, > > >>> evaluating proposals for report block definitions containing new > > >>> metrics. The group will follow the guidelines established > > >> in RFC5968, > > >>> "Guidelines for Extending the RTP Control Protocol > > (RTCP)" and RTP > > >>> Monitoring Architecture being developed in the RTPCORE > > >> working group. > > >>> Goals and Milestones: > > >>> > > >>> Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar > > >>> 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric > > >>> Reporting > > >>> Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric > > >>> Reporting > > >>> Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric > > >>> Reporting > > >>> Jun 2011 Submit RTCP XR Report Block for Delay metric > > Reporting Jun > > >>> 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep > > >>> 2011 Submit RTCP XR Report Block for Jitter Buffer Metric > > Reporting > > >>> Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric > > >>> Reporting > > >>> Sep 2011 Submit RTCP XR Report Block for Packet Delay > > >> Variation Metric > > >>> Reporting > > >>> Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of > > >>> Discarded Packets > > >>> Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting > > >>> _______________________________________________ > > >>> OPS-DIR mailing list > > >>> OPS-DIR@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ops-dir > > >> > > > > >_______________________________________________ >OPS-DIR mailing list >OPS-DIR@ietf.org >https://www.ietf.org/mailman/listinfo/ops-dir From ogud@ogud.com Fri Jan 14 11:37:36 2011 Return-Path: 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 58C853A6BC4 for ; Fri, 14 Jan 2011 11:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 N3eHcll1mWTr for ; Fri, 14 Jan 2011 11:37:35 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 620783A6BAC for ; Fri, 14 Jan 2011 11:37:35 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0EJe0DM065630 for ; Fri, 14 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 14 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110114_194000_020384.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-crocker-dkim-rfc4871bis-doseta-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: , X-List-Received-Date: Fri, 14 Jan 2011 19:37:36 -0000 Count: 14 DKIM D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871, 5672 (if approved) M. Kucherawy, Ed. Intended status: Standards Cloudmark Expires: July 18, 2011 January 14, 2011 DomainKeys Identified Mail (DKIM) Signatures - Over DOSETA draft-crocker-dkim-rfc4871bis-doseta-00 Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to a message or its content and thus preserve the DKIM signature. From ogud@ogud.com Fri Jan 14 11:37:36 2011 Return-Path: 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 689AF3A6BAC for ; Fri, 14 Jan 2011 11:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YBsh+PzQZh7b for ; Fri, 14 Jan 2011 11:37:35 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 620043A6BA7 for ; Fri, 14 Jan 2011 11:37:35 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0EJe0gQ065621 for ; Fri, 14 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 14 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110114_194000_011736.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-crocker-dkim-doseta-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: , X-List-Received-Date: Fri, 14 Jan 2011 19:37:36 -0000 Count: 59 DKIM D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Intended status: Standards Track M. Kucherawy, Ed. Expires: July 18, 2011 Cloudmark January 14, 2011 DomainKeys Security Tagging (DOSETA) draft-crocker-dkim-doseta-00 Abstract DomainKeys Security Tagging (DOSETA) is a component mechanism that enables development of a security-related service, such as authentication or encryption, with keys based on domain names; the name owner can be any actor involved in the handling of the data, such as the author's organization, a server operator or one of their agents. The DOSETA Library provides a collection of common capabilities, including canonicalization, parameter tagging, and retrieval of self-certified keys. The DOSETA Signing Template affixes a signature to data that is in a "header/content" form. Defining the meaning of the signature is the responsibility of the service that incorporates DOSETA. The signature is validated through a cryptographic signature and querying the signer's domain directly, to retrieve the appropriate public key. From ogud@ogud.com Fri Jan 14 12:04:43 2011 Return-Path: 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 E29BB3A6BB8 for ; Fri, 14 Jan 2011 12:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TLf6dUSYiGb8 for ; Fri, 14 Jan 2011 12:04:43 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EA9BE3A6BAC for ; Fri, 14 Jan 2011 12:04:42 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0EJe1P9065653 for ; Fri, 14 Jan 2011 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 14 Jan 2011 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110114_194001_048743.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-mif-dns-server-selection-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: , X-List-Received-Date: Fri, 14 Jan 2011 20:04:44 -0000 Count: 177 Internet Engineering Task Force T. Savolainen Internet-Draft Nokia Intended status: Standards Track J. Kato Expires: July 17, 2011 NTT January 13, 2011 Improved DNS Server Selection for Multi-Homed Nodes draft-ietf-mif-dns-server-selection-00 Abstract A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node often receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When the multi-homed node needs to utilize DNS, it has to choose which of the servers to contact to. This document describes a policy based method for helping on selection of DNS server for both forward and reverse DNS lookup procedures with help of DNS suffix and IPv6 prefix information received via DHCPv6. From rdroms.ietf@gmail.com Mon Jan 17 20:43:56 2011 Return-Path: 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 51E6628C107; Mon, 17 Jan 2011 20:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 PNQV6B5vvESB; Mon, 17 Jan 2011 20:43:55 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 547D628C10E; Mon, 17 Jan 2011 20:43:55 -0800 (PST) Received: by pzk5 with SMTP id 5so1144329pzk.31 for ; Mon, 17 Jan 2011 20:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=jHR+tdMMMwIv6EKaIiKk1BeJQj7GCSmgAQFrD4jiaro=; b=Hbqg07uiDLkmLV+NheE8GTPRSNlBS+EFbjIO0SaZhV+ZBksXN4EgJVSoOh/IKe0eAy Xv+wLD5ZEo4nhDIvoNR8EX6qm0jFmxti7mtaWymrtCPwNBoUk3NRgFKZLFLktRZUw3VD uPHd5JG90mAxOhpzQMNKW5/fUjfREUzeFpSMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=jo9+xOusvMSPtlHi56zSDHg/B7Qn8YhT2WDyjdLyWTrMCR3gsxRaKd7ZoBSJ6Me/tZ NZ0m5kHjis3oLb+Diy5bBgkRURtggWCwoBskCbTLbj8ZvN0ov1GMoBvFoZGYJfBWQc1c 9cUpOshuv8lZoe1BSmDlNYvNAZn1vz5b9ncgA= Received: by 10.143.7.17 with SMTP id k17mr1669837wfi.200.1295325990759; Mon, 17 Jan 2011 20:46:30 -0800 (PST) Received: from [10.21.108.112] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id o1sm7517214wfl.2.2011.01.17.20.46.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 20:46:29 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 20:46:28 -0800 References: <20110117230048.26192.84056.idtracker@localhost> To: IETF Directorate DNS , dnsext@ietf.org, dnsop@ietf.org Message-Id: <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dns-dir] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard 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: , X-List-Received-Date: Tue, 18 Jan 2011 04:43:56 -0000 FYI; review and comment requested... - Ralph Begin forwarded message: From: The IESG Date: January 17, 2011 3:00:48 PM PST To: IETF-Announce Subject: Last Call: = (Special-Use Domain Names) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Special-Use Domain Names' as a Proposed Standard Abstract This document describes what it means to say that a DNS name is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-14. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From jabley@hopcount.ca Tue Jan 18 07:06:20 2011 Return-Path: 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 A35B228C126; Tue, 18 Jan 2011 07:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] 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 dnJXGrfLwHby; Tue, 18 Jan 2011 07:06:18 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 72B8728C0D9; Tue, 18 Jan 2011 07:06:18 -0800 (PST) Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfDF6-000F8B-8Y; Tue, 18 Jan 2011 15:13:12 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-15--771451371 From: Joe Abley In-Reply-To: <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> Date: Tue, 18 Jan 2011 10:08:48 -0500 Message-Id: <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.28 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 18 Jan 2011 09:12:32 -0800 Cc: dnsop@ietf.org, IETF Directorate DNS , dnsext@ietf.org Subject: Re: [dns-dir] [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard 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: , X-List-Received-Date: Tue, 18 Jan 2011 15:06:20 -0000 --Apple-Mail-15--771451371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-01-17, at 23:46, Ralph Droms wrote: > FYI; review and comment requested... Comments below, in-line. > Special-Use Domain Names > draft-cheshire-dnsext-special-names-01 >=20 > Abstract >=20 > This document describes what it means to say that a DNS name is > reserved for special use, when reserving such a name is = appropriate, > and the procedure for doing so. The acronym DNS should perhaps be expanded upon first use. > 1. Introduction >=20 > Certain individual IP addresses and IP address ranges are treated > specially by network implementations, and consequently are not > suitable for use as unicast addresses. For example, IPv4 addresses > 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC2606], = with > 224.0.0.1 being the "all hosts" multicast address [RFC1112] > [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host" > address [RFC5735]. >=20 > Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own > concept of reserved names, such as "example.com", "example.net", = and > "example.org", or any name falling under the top level = pseudo-domain > "invalid" [RFC2606]. However, "Reserved Top Level DNS Names" > [RFC2606] does not state whether implementations are expected to > treat such names differently, and if so, in what way. DNS could be expanded again, upon first use outside the abstract, and a = reference to 1034/1035 wouldn't hurt. I don't think special-use names are a concept of the DNS in the protocol = sense, but rather a set of administrative conventions. I think it's = fairly clear that 2606 does not specify a protocol restriction (and, = consequently, does not specify special handling in implementations); it = doesn't update 1034/1035, and the rationale given in section 2 suggests = normal handling in DNS software (it wouldn't be much of a test if your = test cases were all handled differently from production, non-reserved = names). The idea of creating an IANA registry of special-use names for ease of = reference by other documents seems worthwhile, however. > 2. Applicability >=20 > When IP multicast was created [RFC1112], implementations had to be > updated to understand what a multicast address means and what to do > with it. Adding IP multicast to a networking stack entailed more = than > merely adding the right routing table entries for those addresses. > Moreover, supporting IP multicast entails some level of commonality > that is consistent across all conformant hosts, independent of what > networks those hosts may be connected to. While it is possible to > build a private isolated network using whatever valid unicast IP > addresses and routing topology you choose (regardless of whether > those unicast IP addresses are already in use by other hosts on the > public Internet) the IPv4 multicast address 224.0.0.1 is always the > "all hosts" multicast address and that's not a local decision. The examples above are all those in which special implementation = decisions are required for handling special-use addresses. That covers = part of the story, but... > Similarly, if a domain name has special properties that affect the > way hardware and software implementations handle the name, which > apply universally regardless of what network the implementation may > be connected to, then that may be a candidate for having the IETF > declare the name to be a Special-Use Domain Name and specify what > special treatment implementations should give to that name. If > declaring a given name to be special would result in no change to = any > implementations, then that suggests that the name may not be = special > in any material way, and it may be more appropriate to use the > existing DNS mechanisms [RFC1034] to provide the desired = delegation, > data, or lack-of-data for the name in question. Where the desired > behaviour can be achieved via the existing domain name registration > processes, that process should be used. Reservation of a = Special-Use > Domain Names is not a mechanism for circumventing normal domain = name > registration processes. ... I disagree with the characterisation that follows. Just because = there is no intended special handling required for INVALID as a TLD = doesn't make INVALID less special in the operational sense; implications = remain for root zone management (i.e. the label INVALID should not = appear) that can't be signalled using resource records. EXAMPLE.COM and = friends are delegated, and require no special handling in DNS software, = but those names remain special in the sense that they have specific = application in documentation. > 3. Procedure >=20 > If it is determined that special handling of a name is required in > order to implement some desired new functionality, then an IETF > "Standards Action" RFC [RFC5226] needs to be published describing = the > new functionality, and: If the criteria for expansion of the IANA registry is a standards = action, then that detail belongs in the IANA Considerations section. See = below for more on that. > o The RFC needs to state how implementations determine that the > special handling is required for any given name. This is = typically > done by stating that any fully-qualified domain names ending in = a > certain suffix (i.e. falling within a specified parent pseudo- > domain) will receive the special behaviour. In effect this = carves > off a sub-tree of the DNS namespace in which the modified name > treatment rules apply, analogous to how IP multicast [RFC1112] = or > IP link-local addresses [RFC3927] [RFC4862] carve off chunks of > the IP address space in which their respective modified address > treatment rules apply. I think the description above is largely implicit in the word "domain", = which means a sub-tree of the namespace anchored at a particular domain = name. > o The RFC needs to state, in each of the seven categories below, > what special treatment, if any, is to be applied. If the answer = in > all seven categories is "none", then possibly no special = treatment > is required and requesting reservation of a Special-Use Domain > Name may not be appropriate. This direction contains vaguely normative-sounding language ("needs") = but it's not clear what that means in practice. I think this advice = cannot be normative, but really seeks to give guidance much as RFC 3552 = and RFC 2434 do. This document would be easier to put in context if it = did similarly, I think. If there are hard requirements for updating the = IANA registry that this document also specifies be created then they = belong in the IANA Considerations section, since in effect they are = directions to the IANA for maintaining that registry. The text which = follows in section 4 looks like guidance to me, however. > 4. Domain Name Reservation Considerations >=20 > An IETF "Standards Action" RFC specifying some new naming = behaviour, > which requires a Special-Use Domain Name be reserved to implement > this desired new behaviour, needs to contain a "Domain Name > Reservation Considerations" section giving answers in the following > seven categories: I am not sure that instantiating a new named document section is = practical or necessary, and certainly seems destined to delay this = document's progress as there's little recent precedent for it. Modifying = the review and publication process for the RFC Editor will likely also = require IAB review. Most of the considerations that are described in the rest of this = section look entirely reasonable, but perhaps it's not an exhaustive = list. There's no discussion of the applicability of DNSSEC for the = domains concerned, for example -- it might be beneficial for some = applications to specify that zones not be signed, for some reason, or = that the zone in which a definitively non-existent name does not exist = is signed in order to provide cryptographic confidence in its = non-existence. This one, however, touches on policy that I might argue is effectively = outside the realm of IETF specifications: > 7. DNS Registrars: >=20 > How should DNS Registrars treat requests to register this = reserved > domain name? Should such requests be denied? Should such = requests > be allowed, but only to a specially-designated entity? (For > example, the name "www.example.org" is reserved for = documentation > examples and is not available for registration; however, the = name > is in fact registered; and there is even a web site at that = name, > which states circularly that the name is reserved for use in > documentation and cannot be registered!) EXAMPLE.ORG is in fact reserved as described; the implementation of that = reservation is an entry in the ORG registry, but the effect is as = intended. Domain Name:EXAMPLE.ORG Created On:31-Aug-1995 04:00:00 UTC Last Updated On:27-Jul-2010 20:57:51 UTC Expiration Date:30-Aug-2010 04:00:00 UTC Sponsoring Registrar:Internet Assigned Numbers Authority (IANA) = (R193-LROR) Status:DELETE PROHIBITED Status:RENEW PROHIBITED Status:TRANSFER PROHIBITED Status:UPDATE PROHIBITED > 5. Security Considerations >=20 > This document outlines the circumstances in which reserving a = domain > name for special-use is appropriate, and the procedure for having > that Special-Use Domain Name recorded by IANA. Any document > requesting such a Special-Use Domain Name needs to contain an > appropriate "Security Considerations" section which describes any > security issues relevant to that special use. This seems like an additional guideline that would more usefully belong = in section 4. This document doesn't seem to me to have any security = considerations, but a back-reference to guidance in section 4 doesn't = seem unreasonable. > 6. IANA Considerations >=20 > IANA needs to create a new registry of Special-Use Domain Names. >=20 > When IANA receives a request to record a new "Special-Use Domain > Name" it should verify that the IETF "Standards Action" RFC = [RFC5226] > includes the required "Domain Name Reservation Considerations" > section stating how the special meaning of this name affects the > behaviour of hardware, software, and humans in the seven = categories, > and if so, record in the registry the Special-Use Domain Name and a > reference to the RFC that documents it. I don't pretend to speak authoritatively for Michelle and her team, but = this seems almost unimplementable as-written. It would be much easier = for IANA staff to handle this direction if it included more explicit = instructions such as specifying the registry name and the circumstances = in which entries in the registry are to be added, deleted and changed, = and gave clearer instructions (rows, columns) on how the registry was to = be created. An initial set of data for the registry to contain would = also be useful to mention. For what it's worth I drafted a document some time ago with similar = objectives, but without the useful guidance that this document includes. = I've attached a copy to further illustrate my thoughts above. Perhaps = it's not unreasonable to split the content of this document into two = I-Ds, one which specifies the registry and a second which gives guidance = to future document authors who seek to make use of it. Joe --Apple-Mail-15--771451371 Content-Disposition: attachment; filename=draft-jabley-reserved-domain-names.txt Content-Type: text/plain; name="draft-jabley-reserved-domain-names.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ICANN Intended status: BCP October 18, 2010 Expires: April 21, 2011 Reserved Domain Names draft-jabley-reserved-domain-names-00 Abstract The Domain Name System (DNS) makes use of a hierarchical naming scheme. The validity of a particular name in the DNS is governed by protocol, operational and policy considerations. The IETF has identified particular domain names to have special considerations associated with their use. These domain names have been identified in various documents in the RFC series. This document describes the creation of an IANA registry to catalogue such domain names and provides direction about how this registry should be maintained. This document does not identify any new domain name as having special considerations associated with its use. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Abley Expires April 21, 2011 [Page 1] =0C Internet-Draft Reserved Domain Names October 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abley Expires April 21, 2011 [Page 2] =0C Internet-Draft Reserved Domain Names October 2010 1. Introduction The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. The DNS makes use of a hierarchical naming scheme. The validity of a particular name in the DNS is governed by protocol, operational and policy considerations. The IETF has identified particular domain names to have special considerations associated with their use. Examples of such domain names are "LOCALHOST" and "EXAMPLE.ORG" which are discussed in [RFC2606], and "LOCAL" and "254.169.IN-ADDR.ARPA" which are described in [I-D.cheshire-dnsext-multicastdns]. This document describes the creation of an IANA registry to catalogue such domain names and provides direction about how this registry should be maintained. This document does not identify any new domain name as having special considerations associated with its use. Abley Expires April 21, 2011 [Page 3] =0C Internet-Draft Reserved Domain Names October 2010 2. IANA Considerations This document directs the IANA to create a registry as follows: +-------------------------+--------------------------------------+ | Parameter | Value | +-------------------------+--------------------------------------+ | Registry Name | Reserved Domain Names | | | | | Reference | This document (RFCXXXX) | | | | | Registration Procedures | Document Published with IAB Approval | +-------------------------+--------------------------------------+ The initial registry contents should be as follows: +-------------+-----------------------------------------+-----------+ | Domain Name | Description | Reference | +-------------+-----------------------------------------+-----------+ | TEST | Recommended for use in testing of | [RFC2606] | | | current or new DNS related code | | | | | | | EXAMPLE | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | INVALID | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | LOCALHOST | Traditionally statically defined in | [RFC2606] | | | host DNS implementations as having an A | | | | record pointing to the loop back IP | | | | address, and reserved for such use | | | | | | | EXAMPLE.COM | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.NET | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.ORG | Available for use as examples | [RFC2606] | +-------------+-----------------------------------------+-----------+ Abley Expires April 21, 2011 [Page 4] =0C Internet-Draft Reserved Domain Names October 2010 3. Security Considerations This document poses no new security issues. Abley Expires April 21, 2011 [Page 5] =0C Internet-Draft Reserved Domain Names October 2010 4. Informative References [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-11 (work in progress), March 2010. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. Abley Expires April 21, 2011 [Page 6] =0C Internet-Draft Reserved Domain Names October 2010 Appendix A. Editorial Notes This section (and sub-sections) to be removed prior to publication. A.1. Change History 00 Initial draft. Abley Expires April 21, 2011 [Page 7] =0C Internet-Draft Reserved Domain Names October 2010 Author's Address Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 519 670 9327 Email: joe.abley@icann.org Abley Expires April 21, 2011 [Page 8] =0C --Apple-Mail-15--771451371-- From fweimer@bfk.de Tue Jan 18 07:15:08 2011 Return-Path: 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 C08DB3A6E53; Tue, 18 Jan 2011 07:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=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 CoAqAJCaes6T; Tue, 18 Jan 2011 07:15:08 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id C7C393A6C5D; Tue, 18 Jan 2011 07:15:07 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PfDJW-0003HG-T1; Tue, 18 Jan 2011 15:17:42 +0000 Received: by bfk.de with local id 1PfDJW-0006Lf-ND; Tue, 18 Jan 2011 15:17:42 +0000 To: Joe Abley References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> From: Florian Weimer Date: Tue, 18 Jan 2011 15:17:42 +0000 In-Reply-To: <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> (Joe Abley's message of "Tue\, 18 Jan 2011 10\:08\:48 -0500") Message-ID: <82k4i2ckbt.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 18 Jan 2011 09:12:33 -0800 Cc: dnsop@ietf.org, dnsext@ietf.org, IETF Directorate DNS Subject: Re: [dns-dir] [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard 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: , X-List-Received-Date: Tue, 18 Jan 2011 15:15:08 -0000 * Joe Abley: > I don't think special-use names are a concept of the DNS in the > protocol sense, but rather a set of administrative conventions. LOCAL. is very much protocol-enshrined, but I think it has been reserved neither by IETF nor IANA. Would any other reserved name share a similar fate? Then you might be right in the sense that the IETF cannot set aside names for use at the protocol level. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jabley@hopcount.ca Tue Jan 18 07:18:26 2011 Return-Path: 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 8B07928C15A; Tue, 18 Jan 2011 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wEqOAcCC3bzc; Tue, 18 Jan 2011 07:18:25 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id A17C828C125; Tue, 18 Jan 2011 07:18:25 -0800 (PST) Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfDQq-000FZa-Rp; Tue, 18 Jan 2011 15:25:19 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <82k4i2ckbt.fsf@mid.bfk.de> Date: Tue, 18 Jan 2011 10:20:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F32DBBE-6CAD-45EE-9215-2C5022566139@hopcount.ca> References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> <82k4i2ckbt.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.28 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 18 Jan 2011 09:12:33 -0800 Cc: dnsop@ietf.org, dnsext@ietf.org, IETF Directorate DNS Subject: Re: [dns-dir] [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard 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: , X-List-Received-Date: Tue, 18 Jan 2011 15:18:26 -0000 On 2011-01-18, at 10:17, Florian Weimer wrote: > * Joe Abley: >=20 >> I don't think special-use names are a concept of the DNS in the >> protocol sense, but rather a set of administrative conventions. >=20 > LOCAL. is very much protocol-enshrined, but I think it has been > reserved neither by IETF nor IANA. Would any other reserved name > share a similar fate? Then you might be right in the sense that the > IETF cannot set aside names for use at the protocol level. You're right. I was actually referring to special-use names which have = been specified at the IETF to date rather than those that are in the = process of being specified, but that wasn't clear in the words I used. (I appreciate that in the sense of widespread deployment and = implementation bonjour is clearly extremely specified, but in an IETF = context the work is still ongoing, I think). Joe= From ogud@ogud.com Wed Jan 19 11:37:22 2011 Return-Path: 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 A4CF23A7192 for ; Wed, 19 Jan 2011 11:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nkSumOqW-Frx for ; Wed, 19 Jan 2011 11:37:21 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E7A2C3A6F6C for ; Wed, 19 Jan 2011 11:37:20 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0JJe1iR008532 for ; Wed, 19 Jan 2011 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 19 Jan 2011 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110119_194001_091406.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-decade-survey-03.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:37:22 -0000 Count: 14 DECADE R. Alimi, Ed. Internet-Draft Google Intended status: Informational A. Rahman, Ed. Expires: July 22, 2011 InterDigital Communications, LLC Y. Yang, Ed. Yale University January 18, 2011 A Survey of In-network Storage Systems draft-ietf-decade-survey-03 Abstract This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. From ogud@ogud.com Thu Jan 20 11:37:18 2011 Return-Path: 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 77FBC3A67EF for ; Thu, 20 Jan 2011 11:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hjfEJr3dwjsr for ; Thu, 20 Jan 2011 11:37:17 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 92D9C3A67BD for ; Thu, 20 Jan 2011 11:37:17 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0KJe0o1017204 for ; Thu, 20 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 20 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110120_194000_056754.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-behave-64-analysis-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: , X-List-Received-Date: Thu, 20 Jan 2011 19:37:18 -0000 Count: 36 Behavior Engineering for Hindrance R. Penno Avoidance Juniper Networks Internet-Draft T. Saxena Intended status: Informational Cisco Systems Expires: July 23, 2011 M. Boucadair France Telecom S. Sivakumar Cisco Systems January 19, 2011 Analysis of 64 Translation draft-ietf-behave-64-analysis-00 Abstract Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. From ogud@ogud.com Wed Jan 26 11:37:01 2011 Return-Path: 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 CA12D3A6822 for ; Wed, 26 Jan 2011 11:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pxbErFim2V1W for ; Wed, 26 Jan 2011 11:37:01 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0F0B73A687D for ; Wed, 26 Jan 2011 11:36:59 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0QJe0vV068614 for ; Wed, 26 Jan 2011 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 26 Jan 2011 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110126_194000_019030.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-jiang-ipv6-site-renum-guideline-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: , X-List-Received-Date: Wed, 26 Jan 2011 19:37:01 -0000 Count: 29 Network Working Group S. Jiang Internet Draft B. Liu Intended status: Best Current Practice Huawei Technologies Co., Ltd Expires: August 5, 2011 January 26, 2011 IPv6 Site Renumbering Guidelines and Further Works draft-jiang-ipv6-site-renum-guideline-00.txt Abstract This document analyzes the existing issues for IPv6 site renumbering. It also analyzes the possible directions to solve these issues and gives recommendations. This document only takes the perspective of network and network protocols. Renumbering in IPv4 networks, in the dual-stack network or in the IPv4/IPv6 transition networks are out of scope. This document only takes the perspective of network and network protocols. According to the different stages, these issues are described in three categories: considerations during network design, considerations for routine network management, and considerations during renumbering operation. Recommended solutions or strategies are also described. Issues that still remain unsolvable are listed as the fourth category. Although we list a few non-network issues in this document, we consider them as issues that ISPs or network providers cannot affect. So, these issues are considered to be unsolvable and not explore further in these document, though they may be solved by OS implementations or application implementations. We summary the requests that need to extend current protocols as further works at the end of this document. From ogud@ogud.com Wed Jan 26 11:37:02 2011 Return-Path: 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 1174E3A6822 for ; Wed, 26 Jan 2011 11:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5ay50dWw1tdT for ; Wed, 26 Jan 2011 11:37:01 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AB3C13A6886 for ; Wed, 26 Jan 2011 11:37:00 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0QJe1Tq068623 for ; Wed, 26 Jan 2011 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 26 Jan 2011 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20110126_194001_091835.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-lefaucheur-cdni-requirements-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: , X-List-Received-Date: Wed, 26 Jan 2011 19:37:02 -0000 Count: 36 Network Working Group F. Le Faucheur Internet-Draft M. Viveganandhan Intended status: Informational Cisco Expires: July 30, 2011 G. Watson BT Y. Lee Comcast January 26, 2011 Content Distribution Network Interconnection (CDNI) Requirements draft-lefaucheur-cdni-requirements-00 Abstract Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The "CDN Interconnect Problem Statement" Internet-Draft outlines the problem area for the IETF with a view towards creating a working group. This working group would work on an interoperable and scalable solution for CDN interconnection. The goal of the present document is to start outlining the requirements for such a "CDN Interconnection" solution. From dromasca@avaya.com Fri Jan 28 03:30:29 2011 Return-Path: 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 589A83A67CC; Fri, 28 Jan 2011 03:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 67a58iujSBhl; Fri, 28 Jan 2011 03:30:28 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id DE8643A67B3; Fri, 28 Jan 2011 03:30:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMM3Qk3GmAcF/2dsb2JhbAClAHOiMwKZJ4VPBJAG X-IronPort-AV: E=Sophos;i="4.60,391,1291611600"; d="scan'208";a="261969735" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jan 2011 06:33:24 -0500 X-IronPort-AV: E=Sophos;i="4.60,391,1291611600"; d="scan'208";a="575659080" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2011 06:33:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 12:33:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 3, 2011 IESG Teleconference Thread-Index: Acu+drnSBo4jfz5dQ8ufF0ZijBRjjgAaBq9Q From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 3, 2011 IESG Teleconference 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: , X-List-Received-Date: Fri, 28 Jan 2011 11:30:29 -0000 Please find below the preliminary agenda of the 2/3 IESG telechat. Please send me your comments, questions or concerns about the documents and charters brought up for approval before 2/2 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ltans-xmlers-11 Extensible Markup Language Evidence Record Syntax (Proposed Standard) Note: Carl Wallace is the document sheperd Token: Tim Polk Was deferred by Peter Saint-Andre on 2011-01-19 o draft-ietf-pmol-metrics-framework-07 Guidelines for Considering New Performance Metric Development (BCP) Note: Al Morton (acmorton@att.com) is the document shepherd. Token: Dan Romascanu 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-turner-additional-new-asn-06 Additional New ASN.1 Modules (Proposed Standard) Token: Tim Polk o draft-turner-cms-symmetrickeypackage-algs-00 Algorithms for Cryptographic Message Syntax (CMS)=20 Protection of Symmetric Key Package Content Types (Proposed Standard) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Tim Polk 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-speermint-architecture-17 Session PEERing for Multimedia INTerconnect Architecture (Informational) Note: Document Shepherd: Jason Livingood (Jason_Livingood@cable.comcast.com) Token: Gonzalo Camarillo o draft-morton-ippm-rfc4148-obsolete-03 RFC 4148 and the IPPM Metrics Registry are Obsolete (Informational) Note: Document shepherd is Henk Uijterwaal (henk@ripe.net). Token: Lars Eggert 3.1.2 Returning Items o draft-ietf-nsis-tunnel-13 NSIS Operation Over IP Tunnels (Experimental) Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi). Token: Lars Eggert 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-groves-eccsi-00 Elliptic Curve-based Certificate-less Signatures for Identifier Based Encryption (ECCSI) (Informational) Token: Tim Polk o draft-groves-mikey-sakke-00 MIKEY-SAKKE: Sakai-Kasahara Key Exchange in Multimedia Internet KEYing (MIKEY) (Informational) Token: Tim Polk o draft-groves-sakke-00 Sakai-Kasahara Key Establishment (SAKKE) (Informational) Token: Tim Polk o draft-turner-sha0-sha1-seccon-03 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms (Informational) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Peter Saint-Andre 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-irtf-rrg-design-goals-06 Design Goals for Scalable Internet Routing (Informational) Note: Independent submission via IRTF. Joel Halpern (jmh@joelhalpern.com) is the document shepherd. Token: Jari Arkko o draft-irtf-dtnrg-sdnv-08 Using Self-Delimiting Numeric Values in Protocols (Informational) Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley o draft-irtf-dtnrg-bundle-security-17 Bundle Security Protocol Specification (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley o draft-irtf-dtnrg-cbhe-08 Compressed Bundle Header Encoding (CBHE) (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley o draft-irtf-dtnrg-bundle-metadata-block-09 Delay-Tolerant Networking Metadata Extension Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley o draft-irtf-dtnrg-bundle-previous-hop-block-12 Delay-Tolerant Networking Previous Hop Insertion Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley o draft-irtf-dtnrg-iana-bp-registries-01 Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Light-Weight Implementation Guidance (lwig) Token: Jari From narten@us.ibm.com Mon Jan 31 08:55:20 2011 Return-Path: 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 ECDD83A6C49 for ; Mon, 31 Jan 2011 08:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OO16RMCQ+Q1f for ; Mon, 31 Jan 2011 08:55:17 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 351DD3A6C50 for ; Mon, 31 Jan 2011 08:55:17 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0VGtrML013749 for ; Mon, 31 Jan 2011 09:55:53 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0VGwN5v144268 for ; Mon, 31 Jan 2011 09:58:23 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0VGwMUD022045 for ; Mon, 31 Jan 2011 09:58:22 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-255-188.mts.ibm.com [9.65.255.188]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0VGwKgK021907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 09:58:22 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p0VGwGtW007547; Mon, 31 Jan 2011 11:58:17 -0500 Message-Id: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> To: dns directorate Date: Mon, 31 Jan 2011 11:58:16 -0500 From: Thomas Narten Cc: Suzanne Woolf , Joe Abley Subject: [dns-dir] .eg DNS 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: , X-List-Received-Date: Mon, 31 Jan 2011 16:55:20 -0000 There have obviously been lots of discussions about the situation in Egypt. Internet essentially doesn't work in Egypt, and there is no connectivity into Egypt from outside. >From a DNS perspective, what are the key things that we need to pay attention to? (I'm trying to get the facts straight in my conversations with the ICANN board, to be sure people are acting on facts, rather than assumptions). My understanding is that when DNS names for .eg requested, root servers respond with an NS RR pointing to the authoritative servers for eg. I.e.,: > [cichlid] ~ 121 >dig -t soa eg. @l.root-servers.net > > ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg. @l.root-servers.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60919 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;eg. IN SOA > > ;; AUTHORITY SECTION: > eg. 172800 IN NS ns5.univie.ac.at. > eg. 172800 IN NS rip.psg.com. > eg. 172800 IN NS frcu.eun.eg. > > ;; ADDITIONAL SECTION: > ns5.univie.ac.at. 172800 IN A 193.171.255.77 > rip.psg.com. 172800 IN A 147.28.0.39 > frcu.eun.eg. 172800 IN A 193.227.1.1 > rip.psg.com. 172800 IN AAAA 2001:418:1::39 > > ;; Query time: 44 msec > ;; SERVER: 199.7.83.42#53(199.7.83.42) > ;; WHEN: Mon Jan 31 11:33:10 2011 > ;; MSG SIZE rcvd: 176 The root zone will serve this data indefinitely, until such time as the zone file is updated. This only happens as a result of an explicit IANA action, going through NTIA and VRSN. Consequently, there is no implication to root servers w.r.t. events in Egypt. They will continue serving the current data indefinitely. At the next level, the SOA returned by authoritative servers is as follows: [cichlid] ~ 122 >dig -t soa eg @RIP.PSG.COM. > ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg @RIP.PSG.COM. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50526 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;eg. IN SOA > > ;; ANSWER SECTION: > eg. 604800 IN SOA FRCU.EUN.eg. Postmaster.FRCU.EUN.eg. 2010100421 15000 7200 12096000 86400 > > ;; AUTHORITY SECTION: > eg. 604800 IN NS RIP.PSG.COM. > eg. 604800 IN NS NS5.UNIVIE.AC.AT. > eg. 604800 IN NS FRCU.EUN.eg. > > ;; ADDITIONAL SECTION: > FRCU.EUN.eg. 86400 IN A 193.227.1.1 > > ;; Query time: 132 msec > ;; SERVER: 147.28.0.39#53(147.28.0.39) > ;; WHEN: Mon Jan 31 11:36:30 2011 > ;; MSG SIZE rcvd: 161 Key thing of note. The SOA "expire" time is 12096000 seconds, which translates to 140 days. If a secondary cannot contact the primary within this time, the zone is considered old and the secondary stops being authoritative. I.e., its stops serving the data. Also, when responding to general RR queries, authoritative servers always return the TTL associated with the RRset. I.e., they do not decrement TTLs over time as the zone becomes closer to "expiring". Thus, assuming that the primary servers for eg remain unreachable indefinitely, we have 140 days (from Friday) before DNS queries stop resolving. Do I have the above details right? Is there anything else to note or worry about at this point from a DNS perspective? Thomas From roy@dnss.ec Mon Jan 31 09:25:32 2011 Return-Path: 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 214AD3A699E for ; Mon, 31 Jan 2011 09:25:32 -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 7I4wZG-kQ510 for ; Mon, 31 Jan 2011 09:25:30 -0800 (PST) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 7BD1A3A67F0 for ; Mon, 31 Jan 2011 09:25:30 -0800 (PST) Received: from roy.nominet.org.uk (host-213-248-204-24.nominet.org.uk [213.248.204.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id C9DBE2D56B; Mon, 31 Jan 2011 18:28:43 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Roy Arends In-Reply-To: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> Date: Mon, 31 Jan 2011 17:28:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <448C71F0-0C71-4C44-8262-BEE6472DB744@dnss.ec> References: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: Suzanne Woolf , dns directorate , Joe Abley Subject: Re: [dns-dir] .eg DNS 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: , X-List-Received-Date: Mon, 31 Jan 2011 17:25:32 -0000 On Jan 31, 2011, at 4:58 PM, Thomas Narten wrote: > There have obviously been lots of discussions about the situation in > Egypt. Internet essentially doesn't work in Egypt, and there is no > connectivity into Egypt from outside. >=20 > =46rom a DNS perspective, what are the key things that we need to pay > attention to? (I'm trying to get the facts straight in my > conversations with the ICANN board, to be sure people are acting on > facts, rather than assumptions). >=20 > My understanding is that when DNS names for .eg requested, root > servers respond with an NS RR pointing to the authoritative servers > for eg. I.e.,: >=20 >> [cichlid] ~ 121 >dig -t soa eg. @l.root-servers.net >>=20 >> ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg. = @l.root-servers.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60919 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 >> ;; WARNING: recursion requested but not available >>=20 >> ;; QUESTION SECTION: >> ;eg. IN SOA >>=20 >> ;; AUTHORITY SECTION: >> eg. 172800 IN NS ns5.univie.ac.at. >> eg. 172800 IN NS rip.psg.com. >> eg. 172800 IN NS frcu.eun.eg. >>=20 >> ;; ADDITIONAL SECTION: >> ns5.univie.ac.at. 172800 IN A 193.171.255.77 >> rip.psg.com. 172800 IN A 147.28.0.39 >> frcu.eun.eg. 172800 IN A 193.227.1.1 >> rip.psg.com. 172800 IN AAAA 2001:418:1::39 >>=20 >> ;; Query time: 44 msec >> ;; SERVER: 199.7.83.42#53(199.7.83.42) >> ;; WHEN: Mon Jan 31 11:33:10 2011 >> ;; MSG SIZE rcvd: 176 >=20 > The root zone will serve this data indefinitely, until such time as > the zone file is updated. This only happens as a result of an explicit > IANA action, going through NTIA and VRSN. Consequently, there is no > implication to root servers w.r.t. events in Egypt. They will continue > serving the current data indefinitely. >=20 > At the next level, the SOA returned by authoritative servers is as > follows: >=20 > [cichlid] ~ 122 >dig -t soa eg @RIP.PSG.COM. >=20 >> ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg = @RIP.PSG.COM. >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50526 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1 >> ;; WARNING: recursion requested but not available >>=20 >> ;; QUESTION SECTION: >> ;eg. IN SOA >>=20 >> ;; ANSWER SECTION: >> eg. 604800 IN SOA FRCU.EUN.eg. = Postmaster.FRCU.EUN.eg. 2010100421 15000 7200 12096000 86400 >>=20 >> ;; AUTHORITY SECTION: >> eg. 604800 IN NS RIP.PSG.COM. >> eg. 604800 IN NS NS5.UNIVIE.AC.AT. >> eg. 604800 IN NS FRCU.EUN.eg. >>=20 >> ;; ADDITIONAL SECTION: >> FRCU.EUN.eg. 86400 IN A 193.227.1.1 >>=20 >> ;; Query time: 132 msec >> ;; SERVER: 147.28.0.39#53(147.28.0.39) >> ;; WHEN: Mon Jan 31 11:36:30 2011 >> ;; MSG SIZE rcvd: 161 >=20 > Key thing of note. The SOA "expire" time is 12096000 seconds, which > translates to 140 days. If a secondary cannot contact the primary > within this time, the zone is considered old and the secondary stops > being authoritative. I.e., its stops serving the data. That is correct. The 140 days translates to June 16th (calculated from = the day the routes changed). Gerhard Winkler (univie.ac.at) informed me = he keeps a local copy of the zone in case he needs to change from = Secondary to Primary. > Also, when responding to general RR queries, authoritative servers > always return the TTL associated with the RRset. I.e., they do not > decrement TTLs over time as the zone becomes closer to "expiring".=20 Indeed. both secondaries are responding, and the primary (frcu.eun.eg) = is unreachable. Meanwhile, the registry itself is unreachable as well. > Thus, assuming that the primary servers for eg remain unreachable > indefinitely, we have 140 days (from Friday) before DNS queries stop > resolving. Correct. > Do I have the above details right? Is there anything else to note or > worry about at this point from a DNS perspective? I've looked at various TLD zones to look for nameservers hosted from EG = (in both the EG namespace as well as IP addresses unreachable due to = routes) and there are a few non specific. (No eg. nameserver names in = the co.uk or org.uk zones). Hope this helps, Roy From olaf@NLnetLabs.nl Mon Jan 31 11:13:32 2011 Return-Path: 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 5509B3A6C40 for ; Mon, 31 Jan 2011 11:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 l4gyuEMxOyxB for ; Mon, 31 Jan 2011 11:13:30 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id C4AA13A6C3F for ; Mon, 31 Jan 2011 11:13:29 -0800 (PST) Received: from aagje.fritz.box ([IPv6:2001:980:2282:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p0VJGaWO077328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Jan 2011 20:16:37 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-2-366616766; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> Date: Mon, 31 Jan 2011 20:16:36 +0100 Message-Id: References: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 31 Jan 2011 20:16:39 +0100 (CET) Cc: Suzanne Woolf , dns directorate , Joe Abley Subject: Re: [dns-dir] .eg DNS 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: , X-List-Received-Date: Mon, 31 Jan 2011 19:13:32 -0000 --Apple-Mail-2-366616766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 31, 2011, at 5:58 PM, Thomas Narten wrote: > There have obviously been lots of discussions about the situation in > Egypt. Internet essentially doesn't work in Egypt, and there is no > connectivity into Egypt from outside. >=20 >> =46rom a DNS perspective, what are the key things that we need to pay > attention to? (I'm trying to get the facts straight in my > conversations with the ICANN board, to be sure people are acting on > facts, rather than assumptions). >=20 > My understanding is that when DNS names for .eg requested, root > servers respond with an NS RR pointing to the authoritative servers > for eg. I.e.,: >=20 >> [cichlid] ~ 121 >dig -t soa eg. @l.root-servers.net >>=20 >> ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg. = @l.root-servers.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60919 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 >> ;; WARNING: recursion requested but not available >>=20 >> ;; QUESTION SECTION: >> ;eg. IN SOA >>=20 >> ;; AUTHORITY SECTION: >> eg. 172800 IN NS ns5.univie.ac.at. >> eg. 172800 IN NS rip.psg.com. >> eg. 172800 IN NS frcu.eun.eg. >>=20 >> ;; ADDITIONAL SECTION: >> ns5.univie.ac.at. 172800 IN A 193.171.255.77 >> rip.psg.com. 172800 IN A 147.28.0.39 >> frcu.eun.eg. 172800 IN A 193.227.1.1 >> rip.psg.com. 172800 IN AAAA 2001:418:1::39 >>=20 >> ;; Query time: 44 msec >> ;; SERVER: 199.7.83.42#53(199.7.83.42) >> ;; WHEN: Mon Jan 31 11:33:10 2011 >> ;; MSG SIZE rcvd: 176 >=20 > The root zone will serve this data indefinitely, until such time as > the zone file is updated. This only happens as a result of an explicit > IANA action, going through NTIA and VRSN. Consequently, there is no > implication to root servers w.r.t. events in Egypt. They will continue > serving the current data indefinitely. >=20 > At the next level, the SOA returned by authoritative servers is as > follows: >=20 > [cichlid] ~ 122 >dig -t soa eg @RIP.PSG.COM. >=20 >> ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg = @RIP.PSG.COM. >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50526 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1 >> ;; WARNING: recursion requested but not available >>=20 >> ;; QUESTION SECTION: >> ;eg. IN SOA >>=20 >> ;; ANSWER SECTION: >> eg. 604800 IN SOA FRCU.EUN.eg. = Postmaster.FRCU.EUN.eg. 2010100421 15000 7200 12096000 86400 >>=20 >> ;; AUTHORITY SECTION: >> eg. 604800 IN NS RIP.PSG.COM. >> eg. 604800 IN NS NS5.UNIVIE.AC.AT. >> eg. 604800 IN NS FRCU.EUN.eg. >>=20 >> ;; ADDITIONAL SECTION: >> FRCU.EUN.eg. 86400 IN A 193.227.1.1 >>=20 >> ;; Query time: 132 msec >> ;; SERVER: 147.28.0.39#53(147.28.0.39) >> ;; WHEN: Mon Jan 31 11:36:30 2011 >> ;; MSG SIZE rcvd: 161 >=20 > Key thing of note. The SOA "expire" time is 12096000 seconds, which > translates to 140 days. If a secondary cannot contact the primary > within this time, the zone is considered old and the secondary stops > being authoritative. I.e., its stops serving the data. >=20 > Also, when responding to general RR queries, authoritative servers > always return the TTL associated with the RRset. I.e., they do not > decrement TTLs over time as the zone becomes closer to "expiring".=20 >=20 > Thus, assuming that the primary servers for eg remain unreachable > indefinitely, we have 140 days (from Friday) before DNS queries stop > resolving. >=20 Almost, operators of the individual nameservers may override the Expiry = date and choose to serve data that they happen to have. Note that that = is a choice of the operators, not of ICANN IMHO. If you want to know = what PSG.com would do you could ask Randy Bush. > Do I have the above details right? Is there anything else to note or > worry about at this point from a DNS perspective? In a DNSSEC enabled environment serving an Expired zone would not be = possible after the signatures expired. I that case IANA could take an = action by pulling the DS. I currently believe that in geo-political = turmoil as we see now IANA should never do that. In the case of natural = disaster the case may be slightly different, but that seems something = where IANA could make bilateral service level agreements about. --Olaf ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-2-366616766 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMTMxMTkxNjM2WjAj BgkqhkiG9w0BCQQxFgQUsIECCYiuy1f4+Jq4dBfcbXQggvkwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAECLtB2Bz90MNyeHvUJQaVDZLw3C5mPbmaoVNtKfu3M+dOhblR7ye568nPxCLDfC NUH3lisvqvbyiV6fzew6vKmZdiJ2ZJohuWlwtsLZMyLsIQiTpWpfyPZ3FKLBErva2dU3mTKbZ2+s rE+ljDEYjI+JJ+DRspqKtF+4O/A6A90kdFxZgSQXc7S3C+CKjZjJh6+128K1XDzYBXI1IvrpmrwC HQw5dKhmOqxn4O6/nakqhNn6ye0zPJKeAxK9ZHcTnJ31LBTftr+yjnWsBoFS58DcfuYWC2cgdZon 8EDuvaB5C2r4HjcYb05OHZsiovj5Tg38gErV0JHLeLgwzJnJvjcAAAAAAAA= --Apple-Mail-2-366616766-- From olaf@NLnetLabs.nl Mon Jan 31 11:49:28 2011 Return-Path: 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 001683A6C61 for ; Mon, 31 Jan 2011 11:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 9SPavif6G2yZ for ; Mon, 31 Jan 2011 11:49:27 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 0CB8A3A6C57 for ; Mon, 31 Jan 2011 11:49:25 -0800 (PST) Received: from aagje.fritz.box ([IPv6:2001:980:2282:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p0VJqZbG088990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Jan 2011 20:52:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-8-368775134; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Mon, 31 Jan 2011 20:52:34 +0100 Message-Id: <507BDF7A-6451-40A3-A9FB-217C035AE7E8@NLnetLabs.nl> References: <201101311658.p0VGwGtW007547@cichlid.raleigh.ibm.com> To: Joe Abley X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 31 Jan 2011 20:52:35 +0100 (CET) Cc: Thomas Narten , Suzanne Woolf , dns directorate Subject: Re: [dns-dir] .eg DNS 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: , X-List-Received-Date: Mon, 31 Jan 2011 19:49:28 -0000 --Apple-Mail-8-368775134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 31, 2011, at 8:20 PM, Joe Abley wrote: >>=20 >> In a DNSSEC enabled environment serving an Expired zone would not be = possible after the signatures expired. I that case IANA could take an = action by pulling the DS. I currently believe that in geo-political = turmoil as we see now IANA should never do that. In the case of natural = disaster the case may be slightly different, but that seems something = where IANA could make bilateral service level agreements about. >=20 > ICANN has staff in Egypt (Baher Esmat) who currently has internet = access via modem and international phone call to Europe, and has a = satellite phone for voice communications. I suspect a trusted = communications channel to the EG manager could be arranged via Baher if = it turned out it was needed to authenticate a root zone change for EG. >=20 Fair enough, but that is a bit of a coincidence.=20 > ICANN does not act unilaterally in these cases, but takes direction = from TLD managers. >=20 > (Note also that EG is not signed, so DNSSEC signature expiration is = not a problem in this particular case. For a signed zone, though, = signature expiration is probably a greater concern than zone expiry). Yes, my mail was more a hypothetical and something on which the board, = or the staff may want to develop some guidelines. Oh, not acting Unilaterally is obviously a very good guiding principle = (stronger than a guide-line). --Olaf (who thinks we are in violent agreement)=20 ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-8-368775134 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMTMxMTk1MjM1WjAj BgkqhkiG9w0BCQQxFgQUpRGB9NU4YLglui46xM7kJQd970UwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAHZETj+S5BMexa1n8f5BHlwO+MhwHR6rdcO2ZlngRkhgMZgT9w0/EJJdH/gnGvaW 486vXhRKIpmKeGX/2N4XMADWAZ3dujptFtoyo/wlxyvfMkzvbn0qyKiAEyC50SgymHSU6gR/TuiP emewlXnQcx1PTMwaHa18aaWBKaF2TEqo2vhiK5ettK4oNteQjRwhEKHvSnv1oc16oUwQXQK21Yct 0OPyi9vWzLzL1IfWotWN4fnJK5L/gXrKu93hKKto7ZcrD0wfeKTSxHrj9IdO1kVIrjv6Q0zKXKK5 tqblOyAWj50JIkyBLPLEG2oAk7qpuVbM0qx9f+Sbe/g3m6bLD38AAAAAAAA= --Apple-Mail-8-368775134--