From dromasca@avaya.com Wed Dec 9 01:57:14 2009 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 4C6813A6944; Wed, 9 Dec 2009 01:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 YpocYsQyhW1R; Wed, 9 Dec 2009 01:57:13 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id B2DC23A6781; Wed, 9 Dec 2009 01:57:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,367,1257138000"; d="scan'208";a="183281552" Received: from unknown (HELO p-us1-erhlab.us1.avaya.com) ([135.11.50.35]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Dec 2009 04:56:58 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erhlab-out.us1.avaya.com with ESMTP; 09 Dec 2009 04:56: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, 9 Dec 2009 10:56:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] WG Review: Multiple AoR reachabiliTy InformatioN Indication (MARTINI) Thread-Index: Acp4Yomey5PPN8SFRECVfEYO447QVwAUxFhA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , Subject: [dns-dir] FW: [martini] WG Review: Multiple AoR reachabiliTy InformatioN Indication (MARTINI) 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, 09 Dec 2009 09:57:14 -0000 =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, December 09, 2009 2:00 AM To: ietf-announce@ietf.org Cc: martini@ietf.org Subject: [martini] WG Review: Multiple AoR reachabiliTy InformatioN Indication (MARTINI) 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, December 15, 2009. Multiple AoR reachabiliTy InformatioN Indication (MARTINI) ----------------------------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2009-12-08 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Mailing Lists: General Discussion: martini@ietf.org To Subscribe: martini-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Description of Working Group The MARTINI working group is chartered to specify a means by which an entity that is authoritative for SIP URIs can dynamically register reachability information for multiple Addresses of Record ("AORs") with a service provider. The SIP protocol [RFC 3261 and its extensions] supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP Proxy needs to send a request to a target AOR within its domain, it can use a location service to obtain the registered contact URI, together with any associated path information [RFC 3327], and build a route set to reach the target UA(s). The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a request to a target for which it is not authoritative, the UA/Proxy can use RFC3263 procedures for using DNS to resolve the next-hop connection information. In practice, many small and medium-sized businesses use a SIP-PBX that is authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service Provider (SSP) provides SIP peering/trunking capability to the SIP PBX. The SIP-PBX must be reachable from the SSP so that the SSP can route inbound SIP requests for the AoRs addressed to the SIP PBX, routing these requests to the SIP-PBX itself for onward delivery to registered UAs. Experience has shown that existing mechanisms are not always sufficient to support SIP-PBXs for small/medium businesses. Since a single SSP may support multiple thousands of such SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provision their IP addresses in every SIP node along paths to those SIP-PBXs. Furthermore, IP addresses can be dynamically assigned and therefore can potentially change relatively frequently. In current deployments, dynamic reachability mechanisms based on the SIP REGISTER method are commonly used. Effectively, a single REGISTER request registers the AoR of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI for which the SIP-PBX is authoritative can be delivered from the SSP to the SIP-PBX. However, implementations of this mechanism vary in details, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. The task of this working group is to to standardize a multiple-AoR registration mechanism for SIP that can be widely deployed by service providers at large scale. The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included. The solution will utilize existing SIP mechanisms to the extent possible, although it is anticipated that small protocol extensions are likely to be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not precluded from use in the context of multiple AoR registrations. The solution will incorporate a compatibility mechanism to ensure a deterministic outcome when interworking with entities that do not support multiple AoR registration. The working group will coordinate with SIP Forum and other industry groups on requirements and will coordinate its work with other IETF working groups including DRINKS and SIPCORE. Goals and Milestones Dec 2009 Solicit solution-space drafts Jan 2010 Interim meeting Jan 2010 Adopt Working Group draft Feb 2010 First Working Group Last Call Mar 2010 Second Working Group Last Call Apr 2010 Multiple AoR Registration specification to IESG (PS) Jul 2010 Close or recharter working group _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From dromasca@avaya.com Thu Dec 10 22:45:59 2009 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 26C1F3A6811; Thu, 10 Dec 2009 22:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 3sdqKkrVm0oU; Thu, 10 Dec 2009 22:45:51 -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 BEF683A67FD; Thu, 10 Dec 2009 22:45:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,380,1257138000"; d="scan'208";a="193593623" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Dec 2009 01:45:34 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Dec 2009 01:45:33 -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, 11 Dec 2009 07:45:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for December 17, 2009 Telechat Thread-Index: Acp58UMaPRVy4M9ERbaZuGFzipQrrQAO973A From: "Romascanu, Dan (Dan)" To: , , , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for December 17, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 06:45:59 -0000 Please find below the preliminary agenda of the 12/17 IESG telechat. Please send me your questions, comments and concerns before 12/16 COB. Thanks and Regards, Dan =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tsvwg-admitted-realtime-dscp-06.txt DSCP for Capacity-Admitted Traffic (Proposed Standard) - 1 of 10=20 Token: Magnus Westerlund o draft-ietf-rohc-ipsec-extensions-hcoipsec-06.txt IPsec Extensions to Support Robust Header Compression over IPsec=20 (ROHCoIPsec) (Proposed Standard) - 2 of 10=20 Note: Doc Shepherd Carl Knutsson (WG chair). Review=20 draft-ietf-rohc-hcoipsec before this one.=20 Token: Magnus Westerlund o draft-ietf-rohc-ikev2-extensions-hcoipsec-10.txt IKEv2 Extensions to Support Robust Header Compression over IPsec=20 (ROHCoIPsec) (Proposed Standard) - 3 of 10=20 Note: Doc Shepherd Carl Knutsson (WG chair). Review=20 draft-ietf-rohc-hcoipsec before this one.=20 Token: Magnus Westerlund o draft-ietf-l3vpn-2547bis-mcast-09.txt Multicast in MPLS/BGP IP VPNs (Proposed Standard) - 4 of 10=20 Token: Ross Callon o draft-ietf-ipsecme-traffic-visibility-11.txt Wrapped ESP for Traffic Visibility (Proposed Standard) - 5 of 10=20 Note: Yaron Sheffer (yaronf@checkpoint.com) is the document shepherd. Token: Pasi Eronen o draft-ietf-ccamp-confirm-data-channel-status-08.txt Data Channel Status Confirmation Extensions for the Link Management=20 Protocol (Proposed Standard) - 6 of 10=20 Note: Lou Berger (lberger@labn.net) is the document shepherd.=20 Token: Adrian Farrel o draft-ietf-l3vpn-ospfv3-pece-04.txt OSPFv3 as a PE-CE routing protocol (Proposed Standard) - 7 of 10=20 Token: Ross Callon o draft-ietf-morg-status-in-list-01.txt IMAP4 Extension for returning STATUS information in extended LIST (Proposed=20 Standard) - 8 of 10=20 Token: Lisa Dusseault o draft-ietf-rohc-rfc4995bis-02.txt The RObust Header Compression (ROHC) Framework (Proposed Standard) - 9 of=20 10=20 Note: Carl Knutsson (carl.knutsson@effnet.com) is the document shepherd=20 Token: Magnus Westerlund o draft-ietf-tls-renegotiation-01.txt Transport Layer Security (TLS) Renegotiation Indication Extension (Proposed=20 Standard) - 10 of 10=20 Token: Pasi Eronen 2.1.2 Returning Item o draft-ietf-ipfix-mib-09.txt Definitions of Managed Objects for IP Flow Information Export (Proposed=20 Standard) - 1 of 1=20 Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Item o draft-klensin-ftp-registry-03.txt FTP Command and Extension Registry (Proposed Standard) - 1 of 3=20 Note: Barry Leiba is the document=20 shepherd.. Note that as per latest revision, references to documents defining FTP extensions are now Informational.=20 Token: Alexey Melnikov o draft-nottingham-site-meta-04.txt Defining Well-Known URIs (Proposed Standard) - 2 of 3=20 Token: Lisa Dusseault o draft-melnikov-imap-keywords-09.txt IMAP4 Keyword Registry (Proposed Standard) - 3 of 3=20 Note: Barry Leiba is the document shepherd.=20 Token: Lisa Dusseault 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-rohc-hcoipsec-12.txt Integration of Robust Header Compression (ROHC) over IPsec Security=20 Associations (Informational) - 1 of 2=20 Note: Document shepherd: Carl Knutsson (WG chair)=20 Token: Magnus Westerlund o draft-ietf-tcpm-early-rexmt-03.txt Early Retransmit for TCP and SCTP (Experimental) - 2 of 2=20 Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Lars Eggert 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-weiler-rsync-uri-01.txt The rsync URI Scheme (Informational) - 1 of 1=20 Token: Ross Callon 3.2.2 Returning Item o draft-cheshire-dnsext-multicastdns-08.txt Multicast DNS (Informational) - 1 of 1=20 Token: Ralph Droms 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-spencer-usefor-son-of-1036-01.txt "Son of 1036": News Article Format and Transmission (Historic) - 1 of 1=20 Note: This document is submitted for publication via the RFC3932 process=20 with *no note*. None of the notes are accurate since this is being=20 published as Historic, and this should be in line with future practice with=20 independent stream documents.=20 Token: Lisa Dusseault 3.3.2 Returning Item o draft-hajjeh-tls-identity-protection-09.txt Credential Protection Ciphersuites for Transport Layer Security (TLS) (Experimental) - 1 of 2=20 Note: This is a second 3932(bis) check - remember to re-enter your ballot=20 position.=20 Token: Pasi Eronen o draft-zeilenga-ldap-txn-15.txt LDAP Transactions (Experimental) - 2 of 2=20 Token: Alexey Melnikov 3.3.3 For Action o draft-dolmatov-cryptocom-gost34102001-07.txt GOST R 34.10-2001 digital signature algorithm (Informational) - 1 of 3 =20 Token: Russ Housley o draft-dolmatov-cryptocom-gost341194-06.txt GOST R 34.11-94 Hash function algorithm (Informational) - 2 of 3=20 Token: Russ Housley o draft-dolmatov-cryptocom-gost2814789-06.txt GOST 28147-89 encryption, decryption and MAC algorithms (Informational) - 3=20 of 3=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o BiDirectional or Server-Initiated HTTP (hybi) - 1 of 2 Token: Lisa Dusseault o Internet Wideband Audio Codec (codec) - 2 of 2 Token: Cullen Jennings 4.1.2 Proposed for Approval o Multiple AoR reachabiliTy InformatioN Indication (martini) - 1 of 1 Token: Cullen Jennings 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From ogud@ogud.com Fri Dec 11 04:45:05 2009 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 A092D3A6842 for ; Fri, 11 Dec 2009 04:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, 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 ww7ll-lVBuZn for ; Fri, 11 Dec 2009 04:45:05 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id CCEDE3A6823 for ; Fri, 11 Dec 2009 04:45:04 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id nBBCikBX005436; Fri, 11 Dec 2009 07:44:47 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200912111244.nBBCikBX005436@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Dec 2009 07:44:43 -0500 To: "Romascanu, Dan (Dan)" , "IETF DNS Directorate" From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for December 17, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 12:45:05 -0000 At 01:45 11/12/2009, Romascanu, Dan (Dan) wrote: >Please find below the preliminary agenda of the 12/17 IESG telechat. >Please send me your questions, comments and concerns before 12/16 COB. > >Thanks and Regards, Only multicastdns shows up in the DNS early warning system. Olafur From rdroms@cisco.com Tue Dec 22 07:33:37 2009 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 9C1133A685E for ; Tue, 22 Dec 2009 07:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqd9Z5asHMSz for ; Tue, 22 Dec 2009 07:33:37 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AC5F33A680D for ; Tue, 22 Dec 2009 07:33:36 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALd1MEtAZnwM/2dsb2JhbAC/RpZvhDME X-IronPort-AV: E=Sophos;i="4.47,436,1257120000"; d="scan'208";a="76028815" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Dec 2009 15:33:17 +0000 Received: from [161.44.65.110] ([161.44.65.110]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBMFXHYf002873 for ; Tue, 22 Dec 2009 15:33:17 GMT Message-Id: From: Ralph Droms To: IETF DNS Directorate Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Dec 2009 10:33:17 -0500 X-Mailer: Apple Mail (2.936) Subject: [dns-dir] draft-ietf-dnsext-dnssec-gost-06 publication requested 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, 22 Dec 2009 15:33:37 -0000 The dnsext WG has requested publication of draft-ietf-dnsext-dnssec- gost-06. I expect to start an IETF last call of the document soon. Please start a secdir review of the draft and thanks... - Ralph From rdroms@cisco.com Tue Dec 22 08:09:08 2009 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 281933A6917 for ; Tue, 22 Dec 2009 08:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0c38nkxTMlX for ; Tue, 22 Dec 2009 08:09:07 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7E36E3A6859 for ; Tue, 22 Dec 2009 08:09:07 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH19MEtAZnwM/2dsb2JhbAC/X5ZwhDME X-IronPort-AV: E=Sophos;i="4.47,437,1257120000"; d="scan'208";a="229954421" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-2.cisco.com with ESMTP; 22 Dec 2009 16:08:51 +0000 Received: from [161.44.65.110] ([161.44.65.110]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBMG7cTe015984 for ; Tue, 22 Dec 2009 16:08:50 GMT Message-Id: <4A99C8E4-3D28-4047-8A97-2A74D2BA90AB@cisco.com> From: Ralph Droms To: IETF DNS Directorate In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Dec 2009 11:08:50 -0500 References: X-Mailer: Apple Mail (2.936) Subject: Re: [dns-dir] draft-ietf-dnsext-dnssec-gost-06 publication requested 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, 22 Dec 2009 16:09:08 -0000 Mis-addressed; please ignore. - Ralph On Dec 22, 2009, at 10:33 AM 12/22/09, Ralph Droms wrote: > The dnsext WG has requested publication of draft-ietf-dnsext-dnssec- > gost-06. I expect to start an IETF last call of the document soon. > Please start a secdir review of the draft and thanks... > > - Ralph > From dromasca@avaya.com Tue Dec 22 10:13:54 2009 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 94B6C3A67FB; Tue, 22 Dec 2009 10:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrJQ1fqgfidP; Tue, 22 Dec 2009 10:13:51 -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 3A1DA3A699E; Tue, 22 Dec 2009 10:13:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,437,1257138000"; d="scan'208";a="168093129" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Dec 2009 13:13:24 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2009 13:13: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: Tue, 22 Dec 2009 19:13:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Messaging Abuse Reporting Format (marf) Thread-Index: AcqDMKcdyRm4ZGUeQdmsxlUZMRHREQAAa6kw From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , Subject: [dns-dir] FW: WG Review: Messaging Abuse Reporting Format (marf) 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, 22 Dec 2009 18:13:54 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, December 22, 2009 8:00 PM To: ietf-announce@ietf.org Cc: abuse-feedback-report@mipassoc.org Subject: WG Review: Messaging Abuse Reporting Format (marf)=20 A new IETF working group has been proposed in the Applications 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 January 12, 2010. Messaging Abuse Reporting Format (marf) --------------------------------------- Last Modified: 12-21-2009 Current Status: Proposed Working Group=20 Chair(s): TBD Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: abuse-feedback-report@mipassoc.org To Subscribe:=20 http://mipassoc.org/mailman/listinfo/abuse-feedback-report Archive: http://mipassoc.org/mailman/listinfo/abuse-feedback-report Description of Working Group: Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure and encourage future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. ARF was developed by a messaging trade organization independent of the IETF, and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. The basic format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility. Furthermore, some extensions to the current proposal are of interest to the community, such as the means for an operator to advertise an email address to which abuse reports using ARF should be sent. The working group will take on the task of considering and specifying such a mechanism. The initial proposal is published as draft-shafranovich-feedback-report, and this will provide the working group's starting point. The working group should consider such factors as: * implementer experience * ability to achieve broad implementation and interoperability * existing uses of ARF * internationalization * ability to address broader use cases than may have be contemplated by the original authors * overlap with the INCH working group's work (e.g. RFC5070); it is unclear whether such overlap is appropriate or should be avoided Thus, the working group's specific tasks are as follows: 1) The group will first produce a Proposed Standard track specification of ARF. This will document current use, removing any portions that are not implemented and/or not required for a minimum implementation (to be published later as extensions). This will include not only the format of an ARF message, but must also include appropriate documentation of security considerations and creation of IANA registries for elements of ARF to support future extensions, as well as informational sections conveying current best practices. 2) The group will specify the integration of ARF into DKIM DNS key records, with draft-kucherawy-dkim-reporting as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing ("fraud") and as such are relevant to the ARF effort. The group will produce Proposed Standard track specification for these ARF and DKIM extensions. 3) The group will finally consider a means for publishing the address to which ARF reports should be sent. Not all ARF participants wish to use abuse@(domain), which is the current standard (RFC2142) , as the place to send automated ARF-formatted reports. The group will either conclude that the industry should continue to use this de facto standard (and thus no specification is appropriate), or will produce a Proposed Standard track document identifying the means by which that address should be advertised. The group may consider re-chartering to cover related work, such as further extensions, once these deliverables have been achieved. The working group is aware of a related activity in another group: - Open Mobile Alliance SpamRep The goal is to coordinate efforts with this group as required. Goals and Milestones: Jan 2010 Issue first WG-based Internet-Draft defining ARF Mar 2010 Achieve consensus on any WG-based changes to ARF Apr 2010 Submit ARF ID to IESG for publication Jun 2010 Issue first WG-based ID for DKIM reporting extensions Sep 2011 Achieve consensus on DKIM reporting extensions draft Nov 2011 Submit DKIM reporting ID to IESG for publication Jan 2011 Issue first WG-based ID for advertising the ARF address Mar 2011 Achieve consensus on ARF address advertising draft Jul 2011 Submit ARF address advertising ID to IESG for publication From dromasca@avaya.com Tue Dec 22 10:15:33 2009 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 4ED743A6A46; Tue, 22 Dec 2009 10:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEmxWfW-lzbn; Tue, 22 Dec 2009 10:15:32 -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 B41033A68AA; Tue, 22 Dec 2009 10:15:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,437,1257138000"; d="scan'208";a="195591534" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Dec 2009 13:15:14 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Dec 2009 13:14:34 -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: Tue, 22 Dec 2009 19:14:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Internationalized Resource Identifiers (iri) Thread-Index: AcqDMI38By4CmyaQReKZlskDQMVuMgAAegqA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , Subject: [dns-dir] FW: WG Review: Internationalized Resource Identifiers (iri) 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, 22 Dec 2009 18:15:33 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, December 22, 2009 8:00 PM To: ietf-announce@ietf.org Subject: WG Review: Internationalized Resource Identifiers (iri)=20 A new IETF working group has been proposed in the Applications 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 January 12, 2010. Internationalized Resource Identifiers (iri) --------------------------------------- Last Modified: 12-12-2009 Current Status: Proposed Working Group=20 =20 Chair(s): TBD Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: TBD Description of Working Group: This working group will produce * A new version of RFC 3987: "Internationalized Resource Identifiers (IRIs)" using draft-duerst-iri-bis as the base * A new version of RFC 4395: "Guidelines and Registration Procedures for New URI Schemes" The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distribution of the workload and allow more focused reviews. For example, the following breakdown has been suggested: * Handling of Internationalized domain names in IRIs (BCP) * Internationalization Considerations in IRIs (guidelines for BIDI, character ranges to avoid, special considerations) (BCP) * Syntax, parsing, comparison of IRIs (Standards track) The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular: * The IRI specification(s) must (continue to) be suitable for normative reference with Web and XML standards from W3C specifications. The group should coordinate with the W3C working groups on HTML5, XML Core, and Internationalization, as well as with IETF HTTPBIS WG to ensure acceptability. * The IRI specification(s) should be follow best practices for domain names. The group should coordinate with the IETF IDNABIS working group and Unicode Consortium to assure acceptability. * Explicit review by experts on (and native speakers) of RTL languages, of the recommendations for BIDI languages, is required. The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. Schemes suggested for review include http:, pop:, imap:, xmpp:, mailto:, and sip:. Changes to RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax") are explicitly out of scope of this charter, and may only be considered with a charter update. Goals and Milestones: January 2010 Additional update of Internet drafts by editor(s) February 2010 Review of Internet Drafts, directions during W3C and IETF May 2010 Working group Last Call of all documents June 2010 Publish IRI documents as RFCs (BCP, standards track, as appropriate)